working storage values
yoqi99
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
news:18bff75d-832d-4089...@a35g2000prf.googlegroups.com...
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
> 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
>
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
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
listm...@gmail.com
ok, thanks dad. next time i will do everything you suggest.
plonk....
William M. Klein
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" <yoq...@gmail.com> wrote in message
news:145804c2-faeb-4437...@y5g2000hsf.googlegroups.com...
Rick Smith
<listm...@gmail.com> wrote in message
news:258ae2a6-31d7-4909...@e23g2000prf.googlegroups.com...
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
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
"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" <yoq...@gmail.com> wrote in message
news:18bff75d-832d-4089...@a35g2000prf.googlegroups.com...
docd...@panix.com
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
> In article <966198db-204f-4634-9c2b-8d21439f6...@o42g2000hsc.googlegroups.com>,
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.
docd...@panix.com
... 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.
>> 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.
>
>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
> In article <6969359c-00e5-4485-9e94-2e0e0acb1...@s12g2000prg.googlegroups.com>,
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 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.
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.
> >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.
Being lazy means that I get the job done with minimum effort.
Certainly this means that the project is completed with fewer billing
hours.
> >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.
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.
> >> 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.
>
> >That, too, is soooo 60s.
>
> See above about Tymelessness.
See above for not noticing what happened elsewhere.
> >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.
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.
docd...@panix.com
[snip]
>> ... 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.
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]
>> >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.
>
>Of course search is available in every text editor.
There's a clever lad... things might be worthy of hope, after all!
[snip]
>> 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.
To 'get the job done' can be accomplished without the least invocation or
use of Good Style, last I looked.
>
>
>> >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.
>
>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]
>> 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.
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
Roger While
<level wahtever> MYFLD PIC ZZZ,Z VALUE ALL '9'.
Equivalent in PROCEDURE -
MOVE ALL '9' TO MYFLD.
AFAIK, num-edits are class alphanumeric and as such current
compilers (tested MF/ACU) produce a value of
99999 in MYFLD. (Which, if I am reading the past/current standards
is correct). This seems to me to me to
be non-intuitive. In fact, OC produces 999,9.
Thoughts?
Roger
William M. Klein
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" <rip...@azonic.co.nz> wrote in message
news:794c0dfd-a161-4f3a...@e6g2000prf.googlegroups.com...
William M. Klein
good example).
As I recall (but haven't checked this recently)
Set 88-level to true
also follows the rules of VALUE clause and not MOVE. (I think there are some
issues with JUSTIFIED as well as all "literal").
--
Bill Klein
wmklein <at> ix.netcom.com
"Roger While" <si...@sim-basis.de> wrote in message
news:fju86o$7rg$02$1...@news.t-online.com...
Richard
> In article <794c0dfd-a161-4f3a-b26f-a30aeb06b...@e6g2000prf.googlegroups.com>,
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.
> >> >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.
>
> >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.
It does not require any effort at all, I never see 'EVALUATE TRUE' so
it is of no concern.
> >> 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.
>
> 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
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.
Robert
13.16.61.2
8) Editing characters in a picture character-string are included in determining the size
of the data item, but do not cause editing of the initial value when the data item is
initialized.
What happens when you INITIALIZE MYFLD TO VALUE? Generally, INITIALIZE follows the rules
for MOVE, which would give 999,9. However, the Standard muddies the waters by saying:
14.8.19.3.6.a.3
The actual sending-operand is a literal that, when moved to the receiving-operand with a
MOVE statement, produces the same result as the initial value of the data item as produced
by the application of the VALUE clause.
The requirement is impossible. There IS NO LITERAL that will produce 99999 when MOVEd to
MYFLD.
I tried it on Fujitsu. VALUE ZERO gives 00000. INITIALIZE MYFLD gives 000,0. This compiler
doesn't support TO VALUE.
Howard Brazee
<rip...@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
You will note that I said 'EVALUATE variable', condition names only
fit where it is 'EVALUATE TRUE' (or FALSE).
William M. Klein
--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <n...@e.mail> wrote in message
news:je56m39r1iar54qgl...@4ax.com...
Robert
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
I just looked farther.
Did you see the note under SR(8) which says,
"NOTE The programmer is responsible for specifying the value of a literal
associated with an alphanumeric-edited,
numeric-edited, or national-edited item in edited form."
Value ALl "9"
may be accepted by compilers (I think many/most do) and they may indeed do what
you say, but the source is not conforming to the Standard, so its rules don't
apply.
If you had
05 Num-Ed Pic 99,999.99 Value "12,345.67".
....
Initialize Num-Edi to Value
then all would work "as defined in the Standard".
--
Bill Klein
wmklein <at> ix.netcom.com
"William M. Klein" <wmk...@nospam.netcom.com> wrote in message
news:WJJ8j.138292$Hq5....@fe04.news.easynews.com...
William M. Klein
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" <n...@e.mail> wrote in message
news:lon6m3didvvp3r6i9...@4ax.com...
Robert
>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
Mainframe systems are hugely EXPENSIVE to the companies that run them. They are hugely
profitable to IBM.
docd...@panix.com
[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.
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.
>> >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.
>
>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]
>> 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.
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
docd...@panix.com
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
> 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
docd...@panix.com
Ahhhhh, the equating of 'costs anything' with 'costs too much!'... I've
seen that a few times, here and there.
DD
Richard
> In article <8731d51b-1604-4c2c-8413-e189158ac...@e25g2000prg.googlegroups.com>,
>
> Richard <rip...@azonic.co.nz> wrote:
> >On Dec 14, 11:18 pm, docdw...@panix.com () wrote:
>
> [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.
>
> 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 ?
> >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.
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.
> >> >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.
>
> >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]
>
> >> 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.
>
> 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
> On Dec 16, 1:28 pm, docdw...@panix.com () wrote:
>> In article
>> <8731d51b-1604-4c2c-8413-e189158ac...@e25g2000prg.googlegroups.com>,
> 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.
Richard
wrote:
> "Richard" <rip...@azonic.co.nz> wrote in message
>
> news:39b46538-277e-4cff...@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' ?
>
> > 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.
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.
docd...@panix.com
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]
>> 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 ?
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]
>> >> 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.
>>
>> 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.
Exactly right, Mr Plinston... a couple here, a couple there, nothing
special whatsoever... remember, I'se jes' a COBOL-codin' fool.
DD
docd...@panix.com
>news:39b46538-277e-4cff...@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' ?
>>
>> 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.
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
Robert
Editing rules are likely to be set at execution time, based on locale. For instance, the
currency symbol and whether to use a period or comma before pennies. If the initial value
followed the rules for MOVE, that would complicate program loading and concievably affect
program logic. I believe the Standard is attempting to avoid that inconvenience.
Howard Brazee
<rip...@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
>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.
docd...@panix.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.
DD
Roger While
"Robert" <n...@e.mail> schrieb im Newsbeitrag
news:cu1dm3131h913ngk0...@4ax.com...
Indeed, I am not disputing that. Moving of alpha-numeric to
numeric(-edited) has always been a bone of contention.
However, one ends up with a maybe not expected value in
the field. Funnily enough this turned up with a user
of OC who did not understand the warning that was given
(and which does not appear with MF/ACU, with highest warning level).
OC does initialization at module load time, not at compile time.
Roger
Robert
>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, 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
>>>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, 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 week.
Richard
> In article <zbm9j.191960$_H4.138...@fe08.news.easynews.com>,
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
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
> In article <u7bdm3tu3vjc5vof12f5mfu48e6einq...@4ax.com>,
It certainly would do in very many languages.
(but you may not have known that).
Richard
> On Mon, 17 Dec 2007 12:33:48 -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, 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?
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.
>
> >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.
I think it was you who claimed 'security' for mainframes. This
security is not inherent in the design but is the result of
administration.
> >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 week.
IBM big iron mainframes certainly are reliable, but so are other
systems.
Howard Brazee
<rip...@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
<rip...@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
<rip...@azonic.co.nz> wrote:
>> 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.
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
> On Mon, 17 Dec 2007 12:15:41 -0800 (PST), Richard
>
> <rip...@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.
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
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
> 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
> On Fri, 14 Dec 2007 00:11:28 +0000 (UTC), docdw...@panix.com () wrote:
> >In article <6969359c-00e5-4485-9e94-2e0e0acb1...@s12g2000prg.googlegroups.com>,
> >Richard <rip...@azonic.co.nz> wrote:
> >>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.
>
> profitable to IBM.
OK Robert: Microsoft or IBM? Whom would you rather get into bed with?
Richard
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
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
> 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, 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
> On Mon, 17 Dec 2007 12:33:48 -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, 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.
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
> 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.
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.
>
> > 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.
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
> 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:
> > >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.
>
> 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
> 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.
Richard
> 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.
Charles Hottel
> 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.
Richard
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.
Pete Dashwood
"Richard" <rip...@azonic.co.nz> wrote in message
news:f810a73e-cd25-43b8...@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...@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."
Pete Dashwood
"Howard Brazee" <how...@brazee.net> wrote in message
news:mqndm3l8eoib57f91...@4ax.com...
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.
docd...@panix.com
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
> In article <93ab7ada-5595-4c0f-ad9d-3c5d77d13...@b1g2000pra.googlegroups.com>,
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'.
docd...@panix.com
Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:
>
>
>"Richard" <rip...@azonic.co.nz> wrote in message
[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
docd...@panix.com
Richard <rip...@azonic.co.nz> wrote:
>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.
I'll take that as a 'no, I cannot guess what was being discussed at that
time'.
DD
Richard
>
> news:879f9d87-cbac-4ebd...@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
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 week 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
<cho...@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
> In article <5soie6F1a5e4...@mid.individual.net>,
Actually the 'EIBCALEN code' was an alternate. It used an ELSE and did
one thing _or_ the other. To be similar it should be:
>> IF EIBCALEN = 0
>> PERFORM 0000-HOUSEKEEPING THRU 0000-HSK-EX
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.
> [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.
I am not sure why you think that my dislike of 88 levels should be a
burden on Peter.
Robert
>
>"Robert" <n...@e.mail> schrieb im Newsbeitrag
>news:cu1dm3131h913ngk0...@4ax.com...
>> On Fri, 14 Dec 2007 16:41:39 +0100, "Roger While" <si...@sim-basis.de>
>wrote:
>>
>> >In W/S (Assuming no DECIMAL-POINT IS COMMA) -
>> ><level wahtever> MYFLD PIC ZZZ,Z VALUE ALL '9'.
>> >
>> >Equivalent in PROCEDURE -
>> >MOVE ALL '9' TO MYFLD.
>> >
>> >AFAIK, num-edits are class alphanumeric and as such current
>> >compilers (tested MF/ACU) produce a value of
>> >99999 in MYFLD. (Which, if I am reading the past/current standards
>> >is correct). This seems to me to me to
>> >be non-intuitive. In fact, OC produces 999,9.
>> >Thoughts?
>>
>> Editing rules are likely to be set at execution time, based on locale. For
>instance, the
>> currency symbol and whether to use a period or comma before pennies. If
>the initial value
>> followed the rules for MOVE, that would complicate program loading and
>concievably affect
>> program logic. I believe the Standard is attempting to avoid that
>inconvenience.
>
>Indeed, I am not disputing that. Moving of alpha-numeric to
>numeric(-edited) has always been a bone of contention.
I would use NUMVAL() to cast alphanumeric to numeric.
>However, one ends up with a maybe not expected value in
>the field. Funnily enough this turned up with a user
>of OC who did not understand the warning that was given
>(and which does not appear with MF/ACU, with highest warning level).
The standard says to treat numeric-edited as alphanumeric when initializing it with VALUE.
>OC does initialization at module load time, not at compile time.
Like an INITIALIZE TO VALUE at load time. They should produce the same value, except for
group level values.
Note that '85 says INITIALIZE does not work on INDEX and POINTER whereas '02 initializes
POINTERs.
Richard
> In article <52f573e5-d849-4edd-b14d-b36d4a516...@e23g2000prf.googlegroups.com>,
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.
Richard
NUMVAL() doesn't 'cast', it converts.
> >However, one ends up with a maybe not expected value in
> >the field. Funnily enough this turned up with a user
> >of OC who did not understand the warning that was given
> >(and which does not appear with MF/ACU, with highest warning level).
>
> The standard says to treat numeric-edited as alphanumeric when initializing it with VALUE.
>
> >OC does initialization at module load time, not at compile time.
>
> Like an INITIALIZE TO VALUE at load time. They should produce the same value, except for
> group level values.
>
> Note that '85 says INITIALIZE does not work on INDEX and POINTER whereas '02 initializes
> POINTERs.
'85 doesn't say anything of the sort. USAGE POINTER is an extension to
'85.
Robert
>On Mon, 17 Dec 2007 12:33:48 -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, 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.
I was answering YOUR claim that z/OS has superior scalability. Unix is much more scalable
AND runs on less expensive platforms.
Using your analogy, an internal combustion engine can propel everything from a bicycle to
a cargo ship. Neither a nuclear power plant nor a coal furnace can scale as well..
>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.
Agreed. There's are lots of quasi-religious beliefs in the computer business.
>Trains, cargo ships, and big iron computers are soooo yesterday.
>Anybody who uses them obviously must not have done a careful analysis
>of fashions.
The topic is cost. Many people who HAVE done a careful analysis of cost dumped mainframes
in favor of Big Unix.
>>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.
I was answering YOUR claim that z/OS has superior security.
>>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 week.
Dial tone was sent by a Unix machine, which used to be in the central office. Now it's
likely to be on a telephone pole (as DLC/DSLAM) or in a closet (as PBX). Try putting a
'scalable' mainframe on a telephone pole.
William M. Klein
news:ac8em35r5od3kqvpl...@4ax.com...<snip>
>
> Note that '85 says INITIALIZE does not work on INDEX and POINTER whereas '02
> initializes
> POINTERs.
Huh ???
Pointers are not IN the '85 Standard, so I don't see how/when it says whether
they are or are not impacted by the INITIALIZE statement.
--
Bill Klein
wmklein <at> ix.netcom.com
Robert
If I HAD to pick one, it would be Microsoft. At least half the things they do are either
good or well intentioned. They had the courage and size to move the industry from text to
GUI screens in 1995. If it were up to IBM, we'd still be using green screens. Their OLE
and later .NET were major improvements in interface standardization, done in a
non-proprietary way. IBM would have made them proprietary.
What has IBM accomplished in the last 25 years? Tivoli and WebSphere are the only ones I
can think of (EJB was IBM's idea, but was developed by Sun). Mostly they played Me Too
with Linux so they could milk the mainframe cash cow longer.
Actually, I WAS in bed with IBM earlier this year, on an eight month project that ended in
two months. A hundred contractors were dismissed without notice. In other shops, I noticed
IBM contractors were always the first to go, because they were the most expensive. Their
bill rate is $200, of which the worker gets maybe $40. They are NOT the best; if anything,
they're below average. Often, the IBM manager doesn't even interview them. Now, IBM is
replacing 20,000 (out of 40,000) Unix machines in their Service Centers with mainframes
running Linux. How much displacement do you think that will cause?
I'm not a Microsoft fan, but I'm not a Microsoft hater either.
Richard
> On Mon, 17 Dec 2007 14:28:07 -0800 (PST), Alistair <alist...@ld50macca.demon.co.uk> wrote:
> >On 15 Dec, 22:09, Robert <n...@e.mail> wrote:
> >> On Fri, 14 Dec 2007 00:11:28 +0000 (UTC), docdw...@panix.com () wrote:
> >> >In article <6969359c-00e5-4485-9e94-2e0e0acb1...@s12g2000prg.googlegroups.com>,
> >> >Richard <rip...@azonic.co.nz> wrote:
> >> >>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.
>
> >> 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?
>
> If I HAD to pick one, it would be Microsoft. At least half the things they do are either
> good or well intentioned.
Half the things they do are bought in products. They bought MSSQL from
Sybase, FrontPage from FrontPage, IE from Spyglass (except they never
paid for it).
It is only '_well_ intentioned' if the intent is to 'make more
billions' and/or drive any competition out of business [ducks chair
thrown across room].
> They had the courage and size to move the industry from text to
> GUI screens in 1995.
Microsoft has never been a leader in anything they did. Before Windows
was released the industry was already moving to GUI with Atari, GEM,
Lisa, Macintosh, PERQ, and many others.
One point to note is that in the first edition of 'The Way Ahead'
there is no mention at all of the internet. 2nd ed. corrected that
while MS tried to build an alternate to the internet, the first MSN.
When everyone ignored that and used Netscape or IBM connect on their
Windows boxes MS had to give in and follow once again. Of course
their PR is such that many think Billy boy invented the internet.
> If it were up to IBM, we'd still be using green screens.
Excuse me, but it was IBM that built the PC. Granted it was to compete
with the Apple ][. It was IBM that brought out multi-tasking OS/2 with
Display Manager that MS stole code from to make Windows/386 work.
> Their OLE
> and later .NET were major improvements in interface standardization, done in a
> non-proprietary way. IBM would have made them proprietary.
In what way is _anything_ that MS does 'non-proprietary' ? MS take
standards and then build in proprietary extensions to lock out
competition. eg the HTML is generated by their products in a non-
standard way so that only IE can display it correctly.
docd...@panix.com
And yet... you spend so much time at it! How very generous of you, Mr
Plinston, and yet still unoriginally seasonal.
DD
docd...@panix.com
That might be why, Mr Plinston, it was described as 'similar' and not
'identical'. The difference between the two might be discenred by those
with access to an English dictionary or a bit of education.
>> To be similar it should be:
>
>>> IF EIBCALEN = 0
>>> PERFORM 0000-HOUSEKEEPING THRU 0000-HSK-EX
> END-IF
> PERFORM 5000-PROCESS-INPUT THRU 5000-PI-EX.
That, to my eye, would change it from similar - having the characteristic
of a first-time-in test in common - to being identical. What
characteristics do you see in your change which prevent this?
DD
Robert
I've been using pointers so long, I forgot for a moment they weren't in the '85 Standard.
The point is, Micro Focus, IBM and Fujitsu do not INITIALIZE pointers, in conflict with
the current '02 Standard.
Richard
> In article <28fef15e-4fb6-475c-935c-1fd98b65a...@e23g2000prf.googlegroups.com>,
"IF a END-IF b". is not 'similar' to "IF a ELSE b END-IF". They are
different structures. Or do you think that all code is 'similar'. You
may even want to claim that a triangle is 'similar' to a square.
> having the characteristic
> of a first-time-in test in common -
That is only because your eye has arcane codes burnt into it. Without
that there is nothing that identifies it as a 'first time-in test'. No
meaningful name to indicate what it is, no isolation of the first-time-
in code, no setting of the flag to prevent rerunning that code.
And more importantly it seems that in your code 'Process-Input' is
_not_ performed when 'Housekeeping' is. This may be a
'initialization' (with no input), or a 'first-time' (is Process-Input'
is performed from Housekeeping) or a 'after-end-of-input', or a
'between inputs'.
You see what you are used to and consistently fail to recognise that
others have different experience.
> to being identical. What
> characteristics do you see in your change which prevent this?
No identification that this is a first-time-in flag.
No resetting of the flag to prevent re-executing the code.
And the code itself is stylistically different, with PERFORM THRU vs
PERFORM.
You haven't denied that you think of this as 'Good Style', yet it
obviously fails the clarity test, except of course to those who
already have been told what it does.
You obviously recognised that _my_ code was 'first-time-in' because I
had deliberately included the characteristics of this to make it
clear: a meaningful name, even to those who don't live with CICS;
explicit initial value; resetting the flag within the IF branch
(rather than externally or in the PERFORMed code); continuing after
the first-time-in with the every-time-in.
Richard
> In article <a2c7c77f-c37a-4388-8e39-790d9f1c9...@s8g2000prg.googlegroups.com>,
I didn't spend any time at all on your question. Nor on guessing. Nor
on attempting to work out what "it was not one
that requires one a verb at the end of a sentence to put." was
supposed to mean.
docd...@panix.com
[snip]
>> And yet... you spend so much time at it!
>
>I didn't spend any time at all on your question.
That's very nice to know, Mr Plinston.
DD
docd...@panix.com
[snip]
>> That, to my eye, would change it from similar -
>
>"IF a END-IF b". is not 'similar' to "IF a ELSE b END-IF".
Mr Plinston, I do not know what you intend by the 's around similar but
when I used the word I intended it as 'having characteristics in common',
as per http://m-w.com/dictionary/similar.
Both structures appear to be covered by
<http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/FRAMESET/IGY3LR10/CCONTENTS?DT=20020920180651>
so it might be best left to The Reader to determine if common
characteristics - hence similarity - exists. You might want to run a
compile or two and inspect the generated Assembley statements to see what
that yields, as well.
DD
Richard
> In article <c939e725-053e-4d3f-a118-39ef3621d...@e6g2000prf.googlegroups.com>,
>
> Richard <rip...@azonic.co.nz> wrote:
> >On Dec 19, 1:37 am, docdw...@panix.com () wrote:
>
> [snip]
>
> >> That, to my eye, would change it from similar -
>
> >"IF a END-IF b". is not 'similar' to "IF a ELSE b END-IF".
>
> Mr Plinston, I do not know what you intend by the 's around similar but
> when I used the word I intended it as 'having characteristics in common',
>
> Both structures appear to be covered by
So, you do agree, by your use of 'both', that they are separate and
distinct structures.
<http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/FRAMESET/
IGY3LR1...>
> so it might be best left to The Reader to determine if common
> characteristics - hence similarity - exists.
As I am one of 'The Reader', I thought that I already had determined
that, with several reasons that you haven't even attempted to refute.
> You might want to run a
> compile or two and inspect the generated Assembley statements to see what
> that yields, as well.
I would be entirely surprised if they didn't both generate some sort
of code. That in itself is a similarity of sorts. But I guarantee that
the code generated by your source (on your system) would be completely
dissimilar to the code generated by my source (on my system).
As your source would not compile on my system (it's not CICS) then
that, too, represents a dissimilarity.
docd...@panix.com
[snip]
>> You might want to run a
>> compile or two and inspect the generated Assembley statements to see what
>> that yields, as well.
>
>I would be entirely surprised if they didn't both generate some sort
>of code. That in itself is a similarity of sorts. But I guarantee that
>the code generated by your source (on your system) would be completely
>dissimilar to the code generated by my source (on my system).
I did not ask for your guarantee, Mr Plinston, I suggested that you might
want to run a compile or two and inspect the generated Assembley
statements. When you have some code to post, feel free to do so.
DD
Richard
> In article <28fef15e-4fb6-475c-935c-1fd98b65a...@e23g2000prf.googlegroups.com>,
I have actually looked up what EIBCALEN is:
"""Re: What does it mean when EIBCALEN is equal to zeros?
Answer
# 1 The Program is Running first time and there is not transfer of
data from program to program."""
It is an initialization with no data. Hence the need for _dissimilar_
logic that bypasses the processing step when initialization is done.
Do you think that 'having data to process' is similar to 'not having
data to process' ?
Richard
> In article <9a268132-fe2a-45e6-b90a-7651a0776...@e10g2000prf.googlegroups.com>,
Well in fact, I don't want to. I have no interest in reading assembly
code to determine what some of your 'Good Style' code is supposed to
do. The fact that you suggest it may be useful says more about your
'Good Style' than I ever could.
The whole point of 'high-level' languages is that one should never
need to look at the assembly code generated for whichever machine the
program is required to run on.
Pete Dashwood
<docd...@panix.com> wrote in message news:fk76nh$9se$1...@reader1.panix.com...
> In article <5soie6F...@mid.individual.net>,
> Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:
>>
>>
>>"Richard" <rip...@azonic.co.nz> wrote in message
>>news:f810a73e-cd25-43b8...@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
<sorry for mid-sentence interruption, but the sentence does go on a bit...
:-)>
No, Doc, I'm not objecting to the test for EIBCALEN being zero; that would
be stupid. It HAS to be tested. What I'm objecting to (and I believe it was
also Richard's objection...) is the WAY in which it is tested. It is not
informative or immediately obvious what the test is for or why it is needed.
To me, it smacks of the old "Well, we are a closed Brotherhood here and if
you don't know CICS you shouldn't be maintaining our code" school of COBOL
Priesthood. That defeats te purpose of COBOL and, at least in my opinion,
demeans the language.
> (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.
Yes, I know Richard doesn't like 88 levels and I understand why he doesn't,
but I don't necessarily share his aversion... :-)
Pete.
--
"I used to write COBOL...now I can do anything."
Pete Dashwood
"Howard Brazee" <how...@brazee.net> wrote in message
news:dd8em3do4luk6tha7...@4ax.com...
As usual, a very apposite observation.
For people who have not worked in the IBM mainframe environment, ((but have
worked in multiple other modern environments) it is really difficult to see
how tools like ISPF (which most mainframe programmers get to know and love)
are so "limited". The fact is (as you pointed out) that they AREN'T limited
to people who are used to working within those particular constraints and
the users don't even see them as "constraining".
This was brought home to me a few days after I made the transition from
using the Fujitsu IDE to using VS 2005 with C#. I had never realised how
much I was actually "constrained" by the old tool, until I was "set free" by
the new one.
Richard
<dashw...@removethis.enternet.co.nz> wrote:
> <docdw...@panix.com> wrote in messagenews:fk76nh$9se$1...@reader1.panix.com...
> > In article <5soie6F1a5e4...@mid.individual.net>,
Looking at your 88 level which has an alleged meaningful name of "New-
Conversation" I now find that it is even less of a 'first-time-in'.
The actual EIBCALEN, I had determined by scanning the documentation,
is the LENgth of some data. That alone just means 'there is some data'
or 'there is no data' without indicating first, last, between, or
random.
Now it would seem, from your name, that it may be zero on many
occasions, or is this routine CANCELled at the end of each
conversation ?
So, even with knowing what EIBCALEN is, and your interpretation of
what it means when zero, it is still not clear, without reading
further documentation, that it is Doc's alleged 'first-time-in' (when
it is actually a separate 'initialization' anyway).
It seems that 'Good Style' is 'whatever deliberately keeps code
obscure'.
docd...@panix.com
Richard <rip...@azonic.co.nz> wrote:
>On Dec 19, 9:18 am, docdw...@panix.com () wrote:
>> In article
><9a268132-fe2a-45e6-b90a-7651a0776...@e10g2000prf.googlegroups.com>,
>>
>> Richard <rip...@azonic.co.nz> wrote:
>> >On Dec 19, 8:50 am, docdw...@panix.com () wrote:
>>
>> [snip]
>>
>> >> You might want to run a
>> >> compile or two and inspect the generated Assembley statements to see what
>> >> that yields, as well.
>>
>> >I would be entirely surprised if they didn't both generate some sort
>> >of code. That in itself is a similarity of sorts. But I guarantee that
>> >the code generated by your source (on your system) would be completely
>> >dissimilar to the code generated by my source (on my system).
>>
>> I did not ask for your guarantee, Mr Plinston, I suggested that you might
>> want to run a compile or two and inspect the generated Assembley
>> statements. When you have some code to post, feel free to do so.
>
>Well in fact, I don't want to.
Then, by all means, don't.
DD
docd...@panix.com
[snip]
>> That, to my eye, would change it from similar - having the characteristic
>> of a first-time-in test in common - to being identical. What
>> characteristics do you see in your change which prevent this?
>
>I have actually looked up what EIBCALEN is:
>
>"""Re: What does it mean when EIBCALEN is equal to zeros?
>Answer
># 1 The Program is Running first time and there is not transfer of
>data from program to program."""
>
>It is an initialization with no data. Hence the need for _dissimilar_
>logic that bypasses the processing step when initialization is done.
>
>Do you think that 'having data to process' is similar to 'not having
>data to process' ?
Not having a 'transfer of data from program to program' might, possibly,
be a bit different than 'not having data to process', Mr Plinston... there
might be sources of data other than another program.
DD
William M. Klein
"Robert" <n...@e.mail> wrote in message
"in conflict" with a Standard they don't claim to support.
OK, the significance of this is ...?
docd...@panix.com
Mr Dashwood, there's a bit of a problem here. You object to 'if you don't
know CICS you shouldn't be maintaining CICS code'... but the alternative
to that is 'if you don't know CICS then you should be able to maintain
CICS code'.
I know of no language which does not require a knowledge of that language
in order to maintain it... what am I missing? I do not know of *any*
CICS training that does not contain a description of EIBCALEN and what its
length has to do with processing... but it has been a few decades since I
was introduced to the concept and perhaps things have changed.
>That defeats te purpose of COBOL and, at least in my opinion,
>demeans the language.
It demeans a language to expect that a maintenance programmer knows
something about it before attempting to maintain code? Again, I see a bit
of a problem; code is to be written - as the Anciente Wisdome has it - so
that a programmer with two years' experience can maintain it, not zero
years.
DD
William M. Klein
news:5sqsffF...@mid.individual.net...
<snip>
> No, Doc, I'm not objecting to the test for EIBCALEN being zero; that would be
> stupid. It HAS to be tested. What I'm objecting to (and I believe it was also
> Richard's objection...) is the WAY in which it is tested. It is not
> informative or immediately obvious what the test is for or why it is needed.
> To me, it smacks of the old "Well, we are a closed Brotherhood here and if you
> don't know CICS you shouldn't be maintaining our code" school of COBOL
> Priesthood. That defeats te purpose of COBOL and, at least in my opinion,
> demeans the language.
>
what is happening in a COBOL program that has
IF EIBCALEN = 0
then I would say that programmer should NOT be "touching" that specific program.
CICS is "arcane" (or at least very specific in its "logic" and "methodology")
and a programmer that doesn't recognize that specific code sequence almost
CERTTAINLY is not one who should be modifying any other part of the particular
program.
It is also worth noting that EIBCALEN is probably (almost certainly?) in a
COPYBOOK that the application programmer cannot "play with" and add 88-levels
to.