Re: GOBACK

Richard wrote:

> robert.deletethis@wagner.net (Robert Wagner) wrote
>
> 
>
>
> You appear to be claiming that the ENTRY names should be created in
> form "program-labelname" to avoid pollution.  This is another of your
> off the cuff arbitrary fixits that may, or may not, actually fix the
> very real problem, and certainly shows that you haven't thought this
> through.
>
> It may be that on some platforms there are limits to the length of
> external names.  This would result in truncation of the names and thus
> still result in duplication.
>
> There may be limits on the number of external names that may exist in
> the run-unit.  While this may be perfectly adequate for handling
> program-ids, you are suggesting an increase of a couple of orders of
> magnitude.
>
> Paragraph names may be duplicated in one program and only need to be
> unique within a section (not that I reccommend this), and only needs
> qualification when a reference is ambiguous.  Converting to ENTRY will
> give errors or unexpected behaviour.
>
> 
>
>
> C++ name mangling is a completely different thing.  A Class can have
> overloaded methods with different parameter types. The parameter types
> are mangled to the end of the method name to give a unique call name.
>
> 
>
>
> Fujitsu does not support the use of ENTRY in you way you suggested at
> all.
>
> 
>
>
> Then stop trying to change it into something else.
>
> 
>
>
> 'Read and Maintain' is entirely what one is used to.  I can 'read and
> maintain' C code or Python or even Perl, just as easily as Cobol.  I
> choose the one to use by its suitability to the problem.  There are
> things that I do that I can write and get working much more quickly in
> other languages.
>
> 
>
>
> Nested programs are _not_ a parody of 35 year old C as your use of
> ENTRY is.  The refernce was because very early C compilers exported
> all their routine and function names to the run-unit.  Later (ie not
> as long ago as 35 years), they introduced a mechanism to make routines
> 'file local', ie as if the were 'nested' inside the file.  Perhaps you
> can state this feature which ENTRY does not have ?
>
> Nested programs do not fall into the name space trap. They are
> carefully designed and implemented to be usable and scalable into
> large applications.
>
> But, as you say, Nested Programs are very '80s, they are 'What Pascal
> Did', but at least they are a decade on from 'What C Did' in the 70s.
>
> Your 'better' has failed miserably because it was based on your
> emotional need to be seen as a 'Real Programmer' and a complete lack
> of technical insight.
>
> If you want to move on rather than back then learn and start using and
> advocating OO Cobol.
>
> 
>
>
> Then you are probably wasting your time, people in 'other cultures'
> have their own boat to paddle, and will ignore your attempts at this.
>
> 
>
>
> Cobol is very good at certain things.  Most of this is not because it
> is good at 'accounting and stuff' it is because it is good at
> 'surviving change'.
>
> In the time scale of Cobol use the technical 'culture' has moved from
> Algol through Pascal, Ada, C, C++, Java and C#, with many side
> branches.  Those will never take to Cobol, never have, never will
> regardless of how much you try to make it a poor imitation of what
> they did years ago, they will move to the next language.
>
> Cobol will continue to be used _because_ it doesn't require rewriting
> every few years, or just because the site gets a new machine.  The
> systems outlive the fashion changes.
>
> What you keep recommending is to break this.  If your CALL/ENTRY was
> used then it gets broken by another platform or another compiler.
>
> 
>
>
> And you trying to make Cobol do everything is also futile.  You should
> be advocating that Cobol be used where its strengths are, not where
> some other language is stronger, mixing the languages using OO where
> the combination is better than both separately.
>
> The next program that I need to write is a POP3/IMAP email collection
> program that will extract attachments, unzip them, and process the
> attachments.  This is doddle to do in Python (for me), but I will use
> an existing Cobol program to process the attachment data.


Richard,

I found your message very interesting. It says in a clear
way why COBOL will continue.

I don't program anymore, but I look at lots of code.
I am always amazed at the number of unique language
being created for "new" reasons. Not invented here rules.

Warren Simmons

Robert Wagner wrote:
> riplin@Azonic.co.nz (Richard) wrote:
>
> 
>
>
> Dot Net fully supports VB6, including mixed-mode .NET programs calling VB6
> programs.There is no requirement to rewrite older code.
>
> 
>
>
> VB and VBScript dominate the Basic marketplace.
>
> 
>
>
> There is truth in this statement. You don't offer many better ideas.
>
> 
>
>
> I must add 'shared data item' to my lexicon. Definition: a temporary varia
ble to
> which data must be copied because the language is incapable of passing the
> original variable.
>
> 
>
>
> I dislike GLOBAL because it is variant of EXTERNAL and 'blank common'. It'
s a
> mechanism to defeat 'data hiding' by passing data by stealth rather than
> explicitly.
>
> 
>
>
> The ENTRY header lists the linkage section variables being passed. The com
piler
> _could_ diagnose errors. Local-Storage is setup complete for each instance
,
> therefore all references are valid.
>
> 
>
> of
> 
>
> for
> 
>
>
> Your argument and counter-example are based on a 'cooperative' (i.e. not
> preemptive) operating system that was obsolete ten years ago. This is irre
levant
> in a discussion about contemporary operating systems, where multitasking i
s the
> norm.
>
> 
>
>
> My client has many 'external procedures' written in Cobol and dispatched v
ia a
> primative 'listener' daemon talking through an 'Oracle pipe'. Procedures a
nd the
> pipe itself are single threaded. All users and procedures are blocked whil
e a
> procedure executes. The technology wasn't home-grown; it is and continues 
to be
> delivered by SAP.
>
> Oracle provides an alternative 'listener' that IS multithreaded and assume
s the
> procedures are thread-safe, not just reentrant. The challenge is to make
> existing Cobol procedures thread-safe.
>
> IBM mainframers have a large volume of similar programs because DB2 makes 
it
> easier. It supports Stored Procedures written in Cobol. It doesn't require
 them
> to be External Procedures. It doesn't require the programmer do anything s
pecial
> because it constructs a Working-Storage for each instance. In effect, it t
urns
> Working-Storage into Local-Storage. CICS does the same.
>
> 
>
>
> The operating system I wrote knew how to timeslice.
>
> 
>
>
> Suppose the program needs to do process A, B and C. A traditional Cobol pr
ogram
> would say:
> perform A
> perform B
> perform C
> Execution time would be the sum of A+B+C.
>
> A multithreaded program would say:
> start A
> start B
> start C
> wait for A and B and C
> Execution time would be the longest of the three.

Wait a second here. Has the Perform been promoted to
the program level?  Much of the code, it seems to me,
would not produce correct output if the system began
to execute the code in a list of perform statements
without some knowledge of the dependence of one on another.

Perhaps the problem here is that terminology has not
been settled upon. Just because you hear a quack,
you can't conclude that a duck is in the room.

Warren Simmons


>
> 
>
>
> Quotation kept for its bile content.

Warren Simmons <wsimmons5@optonline.net> wrote:

>Robert Wagner wrote:
 
program 
>
>Wait a second here. Has the Perform been promoted to
>the program level?  Much of the code, it seems to me,
>would not produce correct output if the system began
>to execute the code in a list of perform statements
>without some knowledge of the dependence of one on another.

The assumption is no dependence. For example:

perform get-customer-information
perform get-product-information
perform get-order-form-template
.. followed by ..
perform present-order-form

Surely you've seen Cobol code like that. I have.

>
>Perhaps the problem here is that terminology has not
>been settled upon. Just because you hear a quack,
>you can't conclude that a duck is in the room.
>
>Warren Simmons
>
> 

Robert Wagner wrote:
> Warren Simmons <wsimmons5@optonline.net> wrote:
>
> 
>
>
> 
>
> program
> 
>
>
> The assumption is no dependence. For example:
>
> perform get-customer-information
> perform get-product-information
> perform get-order-form-template
> .. followed by ..
> perform present-order-form
>
> Surely you've seen Cobol code like that. I have.
>
> 
>
>
In the context of the presentation in either case
does not IMHO insure that these paragraphs can be
executed in this manner. There must be some other
indication. Otherwise, anyone reading your message
would have a good notion that this applied to
successfully listed performs in a source. I expect
you will ignore my comment, but I suggest you provide
more detail when you "explain" things to any group
for a greater degree of clarity.

Warren Simmons

robert.deletethis@wagner.net (Robert Wagner) wrote

> The assumption is no dependence. For example:

You assume that at your peril.

> perform get-customer-information
> perform get-product-information

In my systems the customer type or class is used to set the price when
the product is retrieved.  An order usually has several products, so
that would follow on.

> perform get-order-form-template
> .. followed by ..
> perform present-order-form
>
> Surely you've seen Cobol code like that. I have.

'Like that' maybe, without dependencies, no.