Re: MAINFRAME SHOP STANDARDS

..    On  07.12.04
wrote  spamblocker-robert@wagner.net (Robert Wagner)
on  /COMP/LANG/COBOL
in  1laar0hcgea9dt2rchgh69m4p24inmp8rj@4ax.com
about  MAINFRAME SHOP STANDARDS


assuming these standards are genuine ...

Some are OK, some are superflouus and some are really bad.

E.g. those rules that the program has to implement the program
specification in relation to nested or serialized conditional
statements (IF/THEN/ELSE, EVALUATE/WHEN) - what else?

But the rule on EVALUATE:

RW>    For example, if the spec says:
RW>        evaluate true
RW>            when A < B
RW>              ...
RW>            when A = B
RW>              ...
RW>            when A > B
RW>              ...
RW>    write it that way. Do NOT write:
RW>        evaluate A
RW>            when < B
RW>              ...
RW>            when B
RW>              ...
RW>            when > B
RW>              ...

is superflouus since the syntax doesn't allow the "< B" and "> B"
in the second version (if one of those IBM compilers does allow that
non-standard syntax, the rule should simply state to avoid all those
IBM extensions to the standard, or list those which are allowed (there
might be some which make sense).

RW> .. Follow the spec closely.

BTW, if the one writing the specification goes so deep into
details, like this:

RW>    If the spec has nested IFs, do not change them to EVALUATE.

why doesn't that person write the program himself?

Well, maybe because those rules make writing the program so awkward
that nobody wants to do it? There is no need for a coder separate from
the program designer if the rules do not stipulate to duplicate the
work of the compiler and the program designer by the coder.

Like this:

RW> .. No REDEFINES.
RW>
RW> .. No qualification.
RW>
RW> .. File descriptions in copybooks
RW>    One each for Select, FD and record (in working-storage). If a
RW>    file contains multiple record types, for example header and
RW>    trailer, there must be a copybook for each format.
RW>    If two files contain the same format, there must be separate
RW> record copybooks for each file.
RW>
RW> .. No REPLACING.
RW>    If there are six files, there must be six select copybooks,
RW>    six FD copybooks and at least six record copybooks.

RW> .. All working-storage names must be prefixed with ws-, including
RW>    record areas.

The above is just foolish, I dare to say.



while this:

RW> .. No shared File Status code.

should be self-evident, whereas this:

RW>    Code a separate pic xx field for each file.

makes me wonder --- it would be equally self-evident to have the
File Status with all its condition names as a COPY element, but then
one would have to REPLACE parts of it or use qualification ...

Then this:

RW> .. Counters must have unique names.
RW>    Do not use OCCURS. If there are 120 counters, write 120 names.

this should depend if the items being counted are actually a
recurring item, or if there happen to be different items to be counted
separately.

But the following:

RW>    Do not use OCCURS on report lines with columns of numbers.

is again quite foolish. If it _is_ a recurring item, it should be
handled as such.

This makes me think of that famous beginner in programming, who was
give the task of writing a program which had to read in and process a
deck of cards, and who came back after some time asking for the number
of cards in the deck. Since he got the answer "100", he coded 100
separate READ statements in his program....


RW> .. No inline comments.

I understand this to mean introducing comments with "*>" which then
can be everywhere on a line, not just in position 7.

RW> Procedure Division

RW> .. Control checking logic must be procedural rather than
arithmetic.
RW>    For example, when the spec says 'abend when the input is empty',
RW>    you must check for end of file after the first read. Do not count
RW>    the records and test whether the counter is zero.

This probably implies that the normal loop reading a file, i.e.
with a loop which is executed once for every _available_ record, and
not once more, i.e. for every _attempt_ go fetch a record, is not
being used. Proper programming to process a sequential sequence with
unknown number of occurences is
1. try to get first
2. IF no success
leave it
ELSE
REPEAT
process item
try to get next
UNTIL no success
END-IF

which makes the above rule so natural that it would not have to be
mentioned.


RW> .. Paragraph names must begin with a five digit number, which are
RW>    in sequence and indicate logical hierarchy.

My dear goodness. If the logical structure is not clear by the
names of the procedures, then trying to force that into numbers will
fail.

One will inevitably have similar or identical named procedure names
or labels differentiated only by number, which is just confusing and
generating errors.

RW> .. All PERFORMs must be THRU nnnnn-name-EXIT, not nnnnn-EXIT.

My rule was and is, that object of a PERFORM can only be a SECTION,
while labels (called Paragraphs in COBOLese) may only be referenced by
GOTOs, and only within one and the same SECTION, and this only if the
programmer is unable to write the structure properly (well, using a
pre-1985 COBOL it may have been unavoidable sometimes, and did make a
lot of sense in case of a GOTO DEPENDING ON some-integer).


RW> .. No backward PERFORMs.

That makes sense.

And this:

RW> .. Main paragraphs must be named -init, -process and -wrap. Don't
RW>    get creative with names like beginning, middle and end.

is just some arbitrary rule, which standardizes naming.

And the following also makes sense:

RW> .. In conditionals, the literal goes on the right

but for compound conditions ... not necessarily

RW>    Wrong: if zero = ws-imbalance-1 and ws-imbalance-2
RW>    Right: if ws-imbalance-1 = zero and
RW>              ws-imbalance-2 = zero

And I would always write the boolean operator (AND or OR) _before_
the expression it applies to, and not at the end of the previous, i.e.
IF condition-A
AND condition-B

The same as I write
4711
+ 0815

and not 4711 +
0815


The following had already be covered:

RW>    When checking file status, use '00' rather than ZERO.

Better to use a condition name out of the COPY element to be used
for every file status (use it for TYPEDEF with a compiler which
supports it), but this requires qualification ...


The whole sets of rules reflects someone full of fear of losing
control to the compiler, trying to be as close as possible to writing
some assembler, and trying to rule the actual storage bits and bytes
in the machine instead of abstracting from the machine details and
concentrating on the actual objects and their symbolic
representations.

It is a recipe for bad and inefficient programming producing many
errors and forcing extensive and long testing and debugging hours,
days or ws.




Yours
Lüko Willms                                     http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Als er am Kirchhofe vorbei ging, sagte er: Die da können nun sicher sein, da
ß sie nicht mehr gehängt werden, das können wir nicht. -G.C.Lichtenberg

On  7-Dec-2004, l.willms@jpberlin.de (Lueko Willms) wrote:

> RW> .. All working-storage names must be prefixed with ws-, including
> RW>    record areas.
>
>   The above is just foolish, I dare to say.

Foolish in what way?   What kinds of trouble will such a foolish standard le
ad
to?

(There's a difference between a silly standard and a foolish one).

On  7-Dec-2004, l.willms@jpberlin.de (Lueko Willms) wrote:

>    It is a recipe for bad and inefficient programming producing many
> errors and forcing extensive and long testing and debugging hours,
> days or ws.

Could you provide examples of how these silly standards force this?

In article <cp4fk6$t3d$1@peabody.colorado.edu>,
Howard Brazee <howard@brazee.net> wrote:
>
>On  7-Dec-2004, l.willms@jpberlin.de (Lueko Willms) wrote:
> 
>
>Foolish in what way?   What kinds of trouble will such a foolish standard l
ead
>to?
>
>(There's a difference between a silly standard and a foolish one).

Ummmmmm... according to one source they are co-defined or at least
synonymous:

http://www.m-w.com/cgi-bin/dictiona...ionary&va=silly :

3 a : weak in intellect : FOOLISH

http://www.m-w.com/cgi-bin/thesauru...urus&va=foolish

Synonyms SIMPLE 3, asinine, brainless, fatuous, senseless, silly...

DD

On  7-Dec-2004, docdwarf@panix.com wrote:
 
>
> Ummmmmm... according to one source they are co-defined or at least
> synonymous:

Still there are differences between the words.   If you behave foolishly, yo
u
put yourself at risk.

In article <cp4i0d$1f9$1@peabody.colorado.edu>,
Howard Brazee <howard@brazee.net> wrote:
>
>On  7-Dec-2004, docdwarf@panix.com wrote:
> 
>
>Still there are differences between the words.   If you behave foolishly, y
ou
>put yourself at risk.

Well, thanks for clearing that up, Mr Brazee.

DD

On Tue, 7 Dec 2004 14:45:49 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>On  7-Dec-2004, l.willms@jpberlin.de (Lueko Willms) wrote:
> 
>
>Could you provide examples of how these silly standards force this?

move ABLMNR1-CUST-NO to ABLMNX1-CUST-NO.

A typo in the cryptic filename 'qualifier' causes no compilation
error. Data is copied to the wrong place. Compare to:

move CUST-NO in input-record to CUST-NO in output-record.

On 07 Dec 2004 12:18:00 GMT, l.willms@jpberlin.de (Lueko Willms)
wrote:

>.    On  07.12.04
>  wrote  spamblocker-robert@wagner.net (Robert Wagner)
>     on  /COMP/LANG/COBOL

>   But the rule on EVALUATE:
>
>RW>    For example, if the spec says:
>RW>        evaluate true
>RW>            when A < B
>RW>              ...
>RW>            when A = B
>RW>              ...
>RW>            when A > B
>RW>              ...
>RW>    write it that way. Do NOT write:
>RW>        evaluate A
>RW>            when < B
>RW>              ...
>RW>            when B
>RW>              ...
>RW>            when > B
>RW>              ...
>
>   is superflouus since the syntax doesn't allow the "< B" and "> B"
>in the second version (if one of those IBM compilers does allow that
>non-standard syntax, the rule should simply state to avoid all those
>IBM extensions to the standard, or list those which are allowed (there
>might be some which make sense).

It is supported by the current Standard ('02) and the compiler in use.

>  while this:
>
>RW> .. No shared File Status code.
>
>              should be self-evident

It's not self-evident. The Standard does not require separate File
Status codes. Consider:

perform varying file-number from 1 by 1 until file-number > 10
evaluate file-number
when 1 open input file-1
when 2 open input file-2
..
when 10 open output file-10
end-evaluate
if  file-status-1 not equal to zero
display 'open error ' file-status ' on file '
file-name (file-number)
perform abend
end-if
end-evaluate


>RW> .. No inline comments.
>
>   I understand this to mean introducing comments with "*>" which then
>can be everywhere on a line, not just in position 7.

Yes.


>RW> .. Control checking logic must be procedural rather than
>arithmetic.
>RW>    For example, when the spec says 'abend when the input is empty',
>RW>    you must check for end of file after the first read. Do not count
>RW>    the records and test whether the counter is zero.
>
>   This probably implies that the normal loop reading a file, i.e.
>with a loop which is executed once for every _available_ record, and
>not once more, i.e. for every _attempt_ go fetch a record, is not
>being used. Proper programming to process a sequential sequence with
>unknown number of occurences is
>   1. try to get first
>   2. IF no success
>         leave it
>      ELSE
>         REPEAT
>            process item
>            try to get next
>         UNTIL no success
>      END-IF
>
>   which makes the above rule so natural that it would not have to be
>mentioned.

Like this:

perform read-file
if  end-of-file
abort
end-if
perform until end-of-file
process item
perform read-file
end-perform

Not this:

perform read-file
perform until end-of-file
process item
perform read-file
end-perform
if  record-count = 0
abort
end-if

>RW> .. All PERFORMs must be THRU nnnnn-name-EXIT, not nnnnn-EXIT.
>
>   My rule was and is, that object of a PERFORM can only be a SECTION,
>while labels (called Paragraphs in COBOLese) may only be referenced by
>GOTOs, and only within one and the same SECTION, and this only if the
>programmer is unable to write the structure properly

Even Old Style shops avoid GO TO, except to abort.

>RW> .. No backward PERFORMs.
>
>   That makes sense.

Why?

>   The whole sets of rules reflects someone full of fear of losing
>control to the compiler, trying to be as close as possible to writing
>some assembler, and trying to rule the actual storage bits and bytes
>in the machine instead of abstracting from the machine details and
>concentrating on the actual objects and their symbolic
>representations.

Well said. It reflects a way of thinking that solves problems with
brute force rather than abstraction.

>   It is a recipe for bad and inefficient programming producing many
>errors and forcing extensive and long testing and debugging hours,
>days or ws.

A well written program was 900 lines long. Rewritten according to this
standard, it took >2,000 lines.

"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
 news:30rbr0hhhukth2unir0s3kamicavlqk010@
4ax.com...
> On 07 Dec 2004 12:18:00 GMT, l.willms@jpberlin.de (Lueko Willms)
> wrote:
> 
> 
>
> It is supported by the current Standard ('02) and the compiler in use.
>

"partial expressons" in EVALUATE are t NOT by any compiler currently availab
le
for z/OS - but may be for other mainframes.

By the way, as I recall (but could be mistaken on this) Micro Focus implemen
ted
an "early" version of this - and it is slightly different from what was actu
ally
approved in the '02 Standard. I can't remember the DETAILS.  It *might* be t
hat
MF supports:

Evaluate A =
When B

which is NOT valid in the '02 Standard as the selection object needs to star
t
with the relational operator.

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

"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
 news:30rbr0hhhukth2unir0s3kamicavlqk010@
4ax.com...
> On 07 Dec 2004 12:18:00 GMT, l.willms@jpberlin.de (Lueko Willms)
> wrote:
>
<snip>
> 
>
> Even Old Style shops avoid GO TO, except to abort.
>

The *advantage* of PERFORM THRU (with  a compiler that does not yet support 
EXIT
PARAGRAPH/SECTION) is *not* to "abort" (if you mean abort the program) but
rather to do an "imdeiate exit" from the SPECIFIC procedure, i.e.

Perform 123-ABC thru 123-ABC-Exit

123-ABC.
If A = X
If B = Y
Perform 987-XYZ thru 987-XYZ-exit
Go to 123-ABC-Exit
Else
Perform 456-LMN thru 456-LMN-Exit
End-If
Display "Sitl in initial IF TRUE branch"
Else
Compute Q = Y + 3
On size Erorr
Perform 999-Some-Error thru 999-Some-Error-Exit
Go To 123-ABC-Exit
Not on Size Error
Perform 222-Something-Else thru 222-Something-Else-Exit
End-Compute
End-If
Display "all has gone well"