Cobol - working storage values

Author

working storage values

yoqi99

2007-12-12, 7:55 am

Have vendor started task that runs constantly while listening on port
1205. This started task has a loadlib with user written cobol
programs. This started task also has a control file (jcl ddname)
with a record. For performance reasons, I only want to read the
record one time only. How should I code the cobol program so that
the working storage values are retained between calls.

I can't statically link the vendor program with my program.....

Michael Mattias

2007-12-12, 6:55 pm

"yoqi99" <yoqi99@gmail.com> wrote in message
news:18bff75d-832d-4089-a301-1b5162d5eed4@a35g2000prf.googlegroups.com...
> Have vendor started task that runs constantly while listening on port
> 1205. This started task has a loadlib with user written cobol
> programs. This started task also has a control file (jcl ddname)
> with a record. For performance reasons, I only want to read the
> record one time only. How should I code the cobol program so that
> the working storage values are retained between calls.
>
> I can't statically link the vendor program with my program.....

Unless my COBOL has completely deserted me (it's been about six years)....

Option A, straight answer:
Don't CANCEL the called module from the calling program until done with it
AND
Don't use the INITIAL option in the PROGRAM-ID of the called module

Option B, the pragmatic answer
Don't waste your time thinking about retaining values for one dinky record.
Just read the damn thing when you need it.

Option C, the creative answer.
Code the calling program to pass a group-item containing all the info to be
retained acrosss multiple calls; pass BY REFERENCE. On the first call, read
your record and fill that group item with the necessary info; maintain as
necessary whilst the called module executes.

On subsequent calls, use the values in the passed group-item instead of
re-reading the file.

That is, let the calling program retain the called module's 'static' working
storage instead of trying to do so in the called module.

This option also has the advantage of not being dependent on the INITIAL
clause or any compile-time options, and will also work 'as is' if you do
someday go to static linking.

MCM

yoqi99

2007-12-12, 6:55 pm

On Dec 12, 8:53 am, "Michael Mattias" <mmatt...@talsystems.com> wrote:
> Option A, straight answer:
> Don't CANCEL the called module from the calling program until done with it
> AND
> Don't use the INITIAL option in the PROGRAM-ID of the called module
>
Calling the vendor program that calls the user-written program
terminates, thereby losing the values in working storage. This
is not an option.

> Option B, the pragmatic answer
> Don't waste your time thinking about retaining values for one dinky record.
> Just read the damn thing when you need it.
>
I'm not wasting my time retaining values....Reading the record adds
1/10 of a second to the execution time. In a high-volume web
environment, with limited port connections, this translates to longer
response times.

> Option C, the creative answer.
> Code the calling program to pass a group-item containing all the info to be
> retained acrosss multiple calls; pass BY REFERENCE. On the first call, read
> your record and fill that group item with the necessary info; maintain as
> necessary whilst the called module executes.
>
> On subsequent calls, use the values in the passed group-item instead of
> re-reading the file.
>
> That is, let the calling program retain the called module's 'static' working
> storage instead of trying to do so in the called module.
>
> This option also has the advantage of not being dependent on the INITIAL
> clause or any compile-time options, and will also work 'as is' if you do
> someday go to static linking.
>
> MCM
I thought about calling a separate program that reads the record and
retaining the values in a client singleton program, but this would be
problematic if the the started job ends and restarted with new values
in the file. From the web perspective, the singleton program would
have to be reloaded everytime the started job ends....

Michael Mattias

2007-12-12, 6:55 pm

"yoqi99" <yoqi99@gmail.com> wrote in message
news:145804c2-faeb-4437-aa27-40f37d1169e5@y5g2000hsf.googlegroups.com...
> On Dec 12, 8:53 am, "Michael Mattias" <mmatt...@talsystems.com> wrote:
> Calling the vendor program that calls the user-written program
> terminates, thereby losing the values in working storage. This
> is not an option.
>
>
> I'm not wasting my time retaining values....Reading the record adds
> 1/10 of a second to the execution time. In a high-volume web
> environment, with limited port connections, this translates to longer
> response times.
>
> I thought about calling a separate program that reads the record and
> retaining the values in a client singleton program, but this would be
> problematic if the the started job ends and restarted with new values
> in the file. From the web perspective, the singleton program would
> have to be reloaded everytime the started job ends....

Well, since you found fault with all three good-faith no-cost suggestions
provided as best I could from the sketchy and incomplete "conditions", good
luck finding someone who will actually participate in Option D (The Final
Option):

OPTION D
Engage a professional to solve this problem.

MCM

listmazter@gmail.com

2007-12-12, 6:55 pm

On Dec 12, 9:47 am, "Michael Mattias" <mmatt...@talsystems.com> wrote:
> "yoqi99" <yoq...@gmail.com> wrote in message
>
> news:145804c2-faeb-4437-aa27-40f37d1169e5@y5g2000hsf.googlegroups.com...
>
>
>
>
>
>
>
>
>
>
>
>
> Well, since you found fault with all three good-faith no-cost suggestions
> provided as best I could from the sketchy and incomplete "conditions", good
> luck finding someone who will actually participate in Option D (The Final
> Option):
>
> OPTION D
> Engage a professional to solve this problem.
>
> MCM

ok, thanks dad. next time i will do everything you suggest.
plonk....

William M. Klein

2007-12-12, 6:55 pm

I don't really understand your application structure.

The rules of (Standard) COBOL *require* that the Working-Storage values be
retained between calls to the same subprogram *UNLESS* special things are done.

If your user program is a subprogram (called by the Vendor "main" program) and
the subprogram is "losing" WS values, then the Vendor main program MUST be doing
something "special". It might be doing a CANCEL (if it is written in COBOL).
However, if the vendor main program is NOT a COBOL program (and I am correct
that you are on MVS - because of some of the terms you are using), then it is
possible that the main program is NOT "calling" your user program but is doing
an "ATTACH" or something else that "refreshes" your subprogram. This is
something that you need to find out from the vendor.

There is one solution that MIGHT work for you. If you place the values that you
want to keep into an EXTERNAL 01-level in your user-written program, then these
values should be kept - even if the program is CANCELLED by a high-level
program. However, if the higher-level program isn't COBOL, then this may or may
not work.

--
Bill Klein
wmklein <at> ix.netcom.com
"yoqi99" <yoqi99@gmail.com> wrote in message
news:145804c2-faeb-4437-aa27-40f37d1169e5@y5g2000hsf.googlegroups.com...
> On Dec 12, 8:53 am, "Michael Mattias" <mmatt...@talsystems.com> wrote:
> Calling the vendor program that calls the user-written program
> terminates, thereby losing the values in working storage. This
> is not an option.
>
>
> I'm not wasting my time retaining values....Reading the record adds
> 1/10 of a second to the execution time. In a high-volume web
> environment, with limited port connections, this translates to longer
> response times.
>
> I thought about calling a separate program that reads the record and
> retaining the values in a client singleton program, but this would be
> problematic if the the started job ends and restarted with new values
> in the file. From the web perspective, the singleton program would
> have to be reloaded everytime the started job ends....

Rick Smith

2007-12-12, 6:55 pm

<listmazter@gmail.com> wrote in message
news:258ae2a6-31d7-4909-92b0-0d52479a6e60@e23g2000prf.googlegroups.com...
> On Dec 12, 9:47 am, "Michael Mattias" <mmatt...@talsystems.com> wrote:
with[color=darkred]
to[color=darkred]
call,[color=darkred]
maintain as[color=darkred]
of[color=darkred]
INITIAL[color=darkred]
do[color=darkred]
suggestions[color=darkred]
good[color=darkred]
Final[color=darkred]
>
> ok, thanks dad. next time i will do everything you suggest.
> plonk....

It seems you might also benefit from a second professional
to help you deal with your personal issues!

What you provided was very sketchy. No mention of the
compiler, OS, or platform; though IBM is suggested by
mention of 'jcl ddname'. Also, it seems retention of
working-storage values is not required, only the retention
of data from one record.

Off-hand, I might suggest that, since EXTERNAL data
belongs to the run unit, a COBOL program might read
the file placing the data in an EXTERNAL data-item,
then calling the vendor program. When the vendor
program calls the user progam, the user program gets
the data from the EXTERNAL data-item. But I am
uncertain what you intend by "vendor started task" and,
if you do not have access to the JCL, this method
probably can not be implemented.

Richard

2007-12-12, 6:55 pm

On Dec 13, 2:47 am, yoqi99 <yoq...@gmail.com> wrote:
> Have vendor started task that runs constantly while listening on port
> 1205. This started task has a loadlib with user written cobol
> programs. This started task also has a control file (jcl ddname)
> with a record. For performance reasons, I only want to read the
> record one time only. How should I code the cobol program so that
> the working storage values are retained between calls.
>
> I can't statically link the vendor program with my program.....

If the vendor program CALLs your user written program and does not
CANCEL it then the Working-Storage will be retained intact between
CALLs. You only need to set a flag that indicates that the record has
already been read:

Working-Storage Section.
01 Already-Read PIC X VALUE "N".
01 Record-Data ...

Procedure Division.

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

do whatever with data ..

If the vendor program CANCELs or restarts then you will reread the
record.

William M. Klein

2007-12-12, 6:55 pm

I already sent one message saying that we need to know more about the
"structure" of your application and the vendor program that calls your
user-written application.

One thing that I thought of was that *if* (as I assume) you are on an IBM
mainframe, then it is possible that not only is your vendor "main" program NOT
written in COBOL, but it is also possible that it is NOT an "LE-conforming"
Assembler driver. This would certainly (help) explain why your application
subprograms are ACTING as if they were "main" programs. In this case, EXTERNAL
wouldn't help (nor would anything else that I can think of - except writing the
data out into "system" storage of some sort or another.). You really do need to
find out from the vendor whether the program is or is not LE-conforming (not
just LE "tolerant).

If the vendor program is NOT LE-conforming, then you could still "solve" your
problem by creating an LE-conforming (COBOL, Assembler, or whatever) and have
that driver call the vendor program (once - to get it started). In that case,
your COBOL WS items would be retained. However, depending upon how the vendor
program is designed, this MIGHT cause either performance or storage issues.

--
Bill Klein
wmklein <at> ix.netcom.com
"yoqi99" <yoqi99@gmail.com> wrote in message
news:18bff75d-832d-4089-a301-1b5162d5eed4@a35g2000prf.googlegroups.com...
> Have vendor started task that runs constantly while listening on port
> 1205. This started task has a loadlib with user written cobol
> programs. This started task also has a control file (jcl ddname)
> with a record. For performance reasons, I only want to read the
> record one time only. How should I code the cobol program so that
> the working storage values are retained between calls.
>
> I can't statically link the vendor program with my program.....

2007-12-12, 6:55 pm

In article <966198db-204f-4634-9c2b-8d21439f6586@o42g2000hsc.googlegroups.com>,
Richard <riplin@azonic.co.nz> wrote:
>On Dec 13, 2:47 am, yoqi99 <yoq...@gmail.com> wrote:
>
>If the vendor program CALLs your user written program and does not
>CANCEL it then the Working-Storage will be retained intact between
>CALLs. You only need to set a flag that indicates that the record has
>already been read:
>
> Working-Storage Section.
> 01 Already-Read PIC X VALUE "N".
> 01 Record-Data ...
>
> Procedure Division.
>
> If ( Already-Read NOT = "Y" )
> read ..
> MOVE "Y" TO Already-Read
> END-IF
>
> do whatever with data ..

Hmmmmm... leaving aside the matter of style (any good, true, decent and
sane programmer worthy of the pittance of a salary paid for those hard-won
skills would, of course, make Already-Read an 88) I read this and thought
that lo, there is nothing new under the sun.

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

DD

Richard

2007-12-13, 6:56 pm

On Dec 13, 12:32 pm, docdw...@panix.com () wrote:
> In article <966198db-204f-4634-9c2b-8d21439f6...@o42g2000hsc.googlegroups.com>,
>
>
>
> Richard <rip...@azonic.co.nz> wrote:
>
>
>
>
>
>
>
> Hmmmmm... leaving aside the matter of style (any good, true, decent and
> sane programmer worthy of the pittance of a salary paid for those hard-won
> skills would, of course, make Already-Read an 88)

88s are soooo '60s.

I dislike 88 levels and do not use them. They would interfere with
searching for uses of particular variables.

For example I can find where a variable is used with:

grep variable *.cbl *.pd

or by using a text editor search. With 88s I need to also know what
those names are and search for them too. I'm too lazy to be bothered
with that.

In any case I tend to use modern constructs, such as 'EVALUATE
variable' and the archaic 88 style does not fit into that.

> I read this and thought
> that lo, there is nothing new under the sun.
>
> IF EIBCALEN = 0
> PERFORM 0000-HOUSEKEEPING THRU 0000-HSK-EX
> ELSE
> PERFORM 5000-PROCESS-INPUT THRU 5000-PI-EX.
>
> DD

That, too, is soooo 60s.

Seeing an example like that, no wonder Cobol is dying.

2007-12-13, 6:56 pm

In article <6969359c-00e5-4485-9e94-2e0e0acb1ee1@s12g2000prg.googlegroups.com>,
Richard <riplin@azonic.co.nz> wrote:
>On Dec 13, 12:32 pm, docdw...@panix.com () wrote:
><966198db-204f-4634-9c2b-8d21439f6...@o42g2000hsc.googlegroups.com>,
>
>88s are soooo '60s.

.... and '70s... and '80s... and onward, Good Style is Tymeless.

>
>I dislike 88 levels and do not use them. They would interfere with
>searching for uses of particular variables.

I've never found that to be the case... but perhaps our experiences are
different.

>
>For example I can find where a variable is used with:
>
> grep variable *.cbl *.pd
>
>or by using a text editor search.

Again, our experiences may be different... I'm not familiar with
any platform where a text editor search was not available.

>With 88s I need to also know what
>those names are and search for them too. I'm too lazy to be bothered
>with that.

Too lazy to know what you're working on... hmmmmm... something comes to
mind about 'worthy of the pittance of a salary.

>
>In any case I tend to use modern constructs, such as 'EVALUATE
>variable' and the archaic 88 style does not fit into that.

Wow... maybe someone might put together something like

EVALUATE TRUE
WHEN condition-name
imperative

.... and we could have archaic and eat it, too.

>
>That, too, is soooo 60s.

See above about Tymelessness.

>Seeing an example like that, no wonder Cobol is dying.

Some see examples like that every working day on systems that are still
hugely profitable to the companies that run them... a curious sort of
death, aye.

DD

Richard

2007-12-14, 3:55 am

On Dec 14, 1:11 pm, docdw...@panix.com () wrote:
> In article <6969359c-00e5-4485-9e94-2e0e0acb1...@s12g2000prg.googlegroups.com>,
>
>
>
> Richard <rip...@azonic.co.nz> wrote:
>
>
>
>
>
>
>
>
>
>
> ... and '70s... and '80s... and onward, Good Style is Tymeless.

I suppose that if you are stuck in the past then you wouldn't notice
that the rest of the world has moved on.

>
> I've never found that to be the case... but perhaps our experiences are
> different.
>
>
>
>
>
> Again, our experiences may be different... I'm not familiar with
> any platform where a text editor search was not available.

Of course search is available in every text editor. Grep however will
search all files specified (for example where the search is for a file
field usage) without having to bother with using an editor to open
each file. Of course the result of a grep can be piped into the
editor so that the files can be accessed directly by tapping on the
provided file names.

But regardless of how the search is done the use of 88s may mean that
multiple greps/searches are required.

>
> Too lazy to know what you're working on... hmmmmm... something comes to
> mind about 'worthy of the pittance of a salary.

Being lazy means that I get the job done with minimum effort.
Certainly this means that the project is completed with fewer billing
hours.

>
> Wow... maybe someone might put together something like
>
> EVALUATE TRUE
> WHEN condition-name
> imperative
>
> ... and we could have archaic and eat it, too.

Yes you could, but I dislike 'EVALUATE TRUE'.

The use of 'condition-name' not only gets in the way of finding every
place where the underlying variable is used it also dis-locates the
specific values and the resulting actions.

I am sure that you have devised techniques for overcoming this
objection, but I have avoided needing that by dealing with it in other
ways.

>
>
>
> See above about Tymelessness.

See above for not noticing what happened elsewhere.

>
> Some see examples like that every working day on systems that are still
> hugely profitable to the companies that run them... a curious sort of
> death, aye.

Maybe, but the number of companies keeping such examples, and the
number that see these, are declining. You may be in an enclave of
archaicisms, but others have better ways.

2007-12-14, 7:55 am

In article <794c0dfd-a161-4f3a-b26f-a30aeb06bc9c@e6g2000prf.googlegroups.com>,
Richard <riplin@azonic.co.nz> wrote:
>On Dec 14, 1:11 pm, docdw...@panix.com () wrote:

[snip]

>
>I suppose that if you are stuck in the past then you wouldn't notice
>that the rest of the world has moved on.

There are other elements of Good Style which might have been added over
the years, certainly; one with a sufficiently large capacity might find
room for those, as well.

[snip]

>
>Of course search is available in every text editor.

There's a clever lad... things might be worthy of hope, after all!

[snip]

>
>Being lazy means that I get the job done with minimum effort.
>Certainly this means that the project is completed with fewer billing
>hours.

To 'get the job done' can be accomplished without the least invocation or
use of Good Style, last I looked.

>
>
>
>Yes you could, but I dislike 'EVALUATE TRUE'.

Such a sensitive soul... how you manage to get by is truly a Testament to
Human Strength.

[snip]

>
>Maybe, but the number of companies keeping such examples, and the
>number that see these, are declining. You may be in an enclave of
>archaicisms, but others have better ways.

There are different ways in many places, Mr Plinston, and I've seen a
few... it was mentioned a few times that our experiences might, possibly,
be different.

DD

William M. Klein

2007-12-14, 6:56 pm

<Joke>

Using grep (or similar) is *SO* '60's. All current COBOL sensitive editors have
ways of searching for "referenced data items" that include 88-levels and other
"implicit" modifications to COBOL data items.

--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <riplin@azonic.co.nz> wrote in message
news:794c0dfd-a161-4f3a-b26f-a30aeb06bc9c@e6g2000prf.googlegroups.com...
> On Dec 14, 1:11 pm, docdw...@panix.com () wrote:
>
> I suppose that if you are stuck in the past then you wouldn't notice
> that the rest of the world has moved on.
>
>
>
> Of course search is available in every text editor. Grep however will
> search all files specified (for example where the search is for a file
> field usage) without having to bother with using an editor to open
> each file. Of course the result of a grep can be piped into the
> editor so that the files can be accessed directly by tapping on the
> provided file names.
>
> But regardless of how the search is done the use of 88s may mean that
> multiple greps/searches are required.
>
>
>
> Being lazy means that I get the job done with minimum effort.
> Certainly this means that the project is completed with fewer billing
> hours.
>
>
>
> Yes you could, but I dislike 'EVALUATE TRUE'.
>
> The use of 'condition-name' not only gets in the way of finding every
> place where the underlying variable is used it also dis-locates the
> specific values and the resulting actions.
>
> I am sure that you have devised techniques for overcoming this
> objection, but I have avoided needing that by dealing with it in other
> ways.
>
>
> See above for not noticing what happened elsewhere.
>
>
> Maybe, but the number of companies keeping such examples, and the
> number that see these, are declining. You may be in an enclave of
> archaicisms, but others have better ways.
>

Richard

2007-12-14, 6:56 pm

On Dec 14, 11:18 pm, docdw...@panix.com () wrote:
> In article <794c0dfd-a161-4f3a-b26f-a30aeb06b...@e6g2000prf.googlegroups.com>,
>
> Richard <rip...@azonic.co.nz> wrote:
>
> [snip]
>
>
>
> There are other elements of Good Style which might have been added over
> the years, certainly; one with a sufficiently large capacity might find
> room for those, as well.

> [snip]
>
>
>
>
>
>
> There's a clever lad... things might be worthy of hope, after all!
>
> [snip]
>
>
>
> To 'get the job done' can be accomplished without the least invocation or
> use of Good Style, last I looked.

I didn't know that, but I bow to your superior experience with that
issue.

I find that the style that I use gets the job done more effectively,
most noticeably when projects need to be enhanced to meet new
requirements many years later. But each to their own.

I don't know what your 'Good Style' is, perhaps someday you could post
a few lines that use it rather than the style you do post.

>
>
>
>
>
> Such a sensitive soul... how you manage to get by is truly a Testament to
> Human Strength.

It does not require any effort at all, I never see 'EVALUATE TRUE' so
it is of no concern.

>
>
> There are different ways in many places, Mr Plinston, and I've seen a
> few... it was mentioned a few times that our experiences might, possibly,
> be different.

From what I have read before I would hazard a guess that most of your
'many places' were mainframe Cobol shops. Certainly there are many
ways to recycle styles from the 60s.

I would say that the main influence this century on the style that I
use is my adoption of Python as my primary language.

Most of the Cobol (and C, etc) that I now write tends to be table-
driven. A data table is created that specifies all the conditions and
actions and then code processes the table. The table, of course, can
be external data so that the program action can be changed without
fiddling with code at all.

Richard

2007-12-14, 6:56 pm

On Dec 15, 7:48 am, "William M. Klein" <wmkl...@nospam.netcom.com>
wrote:
> <Joke>
>
> Using grep (or similar) is *SO* '60's.

Well, actually it is late 70's. grep derives from the Unix ed (and vi
derivative) editor's command g/re/p which means 'global / regular
expression / print', in other words a text editor search function able
to find variations described by the expression.

Having it additionally as a separate utility allows it to feed results
into any other utility and build scripts that save having to do things
manually by typing, and retyping, into a text editor.

> All current COBOL sensitive editors have
> ways of searching for "referenced data items" that include 88-levels and other
> "implicit" modifications to COBOL data items.

'All' ? Didn't you recently critize someone for implying 'all' ?

Does the lack of this feature indicate that an editor is not 'current'
or not 'Cobol sensitive' ?

Anyway, that 'solution' is just a complexification of a problem that
is best solved (IMHO) by avoiding it. For example, that solution
would most likely use proprietry editors that may not be available,
for various reasons, on a particular system.

I use an editor that I can adapt to whatever task that I am currently
engaged on, but sometimes I have to use different ones and adapt to
those. Tying code to an editor's feature set may make good business
sense to the editor's vendor, but not to me.

Howard Brazee

2007-12-14, 9:56 pm

On Thu, 13 Dec 2007 15:54:50 -0800 (PST), Richard
<riplin@azonic.co.nz> wrote:

>For example I can find where a variable is used with:
>
> grep variable *.cbl *.pd
>
>or by using a text editor search. With 88s I need to also know what
>those names are and search for them too. I'm too lazy to be bothered
>with that.

That's a reasonable argument.

>In any case I tend to use modern constructs, such as 'EVALUATE
>variable' and the archaic 88 style does not fit into that.

Huh? Why not?

Richard

2007-12-15, 3:55 am

On Dec 15, 3:27 pm, Howard Brazee <how...@brazee.net> wrote:
> On Thu, 13 Dec 2007 15:54:50 -0800 (PST), Richard
>
> <rip...@azonic.co.nz> wrote:
>
>
>
> That's a reasonable argument.
>
>
> Huh? Why not?

You will note that I said 'EVALUATE variable', condition names only
fit where it is 'EVALUATE TRUE' (or FALSE).

Robert

2007-12-15, 3:55 am

On Fri, 14 Dec 2007 19:27:21 -0700, Howard Brazee <howard@brazee.net> wrote:

>On Thu, 13 Dec 2007 15:54:50 -0800 (PST), Richard
><riplin@azonic.co.nz> wrote:
>
>
>That's a reasonable argument.
>
>
>Huh? Why not?

Because you can't do this:

01 end-of-file-ind pic x.
88 end-of-file value 'y'.
88 not-end-of-file value 'n'.

evaluate end-of-file-ind
when end-of-file exit perform
when not-end-of-file continue
end-evaluate

You'll get an error because the compiler thinks you're not testing values in
end-of-file-ind. To do that, you must say evaluate true.

One solution:

1. Don't give the data a name. You don't want to set it with the name and test it with the
88, or vice versa. You want to set and test it the same way.

2. If there are two possible values, use false clause on the 88. That way there's only one
name. If you're going to do that, you might as well make it a boolean.

01 pic 1 bit.
88 end-of-file value B'1'' false zero.

set end-of-file to false
perform until end-of-file
....
read ... at end set end-of-file to true end-read
end-perform

William M. Klein

2007-12-15, 6:55 pm

Just so it is clear, you CAN use
Evaluate "name"
with 88-levels, i.e.

evaluate end-of-file
*> This evaluate tests the value in end-of-file-ind
when True exit perform
when False continue
end-evaluate

I don't claim that this is a style you would "like" - but it does work (and the
comment allows you to grep for it. However, if some of us, you actually put the
88-levels under a "filler" field, (and use only SET TO TRUE/FALSE) then that
won't work.

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <no@e.mail> wrote in message
news:lon6m3didvvp3r6i9jdqafbk85n8g9264h@
4ax.com...
> On Fri, 14 Dec 2007 19:27:21 -0700, Howard Brazee <howard@brazee.net> wrote:
>
>
> Because you can't do this:
>
> 01 end-of-file-ind pic x.
> 88 end-of-file value 'y'.
> 88 not-end-of-file value 'n'.
>
> evaluate end-of-file-ind
> when end-of-file exit perform
> when not-end-of-file continue
> end-evaluate
>
> You'll get an error because the compiler thinks you're not testing values in
> end-of-file-ind. To do that, you must say evaluate true.
>
> One solution:
>
> 1. Don't give the data a name. You don't want to set it with the name and test
> it with the
> 88, or vice versa. You want to set and test it the same way.
>
> 2. If there are two possible values, use false clause on the 88. That way
> there's only one
> name. If you're going to do that, you might as well make it a boolean.
>
>
> 01 pic 1 bit.
> 88 end-of-file value B'1'' false zero.
>
> set end-of-file to false
> perform until end-of-file
> ....
> read ... at end set end-of-file to true end-read
> end-perform
>
>
>
>
>

Robert

2007-12-15, 6:56 pm

On Sat, 15 Dec 2007 17:18:47 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>Just so it is clear, you CAN use
> Evaluate "name"
>with 88-levels, i.e.
>
> evaluate end-of-file
> *> This evaluate tests the value in end-of-file-ind
> when True exit perform
> when False continue
> end-evaluate
>
>I don't claim that this is a style you would "like" - but it does work (and the
>comment allows you to grep for it. However, if some of us, you actually put the
>88-levels under a "filler" field, (and use only SET TO TRUE/FALSE) then that
>won't work.

The evaluate will work, and the grep will work on the condition name, which is the ONLY
name.

If there are only two values, true and false, you might as well use IF or UNTIL.

At the place where I work now, they qualify 88s with the data name. That satisfies the
grep requirement.

set end-of-file in end-of-file-ind to false
perform until end-of-file in end-of-file-ind
.....
end-perform

Micro Focus lets you mix a value test on the subject with a normal conditional, like so:

evaluate end-of-file-ind
when any and end-of-file

evaluate end-of-file-ind
when B'1' or phase-of-moon = 'full'

evaluate end-of-file-ind
when not = B'1' and B'0'

>"Robert" <no@e.mail> wrote in message
> news:lon6m3didvvp3r6i9jdqafbk85n8g9264h@
4ax.com...
>

Robert

2007-12-15, 6:56 pm

On Fri, 14 Dec 2007 00:11:28 +0000 (UTC), docdwarf@panix.com () wrote:

>In article <6969359c-00e5-4485-9e94-2e0e0acb1ee1@s12g2000prg.googlegroups.com>,
>Richard <riplin@azonic.co.nz> wrote:

>
>Some see examples like that every working day on systems that are still
>hugely profitable to the companies that run them... a curious sort of
>death, aye.

Mainframe systems are hugely EXPENSIVE to the companies that run them. They are hugely
profitable to IBM.

2007-12-15, 6:56 pm

In article <8731d51b-1604-4c2c-8413-e189158ac88f@e25g2000prg.googlegroups.com>,
Richard <riplin@azonic.co.nz> wrote:
>On Dec 14, 11:18 pm, docdw...@panix.com () wrote:

[snip]

>
>I didn't know that, but I bow to your superior experience with that
>issue.

No need to rely on the experience of others, Mr Plinston... a bit of
mental exercise might be able to supply a bit of evidence. Good Style
can, say, includes datanames which reflect the content of the field; were
one to use a text editor that has not only search capabilities but global
replace ones it would be a trivial task to take a chunk of source and
change all Customer-Number to C001, Customer-Name to C002, Customer-Addr1
to C003, etc.

As long as the changes were global the program would still get the job
done... but, to many eyes, be a tad less legible, as well.

>
>I find that the style that I use gets the job done more effectively,
>most noticeably when projects need to be enhanced to meet new
>requirements many years later.

As my Sainted Paternal Grandfather - may he sleep with the angels! - said,
'Never use yourself as a comparative, you'll only be disappointed'.

But each to their own... after all, what you've found may be all that
there is to be found, right?

>
>I don't know what your 'Good Style' is, perhaps someday you could post
>a few lines that use it rather than the style you do post.

Mr Plinston, I've let competent coders decide which of the styles I've
posted in are considered Good and which aren't, if you want to read what
they have said you may, perhaps, learn something from it.

>
>It does not require any effort at all, I never see 'EVALUATE TRUE' so
>it is of no concern.

A few examples have been posted here... but see above about 'what you've
found'.

[snip]

>
>From what I have read before I would hazard a guess that most of your
>'many places' were mainframe Cobol shops.

A careful reader, Mr Plinston, might have noticed that I made no claim to
having 'many places' and only to having seen 'a few'.

DD

2007-12-15, 6:56 pm

In article <01k8m3p53kfh8f2j0ungcajdunflbka0as@4ax.com>,
Robert <no@e.mail> wrote:
>On Fri, 14 Dec 2007 00:11:28 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
>
>Mainframe systems are hugely EXPENSIVE to the companies that run them.

Mr Wagner, some study in economics might reveal that being EXPENSIVE (caps
original) and being profitable are in no wise mutually exclusive.

DD

Michael Mattias

2007-12-16, 6:55 pm

<docdwarf@panix.com> wrote in message news:fk1rjr$eej$1@reader1.panix.com...
> Mr Wagner, some study in economics might reveal that being EXPENSIVE (caps
> original) and being profitable are in no wise mutually exclusive.

Too many of today's managers don't understand the difference between
"expense" and "value."

MCM

2007-12-16, 6:55 pm

In article <PUa9j.6119$fl7.509@newssvr22.news.prodigy.net>,
Michael Mattias <mmattias@talsystems.com> wrote:
><docdwarf@panix.com> wrote in message news:fk1rjr$eej$1@reader1.panix.com...
>
>Too many of today's managers don't understand the difference between
>"expense" and "value."

Ahhhhh, the equating of 'costs anything' with 'costs too much!'... I've
seen that a few times, here and there.

DD

Richard

2007-12-16, 9:55 pm

On Dec 16, 1:28 pm, docdw...@panix.com () wrote:
> In article <8731d51b-1604-4c2c-8413-e189158ac...@e25g2000prg.googlegroups.com>,
>
> Richard <rip...@azonic.co.nz> wrote:
>
> [snip]
>
>
>
> No need to rely on the experience of others, Mr Plinston... a bit of
> mental exercise might be able to supply a bit of evidence. Good Style
> can, say, includes datanames which reflect the content of the field; were
> one to use a text editor that has not only search capabilities but global
> replace ones it would be a trivial task to take a chunk of source and
> change all Customer-Number to C001, Customer-Name to C002, Customer-Addr1
> to C003, etc.

I am not sure why you would want to tediously change all those, one at
a time, manually, using a tool as crude as a text editor.

> As long as the changes were global the program would still get the job
> done... but, to many eyes, be a tad less legible, as well.

Yes, and is this example from one of your messages a result of this
editing, or is it supposed to represent your 'Good Style' ?

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

Or was it merely a parody of the 1960s ?

>
> As my Sainted Paternal Grandfather - may he sleep with the angels! - said,
> 'Never use yourself as a comparative, you'll only be disappointed'.
>

> But each to their own... after all, what you've found may be all that
> there is to be found, right?
>
>
> Mr Plinston, I've let competent coders decide which of the styles I've
> posted in are considered Good and which aren't, if you want to read what
> they have said you may, perhaps, learn something from it.

Is this indicating that a 'coder' (a rather archaic term from when
there was a strict hierarchy from analyst -> designer -> programmer ->
coder -> card punch operator, but perhaps it still exists in some
halls of cubicaled mazes), that chooses differently is, in your
opinion, less than competent ?

As I cannot tell which 'coders' that you may label 'competent' and
which you would not I could not distinguish between comments deciding
one way or another.

>
>
>
> A few examples have been posted here... but see above about 'what you've
> found'.
>
> [snip]
>
>
>
> A careful reader, Mr Plinston, might have noticed that I made no claim to
> having 'many places' and only to having seen 'a few'.

I stand corrected: your experience is that you have seen only a few
mainframe Cobol shops.

William M. Klein

2007-12-16, 9:55 pm

"Richard" <riplin@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:
<snip>[color=darkred]
> Yes, and is this example from one of your messages a result of this
> editing, or is it supposed to represent your 'Good Style' ?
>
> IF EIBCALEN = 0
> PERFORM 0000-HOUSEKEEPING THRU 0000-HSK-EX
> ELSE
> PERFORM 5000-PROCESS-INPUT THRU 5000-PI-EX.
>
>
> 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.

Such code *is* still in use (and being used by new programs) today.

The original post was talking about this as a '60ish" thing, but as I can't
remember when Command-level came in or how this was done in macro level, I would
guess it is actually a 70's thru current thing.

--
Bill Klein
wmklein <at> ix.netcom.com

Richard

2007-12-17, 3:55 am

On Dec 17, 4:39 pm, "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...
>
> <snip>
>
>
>
> 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.
>
> Such code *is* still in use (and being used by new programs) today.

I grant that this is arcane rather than archaic then.

> The original post was talking about this as a '60ish" thing, but as I can't
> remember when Command-level came in or how this was done in macro level, I would
> guess it is actually a 70's thru current thing.

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.

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.

PERFORM THRU predicts that a GO TO will be used to take early exit. 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.

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.

2007-12-17, 7:55 am

In article <39b46538-277e-4cff-84db-f9e0afc006fe@d27g2000prf.googlegroups.com>,
Richard <riplin@azonic.co.nz> wrote:
>On Dec 16, 1:28 pm, docdw...@panix.com () wrote:
><8731d51b-1604-4c2c-8413-e189158ac...@e25g2000prg.googlegroups.com>,
>
>I am not sure why you would want to tediously change all those, one at
>a time, manually, using a tool as crude as a text editor.
>
>
>Yes, and is this example from one of your messages a result of this
>editing, or is it supposed to represent your 'Good Style' ?
>
>IF EIBCALEN = 0
> PERFORM 0000-HOUSEKEEPING THRU 0000-HSK-EX
>ELSE
> PERFORM 5000-PROCESS-INPUT THRU 5000-PI-EX.
>
>
>Or was it merely a parody of the 1960s ?

Mr Plinston, a bit of careful reading would show this was addressed when I
posted that bit of code on 12 Dec 2007; perhaps my parenthetic note
distracted you and if that is the case I apologise.

[snip]

>
>Is this indicating that a 'coder' (a rather archaic term from when
>there was a strict hierarchy from analyst -> designer -> programmer ->
>coder -> card punch operator, but perhaps it still exists in some
>halls of cubicaled mazes), that chooses differently is, in your
>opinion, less than competent ?

No, Mr Plinston, this is indicating that I've let competent coders decide
which of the styles I've posted in are considered Good and which aren't.

It further is indicating that if you want to read what they have said you
may, perhaps, learn something from it... my apologies, once again, for
being so obscure.

>
>As I cannot tell which 'coders' that you may label 'competent' and
>which you would not I could not distinguish between comments deciding
>one way or another.

Now there's a bit of a challenge for a stout lad... have at it! Find the
code, determine the quality, find the comments, evaluate the competency,
compare with your own conclusions... looks like someone's going to be
rather busy.

[snip]

>
>
>I stand corrected: your experience is that you have seen only a few
>mainframe Cobol shops.

Exactly right, Mr Plinston... a couple here, a couple there, nothing
special whatsoever... remember, I'se jes' a COBOL-codin' fool.

DD

2007-12-17, 7:55 am

In article <zbm9j.191960$_H4.138777@fe08.news.easynews.com>,
William M. Klein <wmklein@nospam.netcom.com> wrote:
>"Richard" <riplin@azonic.co.nz> wrote in message
>news:39b46538-277e-4cff-84db-f9e0afc006fe@d27g2000prf.googlegroups.com...
><snip>
>
>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

Howard Brazee

2007-12-17, 6:56 pm

On Sun, 16 Dec 2007 21:00:56 -0800 (PST), Richard
<riplin@azonic.co.nz> wrote:

>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.
>
>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.
>
>PERFORM THRU predicts that a GO TO will be used to take early exit. 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.
>
>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.

My measure of good code or bad code isn't whether the code is in
fashion today or not.

Does the code do what it is supposed to do?
Is the code clear?
Is the code easily maintainable?
Does the code handle exceptions effectively?
and even
Is the code efficient?

Fashions come and go. Some fashions are actually useful. But
having or not having sequence numbers in paragraph names says nothing
about the quality of the code.

Howard Brazee

2007-12-17, 6:56 pm

On Sat, 15 Dec 2007 16:09:30 -0600, Robert <no@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.

> They are hugely profitable to IBM.

(Only IBM mainframes are hugely profitable to IBM. There are other
mainframe companies).

But Windows & Office is hugely profitable to MS. And Macs and iPods
are hugely profitable to Apple.

How much profit they make has nothing to do with whether their
products are the best choice for me.

2007-12-17, 6:56 pm

In article <u7bdm3tu3vjc5vof12f5mfu48e6einqp3l@4ax.com>,
Howard Brazee <howard@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.

DD

Robert

2007-12-17, 6:56 pm

On Mon, 17 Dec 2007 10:16:27 -0700, Howard Brazee <howard@brazee.net> wrote:

>On Sat, 15 Dec 2007 16:09:30 -0600, Robert <no@e.mail> wrote:
>
>
>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, and isn't run on
supercomputres. It isn't even economically practical on medium sized, which run VSE.

Security is mostly a function of administration, or lack thereof. If z/OS were deployed on
a hundred million home computers, some or most of them would be vulnerable.

As for reliability, when is the last time you couldn't get dial tone?

Howard Brazee

2007-12-17, 6:56 pm

On Mon, 17 Dec 2007 12:33:48 -0600, Robert <no@e.mail> wrote:

>
>z/OS scales from big to very big. It cannot run on handhelds, and isn't run on
>supercomputres. It isn't even economically practical on medium sized, which run VSE.

Are you implying that tools should be optimized to fit their task?
Or are you implying that one size should fit all?

A train engine won't run a cargo ship, nor will it run a sports car.
It is possible to use sports cars to carry large amounts cargo across
the country if the cargo can be compartmentalized sufficiently. And
there is a business case for using sports cars for some deliveries.

But different business needs have different optimal tools.

It is easy to say that the solution that works for me is the Right
solution. But lots of hatred, wars, and missed opportunities are
created by people who reject the notion that some other solution works
for others.

Trains, cargo ships, and big iron computers are soooo yesterday.
Anybody who uses them obviously must not have done a careful analysis
of fashions.

>Security is mostly a function of administration, or lack thereof. If z/OS were deployed on
>a hundred million home computers, some or most of them would be vulnerable.

Therefore, Big Iron is dead. We should replace it with a server farm
- because if Z/OS could be vulnerable on a hundred million computers,
obviously it isn't secure on a single secured spot.

>As for reliability, when is the last time you couldn't get dial tone?

I'm not getting why you are asking this, but last w

Richard

2007-12-17, 6:56 pm

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:
>
>
>
>
>
>
>
> 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.

Richard

2007-12-17, 6:56 pm

On Dec 18, 6:12 am, Howard Brazee <how...@brazee.net> wrote:
> On Sun, 16 Dec 2007 21:00:56 -0800 (PST), Richard
>
>
>
> <rip...@azonic.co.nz> wrote:
>
>
>
>
>
>
> My measure of good code or bad code isn't whether the code is in
> fashion today or not.

Maybe, but the willingness of a new generation of programmers to work
with such code may well depend on that. Cobol is dying along with
those who wrote it since the 60s (which includes myself) because
bright young programmers (which I would like to include myself) won't
work with archaic styles.

> Does the code do what it is supposed to do?

Almost any style can achieve that.

> Is the code clear?

That may depend on 'what one is used to'. Code is usually clear to the
one who wrote it. Shop standards try to ensure that all code is
written the same so that it is 'clear' to all that have written code
to that standard.

To someone that hasn't stuck with the same set of shop standards since
the 60s, such as those trained on Pascal, C++, Java, C#, it may not be
clear at all.

> Is the code easily maintainable?

Same as above. Those whose solution toolset is 'create a new object
and put it in the collection', will not find PERFORM THRU to be
'easily maintainable'.

> Does the code handle exceptions effectively?
> and even
> Is the code efficient?
>
> Fashions come and go. Some fashions are actually useful. But
> having or not having sequence numbers in paragraph names says nothing
> about the quality of the code.

It will have something to do with the age of the programmer still
willing to work on it.

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 ?

GUI, OO, Web Sites, Web Services, aren't written as strict
hierarchical structures. It is not fashion, it is function.

Hierarchical sequence numbering also implies that it is the result of
a strict 'top-down' design methodology, or 'stepwise refinement'
perhaps. More recent methodologies are required when the application
is not 'top-down'.

Richard

2007-12-17, 6:56 pm

On Dec 18, 6:43 am, docdw...@panix.com () wrote:
> In article <u7bdm3tu3vjc5vof12f5mfu48e6einq...@4ax.com>,
> Howard Brazee <how...@brazee.net> wrote:
>
> [snip]
>
>
> 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.

(but you may not have known that).

Richard

2007-12-17, 6:56 pm

On Dec 18, 7:58 am, Howard Brazee <how...@brazee.net> wrote:
> On Mon, 17 Dec 2007 12:33:48 -0600, Robert <n...@e.mail> wrote:
>
>
>
> Are you implying that tools should be optimized to fit their task?
> Or are you implying that one size should fit all?

I think that it was you that claimed 'scale'. Linux, in fact, can and
does run on watches and some of the largest supercomputers. It is not
that it should, but it can.

> A train engine won't run a cargo ship,

I wonder why you would imagine this. The same engines have been used
in both trains and ships.

> nor will it run a sports car.

Interestingly, they have. The Bugatti Royale did use a train engine,
One of Bugatti's main business was engines for railcars.

> It is possible to use sports cars to carry large amounts cargo across
> the country if the cargo can be compartmentalized sufficiently. And
> there is a business case for using sports cars for some deliveries.
>
> But different business needs have different optimal tools.
>
> It is easy to say that the solution that works for me is the Right
> solution. But lots of hatred, wars, and missed opportunities are
> created by people who reject the notion that some other solution works
> for others.
>
> Trains, cargo ships, and big iron computers are soooo yesterday.
> Anybody who uses them obviously must not have done a careful analysis
> of fashions.
>
>
> Therefore, Big Iron is dead. We should replace it with a server farm
> - because if Z/OS could be vulnerable on a hundred million computers,
> obviously it isn't secure on a single secured spot.

I think it was you who claimed 'security' for mainframes. This
security is not inherent in the design but is the result of
administration.

>
> I'm not getting why you are asking this, but last w

.

IBM big iron mainframes certainly are reliable, but so are other
systems.

Howard Brazee

2007-12-17, 6:56 pm

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".

Howard Brazee

2007-12-17, 6:56 pm

On Mon, 17 Dec 2007 12:15:41 -0800 (PST), Richard
<riplin@azonic.co.nz> wrote:

>It will have something to do with the age of the programmer still
>willing to work on it.

I guess there is an argument that fashion can count, even when
function doesn't count. The CEO wearing a tie might lose some blood
flow to the brain but makes sure everybody know his position.

Howard Brazee

2007-12-17, 6:56 pm

On Mon, 17 Dec 2007 12:35:33 -0800 (PST), Richard
<riplin@azonic.co.nz> wrote:

>
>I think it was you who claimed 'security' for mainframes. This
>security is not inherent in the design but is the result of
>administration.

With all other things being equal, putting everything in one box makes
it much easier to defend against attackers.

On the other hand, if we lose that battle, we have lost all.

A server farm's design makes it easier to have redundancy.
A centralized mainframe's design makes it easier to have security.

The same thing happens all over. Weapons in an arsenal are easier to
safeguard - but it's harder to round up all of the weapons in people's
houses. This isn't because one has better administration than the
other, it is an inherent characteristic of centralized vs distributed
design.

Richard

2007-12-17, 6:56 pm

On Dec 18, 9:44 am, Howard Brazee <how...@brazee.net> wrote:
> On Mon, 17 Dec 2007 12:15:41 -0800 (PST), Richard
>
> <rip...@azonic.co.nz> wrote:
>
> Or in the print-out.

Print-out ? you still do printouts ?

> 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".

If they aren't representing an actual hierarchy then they are
superfluous and may be misleading. That is they would get in the way
of understanding and would reduce clarity.

tlmfru

2007-12-17, 6:56 pm

Richard <riplin@azonic.co.nz> wrote in message
news:e6181dab-c81c-46d2-a514-9bd519acdbc0@d27g2000prf.googlegroups.com...
> On Dec 18, 9:44 am, Howard Brazee <how...@brazee.net> wrote:
>
> Print-out ? you still do printouts ?
>
>
> If they aren't representing an actual hierarchy then they are
> superfluous and may be misleading. That is they would get in the way
> of understanding and would reduce clarity.
>

You know, that needn't be so; hierarchy doesn't necessarily come into it.
Any section of code that's functionally cohesive - f'r instance, all the
code needed to finalize an update, or the common utility routines that every
program uses - can be grouped together under one set of paragraph sequence
#'s - 1000 to 1999, etc. As event-oriented code can be written easily
enough in procedural Cobol (assuming an external screen-handler function),
the responses to the various events can be grouped together without any
apparent hierarchy at all.

PL

Alistair

2007-12-17, 6:56 pm

On 14 Dec, 05:54, Richard <rip...@azonic.co.nz> wrote:
> On Dec 14, 1:11 pm, docdw...@panix.com () wrote:
>
>
> Of course search is available in every text editor. Grep however will
> search all files specified (for example where the search is for a file
> field usage) without having to bother with using an editor to open
> each file. Of course the result of a grep can be piped into the
> editor so that the files can be accessed directly by tapping on the
> provided file names.
>

Regrettably, GREP is not available to non-Unix systems. Some of us
don't have the luxury of using the new-fangled tools to which you have
access.

> But regardless of how the search is done the use of 88s may mean that
> multiple greps/searches are required.
>

What, can't you combine GREP searches? Shame thet EGREP and FGREP
don't work either. That's so 1980s.

Alistair

2007-12-17, 6:56 pm

On 15 Dec, 22:09, Robert <n...@e.mail> wrote:
> On Fri, 14 Dec 2007 00:11:28 +0000 (UTC), docdw...@panix.com () wrote:
>
>
> Mainframe systems are hugely EXPENSIVE to the companies that run them. They are hugely
> profitable to IBM.

OK Robert: Microsoft or IBM? Whom would you rather get into bed with?

Richard

2007-12-17, 6:56 pm

On Dec 18, 10:33 am, "tlmfru" <la...@mts.net> wrote:
> Richard <rip...@azonic.co.nz> wrote in message
>
> news:e6181dab-c81c-46d2-a514-9bd519acdbc0@d27g2000prf.googlegroups.com...
>
>
>
>
>
>
>
>
>
> You know, that needn't be so; hierarchy doesn't necessarily come into it.
> Any section of code that's functionally cohesive - f'r instance, all the
> code needed to finalize an update, or the common utility routines that every
> program uses - can be grouped together under one set of paragraph sequence
> #'s - 1000 to 1999, etc. As event-oriented code can be written easily
> enough in procedural Cobol (assuming an external screen-handler function),
> the responses to the various events can be grouped together without any
> apparent hierarchy at all.

If the numbers are merely arbitrary and have no actual meaning then
they may just be obstructive and reduce clarity. Things can be grouped
together using meaningful names rather than arcane codes.

In fact you have defended exactly how Doc described making 'Good
style' into bad. Instead of a meaningful prefix you would put a
number.

And yes, I was writing event-driven code in Cobol for Windows 3.0.

Alistair

2007-12-17, 6:56 pm

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.

>
> 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.

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

Not true.

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.

>
> 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.

Alistair

2007-12-17, 6:56 pm

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:
>
>
>
> 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, it won't be long before you could run your favourite OS on a
handheld. Unfortunately, the battery won't run much beyond 30
minutes....

Alistair

2007-12-17, 6:56 pm

On 17 Dec, 18:58, Howard Brazee <how...@brazee.net> wrote:
> On Mon, 17 Dec 2007 12:33:48 -0600, Robert <n...@e.mail> wrote:
>
>
>
> Are you implying that tools should be optimized to fit their task?
> Or are you implying that one size should fit all?
>
> A train engine won't run a cargo ship, nor will it run a sports car.

The world land-speed record for a steam driven car is in excess of 120
mph.

>
> Trains, cargo ships, and big iron computers are soooo yesterday.
> Anybody who uses them obviously must not have done a careful analysis
> of fashions.

Amusing that you say that in a period of global warming which will
require more efficient use of rail and shipping.

> Therefore, Big Iron is dead. We should replace it with a server farm

Did't they say that in 1980?. And when did they say that Cobol was
dead?

Richard

2007-12-17, 6:56 pm

On Dec 18, 11:21 am, Alistair <alist...@ld50macca.demon.co.uk> wrote:
> On 14 Dec, 05:54, Richard <rip...@azonic.co.nz> wrote:
>
>
>
> Regrettably, GREP is not available to non-Unix systems. Some of us
> don't have the luxury of using the new-fangled tools to which you have
> access.

grep certainly is available wherever there is a C compiler. Just
download some source code. It is even available prebuilt for CP/M, MS-
DOS, Windows, Mac, Atari. and dozens of others.

I don't understand IBM OS but would have thought that OS/390 Unix
System Services may be like some services that would run on OS/390.

>
>
> What, can't you combine GREP searches? Shame thet EGREP and FGREP
> don't work either. That's so 1980s.

Well, of course you can combine them ,that is why I had put "multiple
greps/searches" where it could be done with multiple greps or multiple
searches [in one grep].

Alistair

2007-12-17, 6:56 pm

On 17 Dec, 20:58, Richard <rip...@azonic.co.nz> wrote:
> On Dec 18, 9:44 am, Howard Brazee <how...@brazee.net> wrote:
>
>
>
>
> Print-out ? you still do printouts ?
>

I don't know about others but I certainly still use print-outs. I find
that it is a lot quicker than transcribing the screen to paper with a
quill and ink.

Richard

2007-12-17, 6:56 pm

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:
>
>
>
>
>
> 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.

>
> 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 ?

>
> 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.

>
>
> 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 ?

>
> 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.

Richard

2007-12-17, 6:56 pm

On Dec 18, 11:41 am, Alistair <alist...@ld50macca.demon.co.uk> wrote:
> On 17 Dec, 18:33, Robert <n...@e.mail> wrote:
>
>
>
>
>
> 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.

Charles Hottel

2007-12-17, 6:56 pm

"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:

<snip>
[color=darkred]
> 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.

Richard

2007-12-17, 6:56 pm

Pete Dashwood

2007-12-17, 6:56 pm

"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:
>
> 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...
[color=darkred]

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."

Pete Dashwood

2007-12-17, 6:56 pm

"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:
>
>
> 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."

2007-12-17, 9:56 pm

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:
>
>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

Richard

2007-12-17, 9:56 pm

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:
>
>
>
>
>
> 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'.

2007-12-17, 9:56 pm

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]

>
>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

2007-12-17, 9:56 pm

In article <52f573e5-d849-4edd-b14d-b36d4a516877@e23g2000prf.googlegroups.com>,
Richard <riplin@azonic.co.nz> wrote:
>On Dec 18, 1:58 pm, docdw...@panix.com () wrote:
>
>Which appears to indicate that you are not prepared to learn anything
>from other languages.

I'll take that as a 'no, I cannot guess what was being discussed at that
time'.

DD

Richard

2007-12-17, 9:56 pm

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...
>
>
> <snip>
>
>
> 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

So you don't actually need the paragraph name to start with a number,
what you need is to identify paragraph labels uniquely. It happens
that you can do with with the convention that col 13 is uniquely a
hyphen. 8-12 could always be "XXXXX" or "LABEL" or even a semi-
meaningful word.

If you identify the paragraph labels by some other mechanism (such as
they are all after 'PROCEDURE' and start in col 8, then there would be
no need even for the cruft that fills the first 6 characters.

> 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.

Often I find that I have to take my whole environment on a laptop
whenever I go 'on site' otherwise I'd waste days getting up to speed
on whatever they have used there for decades.

At one 3 month contract they only delivered a usable machine to my
desk in the last w

because IT had better things to do. They only
got around to it then when they realised that all that I had worked on
would be left on a few floppy disks on the desk when I completed.

Howard Brazee

2007-12-17, 9:56 pm

On Mon, 17 Dec 2007 18:39:57 -0500, "Charles Hottel"
<chottel@earthlink.net> wrote:

>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.

In ISPF, it is easy to find paragraph names if I know they follow such
a standard f p'#' 8

Sometimes an obsolete fashion fits "obsolete" tools and environments.
Changing a style to fit the strengths of an editor that I don't have
is not constructive.

Richard

2007-12-17, 9:56 pm

On Dec 18, 2:11 pm, docdw...@panix.com () wrote:
> In article <5soie6F1a5e4...@mid.individual.net>,
>
> Pete Dashwood <dashw...@removethis.enternet.co.nz> wrote:
>
>
> [snip]
>
>
>
>
> 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?

Actually the 'EIBCALEN code' was an alternate. It used an ELSE and did
one thing _or_ the other. To be similar it should be:

END-IF
PERFORM 5000-PROCESS-INPUT THRU 5000-PI-EX.

Of course one would also need to know that this archaic and arcane
system specific name has externally set value. There would,
presumably, be no setting of EIBCALEN to some other value within the
program, so it is not even similar in its use of 'first time switch'.

How strange that you think it 'similar' at all, let alone expect me to
see it as such through your decades of ingrained cruft.

Perhaps it hasn't occurred to you that the world isn't just a bigger
version of your cubicle.

But I wasn't discussing it because it was similar or not, I was asking
whether you thought that it was an example of your 'Good Style' or
not.

[color=darkred]
> [snip]
>
>
>
> An 88-level? Mr Plinston has raised objections to those, as well... but
> that's for another time, perhaps.

I am not sure why you think that my dislike of 88 levels should be a
burden on Peter.

Richard

2007-12-17, 9:56 pm

On Dec 18, 2:15 pm, docdw...@panix.com () wrote:
> In article <52f573e5-d849-4edd-b14d-b36d4a516...@e23g2000prf.googlegroups.com>,
>
>
>
> Richard <rip...@azonic.co.nz> wrote:
>
>
>
>
>
>
>
>
> I'll take that as a 'no, I cannot guess what was being discussed at that
> time'.

That would not be an answer to the actual question asked.

An actual answer may be: "No, I don't care".

For me, programming is done in the most appropriate language for the
task, discussing how things may be done differently, or similarly,
leads to better solutions in all the languages that I use.

Of course, if you reject other languages out of hand as simply being
'off topic' then you may well believe that 'what you learned in the
60s' was all that is necessary to know.