working storage values - cobol

On Dec 18, 11:37 am, Alistair <alist...@ld50macca.demon.co.uk> wrote:
> On 17 Dec, 05:00, Richard <rip...@azonic.co.nz> wrote:
>
> Please bear in mind that I have not read the other 50% of posts
> following this one so:
>
>
>
> > The particular issues that I would raise as a matter of '60s style'
> > would be:
>
> > Paragraph numbering is reminiscent of early Fortran and BASIC and is
> > probably the result of designing using HIPO charts. This was really
> > useful when it was necessary to find your way around a box of cards,
> > and possibly even when green line printouts were the best means of
> > browsing source.
>
> Paragraph (and section) numbering is really useful when you need to
> flip back and forth in listings or age up and down in screen-lists to
> quickly get to the relevant paragrapoh (or section). I learned my
> coding style in the 80s and see no reason to remove the numbers just
> because you can remember where the god-damned paragraph appears in the
> listing.

Listing ? I haven't used a printed listing _since_ the 80s.


> > The whole idea of numbering that followed a hierarchical system is
> > preconditioned by the concept that code follows a strict hierarchy of
> > execution and follows from 60s style batch processing.
>
> Books in a library are numbered to make them easy to find. Paragraphs
> (and sections, because I love them too) are numbered to make them easy
> to find too.

How many web pages have numbers on them for that purpose ?

How often do you Dewey numbers into Google ?

Are all your variables numbers too ?

> > PERFORM THRU predicts that a GO TO will be used to take early exit.
>
> Not true.

Then give me an example of code that does not use GO TO (or an
anonymous GOTO substitute) where the THRU is useful.


>> If GO TO is not used then the THRU can be discarded. Any style that
> > relies on GO TO and/or THRU is liable to a number of coding errors
> > that the compiler cannot detect, and may be difficult and time
> > consuming to resolve manually.
>
> > Full Stops at the end of a line of code and the lack of scope
> > terminators classifies this as 'two decades ago' at least.
>
> Saves on key-presses and is more efficient.

An interesting viewpoint, though not one that is useful.

I would argue with 'more efficient'. In many cases the full stop could
need to be removed, for example if more code were to be added to that
leg of the condition. It would be 'more efficient' in that case to
have put the full stop on its own line instead of burying it on the
end of the code.

In any case it is _not_ fewer key-strokes when one has a modern text
editor that generates keywords with simple keystrokes.

Or were you arguing that less lines or fewer characters means more
efficient compile ?


> > These are why I asked for clarification as to whether this was an
> > example of Doc's 'Good Style', where the capitalizing into proper
> > nouns appears to indicate some specific set of rules, or a parody in
> > an archaic bad style.- Hide quoted text -
>
> Doc has a certain style. So, too, do you. Our styles distinguish us
> and may be mutually exclusive. Live with it.

Excellent point that 'mutually exclusive', it is what is making some
styles of Cobol 'exclusive' to an older and decreasing generation
that, as I pointed out before, make Cobol a dying language.

I won't, and haven't, 'Live with' a style from the 60s, nor will
recent, or not so recent, graduates.

On Dec 18, 11:41 am, Alistair <alist...@ld50macca.demon.co.uk> wrote:
> On 17 Dec, 18:33, Robert <n...@e.mail> wrote:
>
> > On Mon, 17 Dec 2007 10:16:27 -0700, Howard Brazee <how...@brazee.net> wrote:
> > >On Sat, 15 Dec 2007 16:09:30 -0600, Robert <n...@e.mail> wrote:
>
> > >>Mainframe systems are hugely EXPENSIVE to the companies that run them.
>
> > >As are alternatives that provide the same security, reliability, and
> > >scale as mainframes.
>
> > z/OS scales from big to very big. It cannot run on handhelds,
>
> Bearing in mind that there are people who run VM, DOS and even MVS on
> desktops,

The whole point of a 'mainframe' is that it has the channel capacity,
redundancy, and speed to give reliable high performance.

Sticking MVS on a PC doesn't make it a mainframe. It just makes it a
clumsy, slow, PC.

> it won't be long before you could run your favourite OS on a
> handheld.

I don't think that MVS be _his_ favourite.

> Unfortunately, the battery won't run much beyond 30
> minutes....

And you would have to tow the card reader required for input on a
trolley behind you.

"Richard" <riplin@azonic.co.nz> wrote in message
news:879f9d87-cbac-4ebd-9a1b-a0c8c1ae09e8@s12g2000prg.googlegroups.com...
> On Dec 18, 6:12 am, Howard Brazee <how...@brazee.net> wrote:
>> On Sun, 16 Dec 2007 21:00:56 -0800 (PST), Richard

<snip>

> Actually, as I said before, the whole idea that the code is a simple
> hierarchy that can be broken down and sequenced so that the code is
> laid out like the execution sequence (ie a HIPO chart) locks the code
> into a batch type environment. If the sequence numbers aren't
> reflective of any structural hierarchy then what is the point of them
> at all ?, habit ?, ability to find them in the card trays ?
>

By having all paragraph names start with a sequence number of the same size
I can use a ROSCOE command like "DELETEX 13 13 /-/ " to delete all lines
that do not have a dash in column 13. This allows me to get all the
paragraph names in the program with a single command and save then in a
ROSCOE member named T1. Then using DELETEX commands to find all PERFORM,
CALL, GO TO, EXEC CICS LINK, EXEC CICS XCTL etc I save each result in T2,
T3, .... Then I can MERGE T1, T2, .... Tn and see at a glance the flow of
control through the program and its paragraphs.

I am sure you have your own "better" ways, but you have the luxury of
choosing any editor that you like and I do not.

On Dec 18, 12:39 pm, "Charles Hottel" <chot...@earthlink.net> wrote:
> "Richard" <rip...@azonic.co.nz> wrote in message
>
> news:879f9d87-cbac-4ebd-9a1b-a0c8c1ae09e8@s12g2000prg.googlegroups.com...
>
> > On Dec 18, 6:12 am, Howard Brazee <how...@brazee.net> wrote:
> >> On Sun, 16 Dec 2007 21:00:56 -0800 (PST), Richard
>
> <snip>
>
> > Actually, as I said before, the whole idea that the code is a simple
> > hierarchy that can be broken down and sequenced so that the code is
> > laid out like the execution sequence (ie a HIPO chart) locks the code
> > into a batch type environment. If the sequence numbers aren't
> > reflective of any structural hierarchy then what is the point of them
> > at all ?, habit ?, ability to find them in the card trays ?
>
> By having all paragraph names start with a sequence number of the same size
> I can use a ROSCOE command like "DELETEX 13 13 /-/ " to delete all lines
> that do not have a dash in column 13. This allows me to get all the
> paragraph names in the program with a single command and save then in a
> ROSCOE member named T1. Then using DELETEX commands to find all PERFORM,
> CALL, GO TO, EXEC CICS LINK, EXEC CICS XCTL etc I save each result in T2,
> T3, .... Then I can MERGE T1, T2, .... Tn and see at a glance the flow of
> control through the program and its paragraphs.

I think that brings me back to the idea that I raised before where the
numbering presupposes that there is such a 'flow of control', such as
one would find on a HIPO chart.


> I am sure you have your own "better" ways, but you have the luxury of
> choosing any editor that you like and I do not.

Certainly I do choose my tools from time to time without external
constraints.

"Richard" <riplin@azonic.co.nz> wrote in message
news:f810a73e-cd25-43b8-ac63-10523d5a29b3@d4g2000prg.googlegroups.com...
> On Dec 17, 11:28 pm, docdw...@panix.com () wrote:
>> In article <zbm9j.191960$_H4.138...@fe08.news.easynews.com>,
>> William M. Klein <wmkl...@nospam.netcom.com> wrote:
>>
>>
>>
>> >"Richard" <rip...@azonic.co.nz> wrote in message
>> >news:39b46538-277e-4cff-84db-f9e0afc006fe@d27g2000prf.googlegroups.com...
>> >> On Dec 16, 1:28 pm, docdw...@panix.com () wrote:
>> >>> In article
>> >>> <8731d51b-1604-4c2c-8413-e189158ac...@e25g2000prg.googlegroups.com>,
>> ><snip>
>> >> Yes, and is this example from one of your messages a result of this
>> >> editing, or is it supposed to represent your 'Good Style' ?
>>
>>
>> >> Or was it merely a parody of the 1960s ?
>>
>> >For those to whom "EIBCALEN" is not just "any old" variable name, the
>> >code above
>> >is VERY meaningful and represents a few lines of code that is in
>> >HOUNDREDS
>> >(thousands?) of COBOL programs in their shop. If "EIBCALEN' and what it
>> >mands
>> >to be "0" is NOT meaningful to you, then you would not know exactly how
>> >common
>> >this specific code sequence is.
>>
>> Perhaps, Mr Klein, Mr Plinston does not have the experiences others have
>> garnered by working in 'a few' shops... but he seems happy and that's
>> what's important.
>>
>> DD
>
> I have plenty of experience in working in quite a few shops,and
> several other places which didn't use that term, but none of them were
> IBM DOS or MVS (where it seems EICALEN does have a meaning). My
> experience is in a variety of different places with systems that you
> may not have even heard of.
>
> This may be why the style that I use has not been constructed around
> HIPO charts, arcane IBMisms and other stuff that derives directly from
> the 60s.
>

As an old-time CICS programmer and someone who has therefore been exposed to
EIBCALEN I agree with Richard that this archaic.

The code is testing to see if this is an initial conversation or not, and it
is as simple as that. As such, I find Richard's objections to be pefectly
reasonable. If I worked on a CICS site where the first paragraph of every
COBOL program using CICS had this ugly, archaic construct in it, I would
certainly not simply include it in my code. (If it was fossilized into a
"shop standard" I would argue vehemently for the modernization of that lcal
standard into something more modern. While it may not be necessary to go
through and change every existing program, it would certainly be necessary
to stop perpetuating this nonsense...)

Just because "we've always done it that way" doesn't mean we should continue
doing that way.

In my opinion, it would be better to simply change the COMM-AREA copy book
so that EIBCALEN had an 88 as follows:

.....EIBCALEN PIC S9(whatever...depending on your version of CICS)
88 NEW-CONVERSATION VALUE ZERO.

The need for the THRU should also be removed, whether you do it by using
SECTION or simply using a single paragraph...


Then replace...

>> >> IF EIBCALEN = 0
>> >> PERFORM 0000-HOUSEKEEPING THRU 0000-HSK-EX
>> >> ELSE
>> >> PERFORM 5000-PROCESS-INPUT THRU 5000-PI-EX.

with...

IF NEW-CONVERSATION
PERFORM 000-HOUSEKEEPING
ELSE
PERFORM 5000-PROCESS-INPUT
END-IF
....

There is nothing "special" or "sacrosanct" about the CICS COMM-AREA
definition. It should be treated just like everything else. When it needs to
be modernised, modernise it.

Any modern programmer looking at this rubbish would react exactly as Richard
did, and attempts to defend it as "Holy Source Code" simply say much more
about the defenders than they do about new people who might challenge it.


Pete.
--
"I used to write COBOL...now I can do anything."

"Howard Brazee" <howard@brazee.net> wrote in message
news:mqndm3l8eoib57f91o71ba27bpj3pqvep6@4ax.com...
> On Mon, 17 Dec 2007 12:15:41 -0800 (PST), Richard
> <riplin@azonic.co.nz> wrote:
>
>>Actually, as I said before, the whole idea that the code is a simple
>>hierarchy that can be broken down and sequenced so that the code is
>>laid out like the execution sequence (ie a HIPO chart) locks the code
>>into a batch type environment. If the sequence numbers aren't
>>reflective of any structural hierarchy then what is the point of them
>>at all ?, habit ?, ability to find them in the card trays ?
>
> Or in the print-out. But having little or no utility doesn't make
> the code bad unless it makes them bad by some measure more that can be
> measured by criteria more meaningful than "it is sooo 1960s".

When I fist read your response, Howard, I tended to agree, but, on
reflection, I'm not so sure...:-)

Just the fact that code reflects approaches and styles from 40 years ago,
COULD be justification for changing it.

Before everyone jumps down my throat, I'm not suggesting that code that
isn't being amended should be modernised for the sake of it; rather, I'm
saying that if you're going to have to maintain it anyway, you might as well
make it more maintainable for the new generation of programmers at the same
time.

Today's programmers are better trained on a wide variety of languages and
"programming" as a profession, and they are arguably more capable than we
were when we started (they are certainly better equipped than we were...).
Some of the code which we "took as read" is as bewildering to them as
Sanskrit would be to us; their training probably didn't cover techniques
inherited from punch card days...

These days I find myself "re-factoring" COBOL as the main activity I do in
this language. It means isolating and encapsulating functionality so it can
be wrapped as components and re-used. In the course of doing this I have
come to realise that there were techniques we used that lend themselves to
this (modular programming, not using PERFORM...THRU, etc...) and there were
techniques we used that don't lend themselves to this (monolithic, large
programs with no layers or interfaces or tiers of separation between
functions...). This can make a significant difference to the cost of
leveraging existing investment.

I'm proud to have been a COBOL Programmer and I don't want the new
generation to see COBOL in a bad light. There is enough criticism of the
language as it is, without adding gasoline to the fire by perpetuating what
we know was bad practice.

Pete.
--
"I used to write COBOL...now I can do anything."

In article <93ab7ada-5595-4c0f-ad9d-3c5d77d1350d@b1g2000pra.googlegroups.com>,
Richard <riplin@azonic.co.nz> wrote:
>On Dec 18, 6:43 am, docdw...@panix.com () wrote:
>> In article <u7bdm3tu3vjc5vof12f5mfu48e6einq...@4ax.com>,
>> Howard Brazee <how...@brazee.net> wrote:
>>
>> [snip]
>>
>> >But
>> >having or not having sequence numbers in paragraph names says nothing
>> >about the quality of the code.
>>
>> Mr Brazee, some people feel *very* deeply about these matters... my memory
>> is, admittedly, porous but I recall someone posting to this newsgroup
>> claiming that changing the case in which code was written, from mixed to
>> upper, changed it from 'good' to 'bad' code.
>
>It certainly would do in very many languages.

There was only one being discussed at the time, Mr Plinston... care to
muster a guess as to which? As a hint I'll pass along that it was not one
that requires one a verb at the end of a sentence to put.

DD

On Dec 18, 1:58 pm, docdw...@panix.com () wrote:
> In article <93ab7ada-5595-4c0f-ad9d-3c5d77d13...@b1g2000pra.googlegroups.com>,
>
>
>
> Richard <rip...@azonic.co.nz> wrote:
> >On Dec 18, 6:43 am, docdw...@panix.com () wrote:
> >> In article <u7bdm3tu3vjc5vof12f5mfu48e6einq...@4ax.com>,
> >> Howard Brazee <how...@brazee.net> wrote:
>
> >> [snip]
>
> >> >But
> >> >having or not having sequence numbers in paragraph names says nothing
> >> >about the quality of the code.
>
> >> Mr Brazee, some people feel *very* deeply about these matters... my memory
> >> is, admittedly, porous but I recall someone posting to this newsgroup
> >> claiming that changing the case in which code was written, from mixed to
> >> upper, changed it from 'good' to 'bad' code.
>
> >It certainly would do in very many languages.
>
> There was only one being discussed at the time, Mr Plinston... care to
> muster a guess as to which? As a hint I'll pass along that it was not one
> that requires one a verb at the end of a sentence to put.

Which appears to indicate that you are not prepared to learn anything
from other languages. If discussion about programming in general and
what others may do are off the agenda, then yes, you may well remain
stuck with 'what I did with my card punch'.

In article <5soie6F1a5e45U1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
>
>"Richard" <riplin@azonic.co.nz> wrote in message
>news:f810a73e-cd25-43b8-ac63-10523d5a29b3@d4g2000prg.googlegroups.com...

[snip]

>> This may be why the style that I use has not been constructed around
>> HIPO charts, arcane IBMisms and other stuff that derives directly from
>> the 60s.
>>
>
>As an old-time CICS programmer and someone who has therefore been exposed to
>EIBCALEN I agree with Richard that this archaic.
>
>The code is testing to see if this is an initial conversation or not, and it
>is as simple as that. As such, I find Richard's objections to be pefectly
>reasonable.

Mr Dashwood, I can see why Mr Plinston doesn't catch on so very quickly...
but can you, as well, really say that you object to the test for EIBCALEN
(essentially, for those out there not familiar with the conventions of the
Customer Information Command System, the Exec(ution) Interface Block
Common Area Length, set, by definition, to zero the first time the program
is entered and to greater-than-zero for each subsequent entry) and see no
similarity to Mr Plinston's pseudocoding of

Procedure Division.

If ( Already-Read NOT = "Y" )
read ..
MOVE "Y" TO Already-Read
END-IF

do whatever with data ..

.... as both being similar 'first time in' methods?

[snip]

>In my opinion, it would be better to simply change the COMM-AREA copy book
>so that EIBCALEN had an 88 as follows:
>
>....EIBCALEN PIC S9(whatever...depending on your version of CICS)
> 88 NEW-CONVERSATION VALUE ZERO.

An 88-level? Mr Plinston has raised objections to those, as well... but
that's for another time, perhaps.

DD