Cobol - Re: MAINFRAME SHOP STANDARDS

Author

Re: MAINFRAME SHOP STANDARDS

Lueko Willms

2004-12-07, 3:55 pm

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

s.

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

Howard Brazee

2004-12-07, 3:55 pm

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

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

Howard Brazee

2004-12-07, 3:55 pm

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 w

s.

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

docdwarf@panix.com

2004-12-07, 3:55 pm

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

Howard Brazee

2004-12-07, 3:55 pm

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, you
put yourself at risk.

docdwarf@panix.com

2004-12-07, 3:55 pm

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, you
>put yourself at risk.

Well, thanks for clearing that up, Mr Brazee.

DD

Robert Wagner

2004-12-07, 3:55 pm

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.

Robert Wagner

2004-12-07, 3:55 pm

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 w

s.

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

William M. Klein

2004-12-07, 3:55 pm

"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 available
for z/OS - but may be for other mainframes.

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

Evaluate A =
When B

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

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

William M. Klein

2004-12-07, 3:55 pm

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

Robert Wagner

2004-12-07, 8:55 pm

On Tue, 07 Dec 2004 19:01:23 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>
>"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
> news:30rbr0hhhukth2unir0s3kamicavlqk010@
4ax.com...
>
>"partial expressons" in EVALUATE are t NOT by any compiler currently available
>for z/OS - but may be for other mainframes.
>
>By the way, as I recall (but could be mistaken on this) Micro Focus implemented
>an "early" version of this - and it is slightly different from what was actually
>approved in the '02 Standard. I can't remember the DETAILS. It *might* be that
>MF supports:
>
> Evaluate A =
> When B
>
>which is NOT valid in the '02 Standard as the selection object needs to start
>with the relational operator.

That appears to be correct. The Standard says the first word must be a
relational operator; M/F does not.

As far as I can tell, both permit this:

Evaluate A
when = B or C > D

Howard Brazee

2004-12-07, 8:55 pm

On 7-Dec-2004, Robert Wagner <spamblocker-robert@wagner.net> wrote:

> 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

What makes one of these superior to the other?

Lots of times a standard just makes it easier for everybody to do maintenance -
if all the programs have the same style. Unless there is compelling reason why
the other style is superior, this reason is good enough to follow the standard.

Lueko Willms

2004-12-07, 8:55 pm

.. Am 07.12.04
schrieb howard@brazee.net (Howard Brazee)
bei /COMP/LANG/COBOL
in cp4fk6$t3d$1@peabody.colorado.edu
ueber Re: MAINFRAME SHOP STANDARDS
[color=darkred]

I meant all of the above, concerning naming conventions for
variables, including unique names for each and every variable,
prohibiting REDEFINES and that stuff.

HB> Foolish in what way?
HB> What kinds of trouble will such a foolish standard lead to?

Maybe I use this word somewhat differently from those whose first
language is English. So please don't nail me on differences between
"foolish" and e.g. "silly" (Silly was a Rock band in East Berlin).

Coming back to naming variables -- what this shop standard
stipulates is to manage the machine storage space, finding a unique
name for each and every storage address, instead of caring about
identifying _objects,_ real objects or symbolic representations of
them.

Main storage space is administered by the compiler and the run time
system, including the operating system, and should not concern the
programmer. Otherwise, her or his attention is turned away from the
_real_ task toward tasks better done by the compiler.

Look at what this shop standards which we are talking about
specified for file status and qualification. While I get a shudder
thinking that anybody could think of specifying the same status
variable for different files, the file status should not be coded anew
for each and every program, but included via COPY with REPLACING the
name, or better by COPYing once the definition as a TYPEDEF and using
that TYPE repeatedly.

Like this one which I made up for my use:

000010 01 FILESTAT .
000020*> FILESTAT sollte beim COPY durch passenden Namen REPLACEd werden
000030 88 File-Status-OK VALUE '00'.
000040 02 Major PIC X.
000050 88 is-Successful-completed VALUE '0'.
000060 88 has-reached-at-end VALUE '1'.
000070 88 has-invalid-key VALUE '2'.
000080 88 has-permanent-error VALUE '3'.
000090 88 has-logical-error VALUE '4'.
000100 88 has-record-lock-problem VALUE '5'. *> ab Standard 2002 und X/Open
000110 88 has-file-lock-problem VALUE '6'. *> ab Standard 2002 und X/Open
000120 88 has-implementor-defined-condition VALUE '9'.
000130 02 Minor PIC X.
000140 88 has-no-further-information VALUE '0'.
000150 88 it-just-didnt-work VALUE '1'.
000160 88 has-duplicate-key-error VALUE '2'.
000170 88 has-record-not-available VALUE '3'.
000180 88 has-boundary-violation VALUE '4'.
000190 88 is-not-present-file-or-recdesc VALUE '5'.
000200 88 has-sequence-error VALUE '6'.
000210 88 has-some-incompatability VALUE '7', '8', '9'.
000220

The name FILESTAT has to be REPLACED by the actual name (or, leave
that name out, and let them write "01 input-file-status COPY .... ",
also verboten); and then one has of course to qualify the condition
names for the actual file status, like a "IF has-reached-at-end OF
input-file-status" or so.

Whenever the same object occurs in different structures, e.g. in
different files, in a SCREEN definition etc, it should have the same
outspoken name, which of course need to be qualified.

Naming variables is to identify objects, not main storage
locations. To do it otherwise, one is led astray from the actual task
of devising a transformation algorithm from one set of symbolic
representations of reality to a different set. This is best done by
just specifying the rules governing this transformation, and not by
worrying about locations in the main memory of the machine which is
being used to actually execute that transformation.

Think of that transformation as manipulation of an n-dimensional
vector space. And don't try to do the work of the compiler.

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

"Es sind nicht die Generäle und Könige, die die Geschichte machen,
sondern die breiten Massen des Volkes" - Nelson Mandela

Joe Zitzelberger

2004-12-08, 3:55 am

I would call the ability to do an immediate exit a di

vantage.

It only encourage programmers to take a lazy approach to structure and
promotes paragraphs that become large and unwieldy.

One memorable error went something like this:

1234-ABC.

... dozens of lines ...

If A = B
continue
Else
Go To 1234-Exit
End-If

... dozens more lines ...

If A = B
continue
Else
Perform 5678-Do-Stuff thru 5678-Exit
End-If

... dozens more lines ...

1234-Exit
Exit.

The critical 5678-Do-Stuff was, of course, never executed.

Early bail-outs only encourage people to write things like the above.

In article <8entd.4272126$yk.643554@news.easynews.com>,
"William M. Klein" <wmklein@nospam.netcom.com> wrote:

> "Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
> news:30rbr0hhhukth2unir0s3kamicavlqk010@
4ax.com...
> <snip>
>
> 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"
> .
> 123-ABC-Exit.
> Exit
>
> ***
>
> Of course there ARE other ways this same "logic" could be structured (and I
> haven't compiled it - so I may have made a type that the COMPILER would have
> caught).

Joe Zitzelberger

2004-12-08, 3:55 am

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, you
> put yourself at risk.

Perhaps you put yourself at risk of looking silly?

Robert Wagner

2004-12-08, 3:55 am

On Tue, 7 Dec 2004 20:16:07 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>
>On 7-Dec-2004, Robert Wagner <spamblocker-robert@wagner.net> wrote:
>
>
>What makes one of these superior to the other?
>
>Lots of times a standard just makes it easier for everybody to do maintenance -
>if all the programs have the same style. Unless there is compelling reason why
>the other style is superior, this reason is good enough to follow the standard.

This was a simplified example. Suppose there were four input files,
each having several control checks -- record count, hash, etc. I
prefer to put all control validation in one place rather than
scatterred through the program.

Lueko Willms

2004-12-08, 8:55 am

.. Am 07.12.04
schrieb spamblocker-robert@wagner.net (Robert Wagner)
bei /COMP/LANG/COBOL
in 30rbr0hhhukth2unir0s3kamicavlqk010@4ax.com
ueber Re: MAINFRAME SHOP STANDARDS
[color=darkred]

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

Not everything wich the syntax-check lets pass, does make sense.
The file status is an attribute of the file, not of the program, so
each and every file should have its own file status attribut,
separated from all other files.

RW> if file-status-1 not equal to zero
RW> display 'open error ' file-status ' on file '
RW> file-name (file-number)

*> One could as well write

display 'open error ' file-status(file-number) ' on file '
file-name (file-number)

*> i.e. when file-names are indexed,
*> one might index the file-status as well.

*> or
CALL 'EXPFSTAT'
USING file-name(file-number) file-status(file-number)

*> in case table items are allowed as CALL parameters

RW> perform abend
RW> end-if

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

at least.
[color=darkred]

RW> Why?

Because there is a top-down hierarchical structure of a COBOL
program where execution starts with the first executable instruction
in the first SECTION following DECLARATIVES. Recursive PERFORMing is
not allowed.

So I think it is reasonable to organize the program text in a
hierarchical fashion, starting with the main SECTION, and putting any
SECTION being PERFORMed below (in text direction) of the SECTION from
where it is called.

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

"Nach meiner Ansicht besitzt die Presse _das_ _Recht_,
Schriftsteller, Politiker, Komödianten und andere öffentliche
Charaktere zu _beleidigen_. Achtete ich [so einen Angriff gegen mich]
einer Notiz wert, so galt mir in solchen Fällen der Wahlspruch: à
corsaire, corsaire et demi [auf einen Schelmen anderthalben]."
- Karl Marx 17.11.1860 (Herr Vogt, Kapitel XI)

Lueko Willms

2004-12-08, 8:55 am

.. Am 07.12.04
schrieb spamblocker-robert@wagner.net (Robert Wagner)
bei /COMP/LANG/COBOL
in 30rbr0hhhukth2unir0s3kamicavlqk010@4ax.com
ueber Re: MAINFRAME SHOP STANDARDS
[color=darkred]

RW> Like this:
RW>
RW> perform read-file
RW> if end-of-file
RW> abort
RW> end-if
RW> perform until end-of-file
RW> process item
RW> perform read-file
RW> end-perform

Not quite, do it this way, as explained above in an abstract
notation:

perform read-file
if end-of-file
tell-user *> why abort? A gentle way to pass
*> the information would be preferred.
ELSE *> !!!!!!!!!!!!!!!!
perform until end-of-file
process item
perform read-file
end-perform
END-IF

See the difference?

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

"Die Interessen der Nation lassen sich nicht anders formulieren als unter
dem Gesichtspunkt der herrschenden Klasse oder der Klasse, die die
Herrschaft anstrebt." - Leo Trotzki (27. Januar 1932)

Lueko Willms

2004-12-08, 8:55 am

.. Am 07.12.04
schrieb wmklein@nospam.netcom.com (William M. Klein)
bei /COMP/LANG/COBOL
in 8entd.4272126$yk.643554@news.easynews.com
ueber Re: MAINFRAME SHOP STANDARDS

WMK> The *advantage* of PERFORM THRU

can there be an advantage?

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

Whow, another piece of bad programming -- mixing proper structure
with hopping around in the computer's memory.

Delete all those GOTO, which are only there "to confuse the
Russians", but in reality more the programmer her- or himself:

The exception is the "DISPLAY 'all has gone well'" -- well, one may
have to think deeper about all those other actions and conditions.

Perform ABC

ABC SECTION.
ANFANG.
If A = X
If B = Y
Perform 987-XYZ thru 987-XYZ-exit
Else
Perform 456-LMN thru 456-LMN-Exit
Display "Sitl in initial IF TRUE branch"
End-If
Else
Compute Q = Y + 3
On size Erorr
Perform 999-Some-Error thru 999-Some-Error-Exit
Not on Size Error
Perform 222-Something-Else
thru 222-Something-Else-Exit
End-Compute
End-If
*> ........................................

Display "all has gone well"

Do you see any significant difference, except that it is much
easier to understand, and the sense of the final DISPLAY cannot (by
me) understood without seeing more of the context?

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

"Es sind nicht die Generäle und Könige, die die Geschichte machen,
sondern die breiten Massen des Volkes" - Nelson Mandela

Robert Wagner

2004-12-08, 8:55 am

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

>. Am 07.12.04
> schrieb spamblocker-robert@wagner.net (Robert Wagner)
> bei /COMP/LANG/COBOL
> in 30rbr0hhhukth2unir0s3kamicavlqk010@4ax.com
> ueber Re: MAINFRAME SHOP STANDARDS
>
>
>RW> Like this:
>RW>
>RW> perform read-file
>RW> if end-of-file
>RW> abort
>RW> end-if
>RW> perform until end-of-file
>RW> process item
>RW> perform read-file
>RW> end-perform
>
> Not quite, do it this way, as explained above in an abstract
>notation:
>
> perform read-file
> if end-of-file
> tell-user *> why abort? A gentle way to pass
> *> the information would be preferred.
> ELSE *> !!!!!!!!!!!!!!!!
> perform until end-of-file
> process item
> perform read-file
> end-perform
> END-IF
>
>
> See the difference?

Mine was a batch program. The way to tell-user is log a message and
abort.

Robert Wagner

2004-12-08, 8:55 am

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

>. Am 07.12.04
> schrieb spamblocker-robert@wagner.net (Robert Wagner)
> bei /COMP/LANG/COBOL
> in 30rbr0hhhukth2unir0s3kamicavlqk010@4ax.com
> ueber Re: MAINFRAME SHOP STANDARDS
>
>
>RW> It's not self-evident. The Standard does not require separate File
>RW> Status codes.
>
> Not everything wich the syntax-check lets pass, does make sense.
>The file status is an attribute of the file, not of the program, so
>each and every file should have its own file status attribut,
>separated from all other files.

The program can access one file at a time. It will check the status
_immediately_ after the I/O. There is no reason to retain it after it
has been checked.

I've been using one File Status for 20 years. It's never caused a
problem.

>RW> if file-status-1 not equal to zero
>RW> display 'open error ' file-status ' on file '
>RW> file-name (file-number)
>
> *> One could as well write
>
> display 'open error ' file-status(file-number) ' on file '
> file-name (file-number)
>
> *> i.e. when file-names are indexed,
> *> one might index the file-status as well.

It's not so easy. When SELECT is in a copybook, it doesn't know which
subscript to use. REPLACING could be used, but why?

docdwarf@panix.com

2004-12-08, 3:55 pm

In article <t8hdr0p5lucbaek36th03t4ch3ulb7lpap@4ax.com>,
Robert Wagner <spamblocker-robert@wagner.net> wrote:
>On 08 Dec 2004 07:09:00 GMT, l.willms@jpberlin.de (Lueko Willms)
>wrote:
>
>
>The program can access one file at a time. It will check the status
>_immediately_ after the I/O. There is no reason to retain it after it
>has been checked.
>
>I've been using one File Status for 20 years. It's never caused a
>problem.

Bingo... other people, Mr Wagner, have been using multiple File Statuses
for *forty* years... does that make their practises twice as 'best'?

DD

Robert Wagner

2004-12-08, 3:55 pm

On 8 Dec 2004 05:27:27 -0500, docdwarf@panix.com wrote:

>In article <t8hdr0p5lucbaek36th03t4ch3ulb7lpap@4ax.com>,
>Robert Wagner <spamblocker-robert@wagner.net> wrote:
>
>Bingo... other people, Mr Wagner, have been using multiple File Statuses
>for *forty* years... does that make their practises twice as 'best'?

If it was called VSAM Return Code rather than File Status, people
would see it as singular rather than plural. Perception is in
terminology.

docdwarf@panix.com

2004-12-08, 3:55 pm

In article <uuber0dph5cv5bcr24dng06geraqol0k42@4ax.com>,
Robert Wagner <spamblocker-robert@wagner.net> wrote:
>On 8 Dec 2004 05:27:27 -0500, docdwarf@panix.com wrote:
>
>
>If it was called VSAM Return Code rather than File Status, people
>would see it as singular rather than plural.

Conjecture, Mr Wagner; if it were so easy to predict how 'people would
see' things then there might not be the complaint of 'Half the money I
spend on advertising is wasted... now if I only knew *which* half!'

>Perception is in
>terminology.

Those without language cannot perceive, then? Second request, Mr Wagner:
other people have been using multiple File Statuses for *forty* years...
does that make their practises twice as 'best'?

DD

William M. Klein

2004-12-08, 3:55 pm

"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
news:t8hdr0p5lucbaek36th03t4ch3ulb7lpap@
4ax.com...
> On 08 Dec 2004 07:09:00 GMT, l.willms@jpberlin.de (Lueko Willms)
> wrote:
>
>
> The program can access one file at a time. It will check the status
> _immediately_ after the I/O. There is no reason to retain it after it
> has been checked.
>
> I've been using one File Status for 20 years. It's never caused a
> problem.
>

Robert,
You also implied (or I inferred) that you didn't like a standard that required
that you couldn't have multiple statements on the same line.

However, you have previously indicated that you "didn't like"

Open Input File-1 File-2
Output File-3

which is perfectly VALID COBOL - and would cause problems with having a single
file status field.

You would also have problems with a SORT or MERGE statement - without
Input/Output Procedures.

Obviously, you have never used either of these (or haven't checked file status
fields) in the last 20 years - which is fine for you, but is restrictive (IMO)
and not something that I would REQUIRE others to follow.

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

William M. Klein

2004-12-08, 3:55 pm

My example was contrived and I think (hope) I indicated it could be restructured
in many other ways.

The most common place where I have seen (IMHO) "good" usage of the "get me out
quick" technique is in a single procedure that does "field validation" of
several input fields (from a "character based" screen). In these cases, the
FIRST field (usually checked from the bottom of the screen up) that has an error
causes an error message to be issued - then the program logic "exits" the entire
routine (as there is no need to check further). This CAN be done by "deeply
nested" IF statements - but I (personally) find that LESS maintainable.

This is, however, (again in my opinion) a style matter - not a "best practice"
(for all programmers and all shops) matter.

--
Bill Klein
wmklein <at> ix.netcom.com
"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9MVCe4KPflB@jpberlin-l.willms.jpberlin.de...
>. Am 07.12.04
> schrieb wmklein@nospam.netcom.com (William M. Klein)
> bei /COMP/LANG/COBOL
> in 8entd.4272126$yk.643554@news.easynews.com
> ueber Re: MAINFRAME SHOP STANDARDS
>
> WMK> The *advantage* of PERFORM THRU
>
> can there be an advantage?
>
> WMK> (with a compiler that does not yet support EXIT PARAGRAPH
> WMK> /SECTION) is *not* to "abort" (if you mean abort the
> WMK> program) but rather to do an "imdeiate exit" from the SPECIFIC
> WMK> procedure, i.e.
>
> Whow, another piece of bad programming -- mixing proper structure
> with hopping around in the computer's memory.
>
> Delete all those GOTO, which are only there "to confuse the
> Russians", but in reality more the programmer her- or himself:
>
> The exception is the "DISPLAY 'all has gone well'" -- well, one may
> have to think deeper about all those other actions and conditions.
>
>
> Perform ABC
>
> ABC SECTION.
> ANFANG.
> If A = X
> If B = Y
> Perform 987-XYZ thru 987-XYZ-exit
> Else
> Perform 456-LMN thru 456-LMN-Exit
> Display "Sitl in initial IF TRUE branch"
> End-If
> Else
> Compute Q = Y + 3
> On size Erorr
> Perform 999-Some-Error thru 999-Some-Error-Exit
> Not on Size Error
> Perform 222-Something-Else
> thru 222-Something-Else-Exit
> End-Compute
> End-If
> *> ........................................
>
> Display "all has gone well"
>
>
>
> Do you see any significant difference, except that it is much
> easier to understand, and the sense of the final DISPLAY cannot (by
> me) understood without seeing more of the context?
>
>
>
> Yours,
> Lüko Willms http://www.mlwerke.de
> /--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
>
> "Es sind nicht die Generäle und Könige, die die Geschichte machen,
> sondern die breiten Massen des Volkes" - Nelson Mandela

Robert Wagner

2004-12-08, 8:55 pm

On Tue, 07 Dec 2004 19:01:23 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>"partial expressons" in EVALUATE are t NOT by any compiler currently available
>for z/OS - but may be for other mainframes.
>
>By the way, as I recall (but could be mistaken on this) Micro Focus implemented
>an "early" version of this - and it is slightly different from what was actually
>approved in the '02 Standard. I can't remember the DETAILS. It *might* be that
>MF supports:
>
> Evaluate A =
> When B
>
>which is NOT valid in the '02 Standard as the selection object needs to start
>with the relational operator.

Partial expressions solve the problem of testing for multiple values.
Under '85 Cobol, we wrote:

evaluate A
when 1
when 2
when 3
perform B

I wish I had a nickel for every time I've seen:

evaluate A
when 1
perform B
when 2
perform B
when 3
perform B

Under '02 and current Micro Focus, we can write:

evaluate A
when = 1 or 2 or 3
perform B

Lueko Willms

2004-12-08, 8:55 pm

.. On 08.12.04
wrote spamblocker-robert@wagner.net (Robert Wagner)
on /COMP/LANG/COBOL
in 4hoer0hkdec0fsh8ij91p8v24538nt8h03@4ax.com
about Re: MAINFRAME SHOP STANDARDS

RW> Partial expressions solve the problem of testing for multiple values.
RW> Under '85 Cobol, we wrote:
RW>
RW> evaluate A
RW> when 1
RW> when 2
RW> when 3
RW> perform B

This is the same like in C, or the good old GOTO DEPENDING ON A

RW> Under '02 and current Micro Focus, we can write:
RW>
RW> evaluate A
RW> when = 1 or 2 or 3
RW> perform B

And? Is that progress?

I don't think so multiplying the various ways one can make errors
is not a good thing, in my humble view.

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

Seine Bücher waren alle sehr nett, sie hatten auch sonst wenig zu tun. -G.C.Lichtenberg

Robert Wagner

2004-12-08, 8:55 pm

On 8 Dec 2004 12:21:43 -0500, docdwarf@panix.com wrote:

>In article <uuber0dph5cv5bcr24dng06geraqol0k42@4ax.com>,
>Robert Wagner <spamblocker-robert@wagner.net> wrote:

>
>Conjecture, Mr Wagner; if it were so easy to predict how 'people would
>see' things then there might not be the complaint of 'Half the money I
>spend on advertising is wasted... now if I only knew *which* half!'

ESQL returns a single SQLCODE. They could have designed it so each
statement returned a separate one:

select surname into :ws-surname from person where personid =
:ws-personid STATUS IN :ws-status-07;

If they had, Cobol shops would have formed elaborate rules specifying
how to name them, avoid collisions, etc. There would be debates on the
best way to do it. If I said it was pointless, all you need is a
single SQLCODE, people would scoff. They'd say 'We've been receiving
separate codes for 40 years. That proves we're right.'

> Second request, Mr Wagner:
>other people have been using multiple File Statuses for *forty* years...
>does that make their practises twice as 'best'?

Sure it does, in their minds.

Robert Wagner

2004-12-08, 8:55 pm

On Wed, 08 Dec 2004 19:24:41 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>
>"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
> news:t8hdr0p5lucbaek36th03t4ch3ulb7lpap@
4ax.com...
>
>Robert,
> You also implied (or I inferred) that you didn't like a standard that required
>that you couldn't have multiple statements on the same line.

I wasn't thinking of multiple I/O statements.

>However, you have previously indicated that you "didn't like"
>
>Open Input File-1 File-2
> Output File-3
>
>which is perfectly VALID COBOL - and would cause problems with having a single
>file status field.

Would you also advocate:

read file-1
read file-2
read file-3

if file-1-status not = zero
display 'Something wrong with file-1'
end-if
if file-2-status not = zero
display 'Something wrong with file-2'
....

If not, what's the difference?

>You would also have problems with a SORT or MERGE statement - without
>Input/Output Procedures.

I'd use a sort utility.

>Obviously, you have never used either of these (or haven't checked file status
>fields) in the last 20 years - which is fine for you, but is restrictive (IMO)
>and not something that I would REQUIRE others to follow.

I don't advocate requiring either style. The standard REQUIRES
separate fields.

The only advantage of "Open Input File-1 File-2" is that it saves
typing the word Input. Let's see which style really saves typing:

perform varying f from 1 by 1 until f > 9
evaluate f
when 1 open input File-1
when 2 open input File-2
when 3 open input File-3
when 4 open input File-4
when 5 open input File-5
when 6 open input File-6
when 7 open output File-7
when 8 open output File-8
when 9 open output File-9
end-evaluate
if File-Status not equal to zero
display 'Error' File-Status ' opening File ' f
perform ...
end-if
end-perform

Line count: 17

Open Input File-1 File-2 file-3 File-4 File-5 File-6
Output File-7 File-8 File-9
if File-Status-1 not equal to zero
display 'Error ' File-Status-1 ' opening File 1'
perform ....
end-if
if File-Status-2 not equal to zero
display 'Error ' File-Status-2 ' opening File 2'
perform ....
end-if
if File-Status-3 not equal to zero
display 'Error ' File-Status-3 ' opening File 3'
perform ....
end-if
if File-Status-4 not equal to zero
display 'Error ' File-Status-4 ' opening File 4'
perform ....
end-if
if File-Status-5 not equal to zero
display 'Error ' File-Status-5 ' opening File 5'
perform ....
end-if
if File-Status-6 not equal to zero
display 'Error ' File-Status-6 ' opening File 6'
perform ....
end-if
if File-Status-7 not equal to zero
display 'Error ' File-Status-7 ' opening File 7'
perform ....
end-if
if File-Status-8 not equal to zero
display 'Error ' File-Status-8 ' opening File 8'
perform ....
end-if
if File-Status-9 not equal to zero
display 'Error ' File-Status-9 ' opening File 9'
perform ....
end-if

Line count: 38

LX-i

2004-12-09, 3:55 am

Robert Wagner wrote:
>
> Partial expressions solve the problem of testing for multiple values.
> Under '85 Cobol, we wrote:
>
> evaluate A
> when 1
> when 2
> when 3
> perform B

This is good... If 2 becomes no longer a condition under which B needs
to be performed, it can be deleted.

> I wish I had a nickel for every time I've seen:
>
> evaluate A
> when 1
> perform B
> when 2
> perform B
> when 3
> perform B

I used to do this, then I learned about the technique above. (In fact,
I believe it was a question in this very newsgroup which enlightened
me.) I'm sure this is just a contrived example, but under 85 COBOL, you
could also say

evaluate A
when 1 thru 3
perform B

> Under '02 and current Micro Focus, we can write:
>
> evaluate A
> when = 1 or 2 or 3
> perform B

Hmm... Not sure I'm crazy about that, but if it compiles, more power to
ya'... :)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

Lueko Willms

2004-12-09, 8:55 am

.. On 08.12.04
wrote spamblocker-robert@wagner.net (Robert Wagner)
on /COMP/LANG/COBOL
in ab3fr0lh6hirba0sl9rkkboogh7uba6e6m@4ax.com
about Re: MAINFRAME SHOP STANDARDS

RW> ESQL returns a single SQLCODE. They could have designed it so each
RW> statement returned a separate one:

No, there is a single database. This is different from working with
several separate files.

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

Wir wohnen in Göttingen in Scheiterhaufen, die mit Türen und Fenstern versehen sind. -G.C.Lichtenberg

Lueko Willms

2004-12-09, 8:55 am

.. On 09.12.04
wrote spamblocker-robert@wagner.net (Robert Wagner)
on /COMP/LANG/COBOL
in d25fr05jn00dq46hr7aapehdc73au1kli2@4ax.com
about Re: MAINFRAME SHOP STANDARDS

RW> Open Input File-1 File-2 file-3 File-4 File-5 File-6
RW> Output File-7 File-8 File-9

I wonder about that scenario where it would make sense to open 9
files at once. Could you explain?

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

Das Buch, das in der Welt am ehesten verboten zu werden verdiente, wäre ein Katalogus von verbotenen Büchern. -G.C.Lichtenberg

Joe Zitzelberger

2004-12-09, 3:55 pm

In article <9MZNO$neflB@jpberlin-l.willms.jpberlin.de>,
l.willms@jpberlin.de (Lueko Willms) wrote:

> . On 09.12.04
> wrote spamblocker-robert@wagner.net (Robert Wagner)
> on /COMP/LANG/COBOL
> in d25fr05jn00dq46hr7aapehdc73au1kli2@4ax.com
> about Re: MAINFRAME SHOP STANDARDS
>
>
> RW> Open Input File-1 File-2 file-3 File-4 File-5 File-6
> RW> Output File-7 File-8 File-9
>
> I wonder about that scenario where it would make sense to open 9
> files at once. Could you explain?

Just to chime in with an example -- my shop gets a lot of help from
parallel jobs.

We have almost half a billion accounts on file. So to make processes
run faster we will often hash the files into groups based on the IMS
area it falls into.

Then separate jobs can be started for each IMS area to accomplish the
processing.

The reverse is also needed. Sometimes we take group output and merge it
all together...

When doing this via Cobol, one needs to allow for up to 240 areas which
is some old limit of IMS. The current versions support 2000 areas, but
the process wasdesigned before they did.

Lueko Willms

2004-12-09, 3:55 pm

.. On 09.12.04
wrote joe_zitzelberger@nospam.com (Joe Zitzelberger)
on /COMP/LANG/COBOL
in joe_zitzelberger-BF5DFE.08565509122004@knology.usenetserver.com
about Re: MAINFRAME SHOP STANDARDS

[color=darkred]

JZ> Just to chime in with an example

thank you

JZ> -- my shop gets a lot of help from parallel jobs.

I would understand the concept of "parallel" jobs to mean that
several jobs run in parallel, each processing a file. In COBOL itself,
parallell processing is not possible, at least by the standard (I know
of two implementations which do implement what they call "asynchronous
processing").

JZ>
JZ> We have almost half a billion accounts on file.

A phone company?

JZ> So to make processes run faster we will often hash the files into
JZ> groups based on the IMS area it falls into.

If I only knew what an IMS area is. ...

JZ> Then separate jobs can be started for each IMS area to accomplish the
JZ> processing.
JZ>
JZ> The reverse is also needed. Sometimes we take group output and merge
JZ> it all together...

More a SORT/MERGE-process?

JZ> When doing this via Cobol, one needs to allow for up to 240 areas
JZ> which is some old limit of IMS. The current versions support 2000
JZ> areas, but the process was designed before they did.

Again, what is meant by these areas?

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

A. Der Mann hat viele Kinder. B. Ja, aber ich glaube, von den meisten hat er bloß die Korrektur besorgt. -G.C.Lichtenberg

Robert Wagner

2004-12-09, 3:55 pm

Robert Wagner

2004-12-09, 3:55 pm

On 09 Dec 2004 06:25:00 GMT, l.willms@jpberlin.de (Lueko Willms)
wrote:

>. On 08.12.04
> wrote spamblocker-robert@wagner.net (Robert Wagner)
> on /COMP/LANG/COBOL
> in ab3fr0lh6hirba0sl9rkkboogh7uba6e6m@4ax.com
> about Re: MAINFRAME SHOP STANDARDS
>
>
>RW> ESQL returns a single SQLCODE. They could have designed it so each
>RW> statement returned a separate one:
>
> No, there is a single database. This is different from working with
>several separate files.

A program can connect to multiple databases.

Frederico Fonseca

2004-12-09, 3:55 pm

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

>. On 09.12.04
> wrote spamblocker-robert@wagner.net (Robert Wagner)
> on /COMP/LANG/COBOL
> in d25fr05jn00dq46hr7aapehdc73au1kli2@4ax.com
> about Re: MAINFRAME SHOP STANDARDS
>
>
>RW> Open Input File-1 File-2 file-3 File-4 File-5 File-6
>RW> Output File-7 File-8 File-9
>
> I wonder about that scenario where it would make sense to open 9
>files at once. Could you explain?

Many many cases.

Let's see one example that comes to mind.

Insurance software.
1- Links file (holds the relation between diff numbers used on the
other files.
2- Master Person file
2- Person insurance details
3- Person physical details (address and so on)
4- Scheme file
5- Scheme Category file
6- Policy file
7- Coverage details file
8- Coverage amounts file
9- Policy fund selection file
10- Unit totals file
11- Unit movements file
12- Fund switch file
13- Fund calculation file
14- Generic tables file
15- Accounts file
16- Error reporting file
17- Exception reporting file
18- Softlock file
19- Unit exclusion file

This particular program still has more files but I don't remember
them.

The program isn't even medium size, just around 7/8 thousand lines
excluding file layout copybooks.
>
>
>Yours,
>Lüko Willms http://www.willms-edv.de
>/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
>
>Das Buch, das in der Welt am ehesten verboten zu werden verdiente, wäre ein Katalogus von verbotenen Büchern. -G.C.Lichtenberg

Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

Lueko Willms

2004-12-09, 8:55 pm

.. On 09.12.04
wrote real-email-in-msg-spam@email.com (Frederico Fonseca)
on /COMP/LANG/COBOL
in pd3hr05k0s989uqh9mfcug5f6bk29ici39@4ax.com
about Re: MAINFRAME SHOP STANDARDS

[color=darkred]

FF> Let's see one example that comes to mind.
FF>
FF> Insurance software.
FF> 1- Links file (holds the relation between diff numbers used on the
FF> other files.
FF> 2- Master Person file
FF> 2- Person insurance details
FF> 3- Person physical details (address and so on)
FF> 4- Scheme file
FF> 5- Scheme Category file

and so on.

That is a database.

But why is this database in individual flat files which are kept
together only by the programs working on them, instead of in a real
database system which can take care of referencial integrity and so
on?

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

Die Wörter-Welt. -G.C.Lichtenberg

Frederico Fonseca

2004-12-09, 8:55 pm

On 09 Dec 2004 21:48:00 GMT, l.willms@jpberlin.de (Lueko Willms)
wrote:

>. On 09.12.04
> wrote real-email-in-msg-spam@email.com (Frederico Fonseca)
> on /COMP/LANG/COBOL
> in pd3hr05k0s989uqh9mfcug5f6bk29ici39@4ax.com
> about Re: MAINFRAME SHOP STANDARDS
>
>
>
>FF> Let's see one example that comes to mind.
>FF>
>FF> Insurance software.
>FF> 1- Links file (holds the relation between diff numbers used on the
>FF> other files.
>FF> 2- Master Person file
>FF> 2- Person insurance details
>FF> 3- Person physical details (address and so on)
>FF> 4- Scheme file
>FF> 5- Scheme Category file
>
> and so on.
>
> That is a database.
Only in the sense that a database is a collection of tables with
related information. Nothing else.
>
> But why is this database in individual flat files which are kept
>together only by the programs working on them, instead of in a real
>database system which can take care of referencial integrity and so
>on?
Because this is not a database. It is an application fully developed
in COBOL and as such it works with indexed files.
This application had over 100 main files, and around 3000 programs.
Converting this to a full database would be very costly, and no real
gain was visible to the company.

Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

James J. Gavan

2004-12-09, 8:55 pm

Lueko Willms wrote:

>. On 09.12.04
> wrote real-email-in-msg-spam@email.com (Frederico Fonseca)
> on /COMP/LANG/COBOL
> in pd3hr05k0s989uqh9mfcug5f6bk29ici39@4ax.com
> about Re: MAINFRAME SHOP STANDARDS
>
>
>
>
>
>FF> Let's see one example that comes to mind.
>FF>
>FF> Insurance software.
>FF> 1- Links file (holds the relation between diff numbers used on the
>FF> other files.
>FF> 2- Master Person file
>FF> 2- Person insurance details
>FF> 3- Person physical details (address and so on)
>FF> 4- Scheme file
>FF> 5- Scheme Category file
>
> and so on.
>
> That is a database.
>
> But why is this database in individual flat files which are kept
>together only by the programs working on them, instead of in a real
>database system which can take care of referencial integrity and so
>on?
>
>
>
>
Lueko, your question was :-
[color=darkred]
And he gave you an answer. Now if you want to ask :-

[color=darkred]

Then no doubt you will get a different answer. :-) Or, having answered
the question, do you want him to go into a long dissertation to justify
why the application is using COBOL files v (R)DBMS

Pete Dashwood

2004-12-10, 3:55 am

"Frederico Fonseca" <real-email-in-msg-spam@email.com> wrote in message
news:e4nhr0h3j7sbitmbpfvdc7mle49n9scv8i@
4ax.com...
> On 09 Dec 2004 21:48:00 GMT, l.willms@jpberlin.de (Lueko Willms)
> wrote:
>
> Only in the sense that a database is a collection of tables with
> related information. Nothing else.
> Because this is not a database. It is an application fully developed
> in COBOL and as such it works with indexed files.
> This application had over 100 main files, and around 3000 programs.
> Converting this to a full database would be very costly, and no real
> gain was visible to the company.
>
>
The conversion cost is in the 3000 programs, not the database. I have tools
that could convert the data for under $US3000, including indexes,
constraints, and third normal form, with OCCURS clauses in record layouts,
converted to separate linked tables.

The problem is in converting the programs that process the current files.
That would be expensive because it can really only be "computer assisted"
not fully automated, and 3000 programs is a significant number. Even given a
tool that claimed to do the conversion in the programs 100%, it still needs
manual intervention to check it.

Nevertheless, the benefits which were "not visible" would be as follows:

1. Reporting and downstream feeds (interfaces with other systems) without
having to write a COBOL program.
2. Data entry requirements can be easily met without requiring COBOL
programs.
3. Any standard software can access the data. It is not locked in to the
COBOL system.
4. The database can be easily scaled and even moved to a different platform
if it made sense to do so economically. More options are available.
5. Standard backup recovery replication makes these functions simpler and
more reliable.

The life of this application will be limited by it NOT being converted.

However, in the meantime it is doing the job and everybody is happy with it.
(I'd start planning for its replacement NOW, if I were you... <G> )

Pete.

Pete Dashwood

2004-12-10, 3:55 am

"James J. Gavan" <jjgavan@shaw.ca> wrote in message
news:6c5ud.473437$%k.409029@pd7tw2no...
> Lueko Willms wrote:
>
<snip>>[color=darkred]
> Then no doubt you will get a different answer. :-) Or, having answered
> the question, do you want him to go into a long dissertation to justify
> why the application is using COBOL files v (R)DBMS
>
No such justification is possible, apart from: "That's the way it evolved;
that's the way it is."

(OK, I'm teasing... but you have to admit, if it wasn't apparent before, it
certainly is now, that the advantages of DBMS go a long way beyond I/O
performance...Locking your application into the COBOL file system is like
saying: "Nothing else is ever going to communicate with this system, it is
never going to communicate with anything else, and if you need to know
anything stored in it you can bloody well write a COBOL program..." As the
COBOL star wanes, this argument has less and less weight and power...)

Pete.

William M. Klein

2004-12-10, 3:55 am

Pete,
HISTORICALLY (pre- "PC" and outside of Unix), the "COBOL file system" often
(usually???) was the Operating System "file system". This meant that data
"stored" in COBOL "files" could EASILY be accessed by any and all other
applications (including those not in COBOL - even those just using "O/S
utilities"). Or at least that is my impression.

Therefore, although I certainly agree that there are advantages to "databases"
(and often - not always - advantages to Relational over Network and Hierarchical
databases) accessibility from non-COBOL was not (historically) one of them.

--
Bill Klein
wmklein <at> ix.netcom.com
"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:31sb3bF3h21qoU1@individual.net...
>
> "James J. Gavan" <jjgavan@shaw.ca> wrote in message
> news:6c5ud.473437$%k.409029@pd7tw2no...
> <snip>>
> No such justification is possible, apart from: "That's the way it evolved;
> that's the way it is."
>
> (OK, I'm teasing... but you have to admit, if it wasn't apparent before, it
> certainly is now, that the advantages of DBMS go a long way beyond I/O
> performance...Locking your application into the COBOL file system is like
> saying: "Nothing else is ever going to communicate with this system, it is
> never going to communicate with anything else, and if you need to know
> anything stored in it you can bloody well write a COBOL program..." As the
> COBOL star wanes, this argument has less and less weight and power...)
>
> Pete.
>
>
>

James J. Gavan

2004-12-10, 3:55 am

Pete Dashwood wrote:

>"James J. Gavan" <jjgavan@shaw.ca> wrote in message
>news:6c5ud.473437$%k.409029@pd7tw2no...
>
>
><snip>>
>
>
>No such justification is possible, apart from: "That's the way it evolved;
>that's the way it is."
>
>(OK, I'm teasing... but you have to admit, if it wasn't apparent before, it
>certainly is now, that the advantages of DBMS go a long way beyond I/O
>performance...Locking your application into the COBOL file system is like
>saying: "Nothing else is ever going to communicate with this system, it is
>never going to communicate with anything else, and if you need to know
>anything stored in it you can bloody well write a COBOL program..." As the
>COBOL star wanes, this argument has less and less weight and power...)
>
>Pete.
>
>
>
>
>
I *know* you are teasing. Oh I wish, I wish you had mentioned it
earlier - MYSQL (Was that it - a freebie or shareware ? ).

Having got royally clobbered on my Win 98 with viruses, bought Norton's
Anti-Virus, which was incompatible with Norton Utilities, and the two
of' 'em incompatible with Windoze - Oh my gawd ! Machine starts up real
dodgy - then keep fingers crossed - still doesn't perform properly.

Solution new desktop Windows XP . (Hey, watch it there on the beach.
Just read to-day a laptop can cause infertility :-) ). Here's the
luverly bit - the guys who sold it to me gave me Access, Word, Excel
etc. So switch to a new machine, upgrade on those. One "problem'o" - the
bastards didn't leave me with the original CDs. New machine - new copies
of those, not upgrades.

Word - every damn bit of correspondence you get, seems you need Word.
Excel - could do without it, (although I had it in mind to do some very
simple graphing). Access - that's the route I went - and as I've
indicated previously, from the M/F IDE I generate SQL syntax and do a
copy and paste into COBOL source.

I haven't yet plonked down the money, salesman was off sick with flu,
then he thought I would contact him, and I thought he would contact me -
bloody human communication. So I could still back off on MS Access and
go MySQL - if that's what it is called. (With the exception of Word,
not using the MS stuff could save me $300-400 approx). But even with
your background in DBs you did indicate it was a little tricky getting
started. I'd have to check with M/F but assuming 'MySql' can be added
to the ODBC list and I can still generate my SQLs as copy and pastes -------
Any thoughts ?

Jimmy

...

Joe Zitzelberger

2004-12-10, 3:55 am

In article <9MZQU30eflB@jpberlin-l.willms.jpberlin.de>,
l.willms@jpberlin.de (Lueko Willms) wrote:

> . On 09.12.04
> wrote joe_zitzelberger@nospam.com (Joe Zitzelberger)
> on /COMP/LANG/COBOL
> in joe_zitzelberger-BF5DFE.08565509122004@knology.usenetserver.com
> about Re: MAINFRAME SHOP STANDARDS
>
>
>
> JZ> Just to chime in with an example
>
> thank you
>
> JZ> -- my shop gets a lot of help from parallel jobs.
>
> I would understand the concept of "parallel" jobs to mean that
> several jobs run in parallel, each processing a file. In COBOL itself,
> parallell processing is not possible, at least by the standard (I know
> of two implementations which do implement what they call "asynchronous
> processing").

Once the split is performed, then 1 job per group is kicked off. They
run on different LPARS or different machines and then the results are
available as output files that can be merged back together.

> JZ>
> JZ> We have almost half a billion accounts on file.
>
> A phone company?

Financial services.

> JZ> So to make processes run faster we will often hash the files into
> JZ> groups based on the IMS area it falls into.
>
> If I only knew what an IMS area is. ...

An IMS area is a 'physical' VSAM file. Many of these are joined by IMS
to make a 'logical' database.

Frederico Fonseca

2004-12-10, 8:55 am

On Fri, 10 Dec 2004 13:58:11 +1300, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:

>
>"Frederico Fonseca" <real-email-in-msg-spam@email.com> wrote in message
> news:e4nhr0h3j7sbitmbpfvdc7mle49n9scv8i@
4ax.com...
snip
>
>1. Reporting and downstream feeds (interfaces with other systems) without
>having to write a COBOL program.
Not a problem for two reasons.
1-Although the programs consider the files as Indexed files these are
AS400 physical and logical files and are therefore available to all
other applications out there that can access DB2.

All generic reporting (e.g. letter to customers) are do using a
VB/Word application, all others can be done either with Query/400 or
with Crystal Reports.
There are a few COBOL reports but not that many.

>2. Data entry requirements can be easily met without requiring COBOL
>programs.
Interfacing has now moved to a Java application. All programs were
kept unchanged, including the entry ones, as these are "called" from
Java.
>3. Any standard software can access the data. It is not locked in to the
>COBOL system.
See above.
>4. The database can be easily scaled and even moved to a different platform
>if it made sense to do so economically. More options are available.
>5. Standard backup recovery replication makes these functions simpler and
>more reliable.
What has backup anything to do with it!!
>
>The life of this application will be limited by it NOT being converted.
>
>However, in the meantime it is doing the job and everybody is happy with it.
>(I'd start planning for its replacement NOW, if I were you... <G> )
they were considering a change to a Oracle solution a few years ago.
100 milion Euros cost with over two years development (not counting
testing/fixing) was decisive to put it away.
>
>Pete.
>
>

Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

Lueko Willms

2004-12-10, 8:55 am

.. On 10.12.04
wrote wmklein@nospam.netcom.com (William M. Klein)
on /COMP/LANG/COBOL
in YB7ud.563876$SM5.33457@news.easynews.com
about Re: MAINFRAME SHOP STANDARDS

WMK> HISTORICALLY (pre- "PC" and outside of Unix), the "COBOL file
WMK> system" often (usually???) was the Operating System "file system".
WMK> This meant that data "stored" in COBOL "files" could EASILY be
WMK> accessed by any and all other applications (including those not in
WMK> COBOL - even those just using "O/S utilities"). Or at least that is
WMK> my impression.

More or less true.

WMK> Therefore, although I certainly agree that there are advantages to
WMK> "databases" (and often - not always - advantages to Relational over
WMK> Network and Hierarchical databases) accessibility from non-COBOL
WMK> was not (historically) one of them.

The difference is that with flat files, as being used in the very
elaborate example presented here, the relationships between those
different files are maintained only by the programmed logic of the
programs accessing this database.

In a proper database system, relations, contraints, referential
integrity is defined in the database schema, and enforced by the
database system.

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

Das Buch muß erst ausgedroschen werden. -G.C.Lichtenberg

Lueko Willms

2004-12-10, 8:55 am

.. On 10.12.04
wrote dashwood@enternet.co.nz (Pete Dashwood)
on /COMP/LANG/COBOL
in 31sal9F3fpbhjU1@individual.net
about Re: MAINFRAME SHOP STANDARDS

PD> The conversion cost is in the 3000 programs, not the database. I have
PD> tools that could convert the data for under $US3000, including
PD> indexes, constraints, and third normal form, with OCCURS clauses in
PD> record layouts, converted to separate linked tables.

Looking at those file names, I seems to me to be already very
normalized, only the relationships of those tables lies in the program
logic of those COBOL programs, not in the database definition
maintained by the database system.

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

Der Amerikaner, der den Kolumbus zuerst entdeckte, machte eine böse Entdeckung. -G.C.Lichtenberg

Lueko Willms

2004-12-10, 8:55 am

.. On 09.12.04
wrote jjgavan@shaw.ca (James J. Gavan)
on /COMP/LANG/COBOL
in 6c5ud.473437$%k.409029@pd7tw2no
about Re: MAINFRAME SHOP STANDARDS

JJG> Lueko, your question was :-
[color=darkred]

JJG> And he gave you an answer.

An enlightening one. But even with such a database without database
management system, I would think that the files do not have to be
opened all at once, but according to their logical relationship, when
the files are needed. I.e. for many programs, the address related to
an account is not necessary, for others one doesn't need the insurance
details when only the current account is of interest, etc.

Also, I don't need to open an output file when I can't access the
input file.

This reasoning is behind my question.

JJG> Now if you want to ask :-
[color=darkred]

That is done automatically by the database system. The program
interfaces those tables thru the database management system, not
directly.

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

Das Buch, das in der Welt am ehesten verboten zu werden verdiente, wäre ein Katalogus von verbotenen Büchern. -G.C.Lichtenberg

Lueko Willms

2004-12-10, 8:55 am

.. On 10.12.04
wrote jjgavan@shaw.ca (James J. Gavan)
on /COMP/LANG/COBOL
in aF7ud.470251$nl.311297@pd7tw3no
about Re: MAINFRAME SHOP STANDARDS

on database systems:

JJG> So I could still back off on MS Access
JJG> and go MySQL - if that's what it is called. (With the exception of
JJG> Word, not using the MS stuff could save me $300-400 approx). But
JJG> even with your background in DBs you did indicate it was a little
JJG> tricky getting started. I'd have to check with M/F but assuming
JJG> 'MySql' can be added to the ODBC list and I can still generate my
JJG> SQLs as copy and pastes ------- Any thoughts ?

Beware of the licence model of mySQL -- when your application is
not open source, licence fees apply.

In case you use a dot-NET application, you might try a look on
TurboDB .NET components (also available as components for Delphi,
C++Builder, and Kylix); see http://www.dataweb.de

That is the same database engine on which VDP, the system I work
with, is based.

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

James J. Gavan

2004-12-10, 3:55 pm

Richard wrote:

Thanks Richard.

>
>Reformt and install Mandrake, or SUSE.
>
>
>
>
>You also need to dump all the Spyware that has installed itself, use
>both AdAware and SpyBot to get rid of all that too.
>
>
>
>$300-400 approx
>
>Get OpenOffice.org, you can open MSWord documents in those. At least
>you wll be able to until MS brings out the next deliberately
>incompatible version to force all users into a new round of upgrades
>for no purpose.
>
>Do not ever use Outlook or IE, they are the conduit by which you get
>all the viruses and spyware. Get Firefox and Thunderbird.
>
>
>

Donald Tees

2004-12-10, 3:55 pm

Richard wrote:
>
>
> Reformt and install Mandrake, or SUSE.
>
>
>
>
> You also need to dump all the Spyware that has installed itself, use
> both AdAware and SpyBot to get rid of all that too.
>
>
>
> $300-400 approx
>
> Get OpenOffice.org, you can open MSWord documents in those. At least
> you wll be able to until MS brings out the next deliberately
> incompatible version to force all users into a new round of upgrades
> for no purpose.
>
> Do not ever use Outlook or IE, they are the conduit by which you get
> all the viruses and spyware. Get Firefox and Thunderbird.
>

Good advice, Jimmy. I put in a mandrake system about a year back, and
use it as a firewall. It shares my line accross the ethernet hub, so I
can stll do updates and such on windows, and have no problem connecting
to orher windows systems using PC Anywhere, but I now to all my WWW
browsing plus all ny mail/usenet stuff on the Linux box. Nary a worry
about worms/virii etc., plus about 75% of the spam is now filtered out.

Pain in the ass to learn, but then they all are. Not doing any Cobol on
it yet.

Donald

Lueko Willms

2004-12-10, 3:55 pm

Lueko Willms

2004-12-10, 3:55 pm

Robert Wagner

2004-12-10, 3:55 pm

docdwarf@panix.com

2004-12-10, 3:55 pm

Robert Wagner

2004-12-10, 3:55 pm

s.

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

Joe Zitzelberger

2004-12-10, 3:55 pm

I would call the ability to do an immediate exit a di