Revisiting an Old Prejudice: READ INTO/WRITE FROM
docd...@panix.com
So... I was being consulted on a program's design and mention was made of
the FD; reflexively I responded that the record layout in the FD should be
as simple as possible, e.g.
FD INFILE
BLOCK CONTAINS 0 RECORDS
.
01 INFILE-REC PIC X(160).
... and that everything should be dealt with in WORKING-STORAGE using READ
INTO and WRITE FROM.
This, of course, is what was taught to me lo, those many decades back; the
specific of 'Thou shalt not perform arithmetic manipulations in file
buffers' was expanded into the zero-tolerance rule of 'Thou shalt not
touch file buffers; all will be done in WORKING-STORAGE via READ INTO and
WRITE FROM.'
A few years back... not too long ago, maybe 1988, 1989, I was called in to
help a coder who was getting some whacky results... and sure enough, he
was doing arithmetice manipulations on the FDand the numbers were coming
out screwy. Granted, the platform was WANG VS... but the Ancient Teaching
was proven right.
Things have changed since then, of course, and the Thou Shalt/Shalt Nots
dating back to ENIAC may no longer be applicable... so I wonder:
Does anyone know of harm/damage/bad stuff (outside of that which can be
chalked up to sloppiness, e.g. changing a key's position/length and not
updating the WORKING-STORAGE layout to match) which might happen due to
continuing to adhere to this? What is more likely to Go Wrong by holding
to this 'standard'?
DD
Pat Hall
old habits, especially ones with historical merit, die hard. Besides
if I always do it the same way it sure is easier to debug.
PatH
Robert Wagner
>So... I was being consulted on a program's design and mention was made of
>the FD; reflexively I responded that the record layout in the FD should be
>as simple as possible, e.g.
>
> FD INFILE
> BLOCK CONTAINS 0 RECORDS
> .
> 01 INFILE-REC PIC X(160).
>
>... and that everything should be dealt with in WORKING-STORAGE using READ
>INTO and WRITE FROM.
That's not as simple as possible. This is:
FD INFILE.
01 PIC X(160).
docd...@panix.com
Do tell, Mr Wagner... how is your record layout of X(160) simpler than any
other record layout of X(160)?
DD
Walter Murray
> This, of course, is what was taught to me lo, those many decades back; the
> specific of 'Thou shalt not perform arithmetic manipulations in file
> buffers' was expanded into the zero-tolerance rule of 'Thou shalt not
> touch file buffers; all will be done in WORKING-STORAGE via READ INTO and
> WRITE FROM.'
I don't think I've heard this before--avoiding arithmetic manipulations in
file buffers. Is it a performance thing with some compilers? Could you
give an example of what needs to be avoided?
Walter
docd...@panix.com
Walter Murray <wmu...@midtown.net> wrote:
><docd...@panix.com> wrote in message:
>> This, of course, is what was taught to me lo, those many decades back; the
>> specific of 'Thou shalt not perform arithmetic manipulations in file
>> buffers' was expanded into the zero-tolerance rule of 'Thou shalt not
>> touch file buffers; all will be done in WORKING-STORAGE via READ INTO and
>> WRITE FROM.'
>
>I don't think I've heard this before--avoiding arithmetic manipulations in
>file buffers. Is it a performance thing with some compilers?
From the posting to which you responded, the paragraph immediately
following the above:
--begin quoted text:
A few years back... not too long ago, maybe 1988, 1989, I was called in to
help a coder who was getting some whacky results... and sure enough, he
was doing arithmetice manipulations on the FDand the numbers were coming
out screwy. Granted, the platform was WANG VS... but the Ancient Teaching
was proven right.
--end quoted text
>Could you
>give an example of what needs to be avoided?
Arithmetic manipulations... things like ADD, SUBTRACT, MULTIPLY, DIVIDE
and COMPUTE, for a start.
FD INFILE.
01 INREC.
05 INREC-NUMFLD1 PIC S9(5)V99 COMP-3.
05 INREC-NUMFLD2 PIC S9(5)V99 COMP-3.
05 INREC-NUMFLD3 PIC S9(5)V99 COMP-3.
05 INREC-NUMFLD4 PIC S9(5)V99 COMP-3.
ADD INREC-NUMFLD1 TO INREC-NUMFLD2.
DIVIDE INREC-NUMFLD1 BY INREC-NUMFLD4.
SUBTRACT 3.14 FROM INREC-NUMFLD3.
MULTIPLY INREC-NUMFLD3 BY 5.
... and suchlike.
DD
Chuck Stevens
> In article <41124383....@news.optonline.net>,
> >That's not as simple as possible. This is:
> >
> >FD INFILE.
> >01 PIC X(160).
>
> Do tell, Mr Wagner... how is your record layout of X(160) simpler than any
> other record layout of X(160)?
I think he was commenting on the BLOCK CONTAINS clause.
But I'll go you one better:
FD INFILE.
is sufficient in 2002 COBOL; the record description is optional. READ ...
INTO you already have had for decades. What makes this possible is the new
WRITE FILE <filename> FROM <identifier>.
-Chuck Stevens
Chuck Stevens
<docd...@panix.com> wrote in message news:cetdfp$mnk$1...@panix5.panix.com...
> Does anyone know of harm/damage/bad stuff (outside of that which can be
> chalked up to sloppiness, e.g. changing a key's position/length and not
> updating the WORKING-STORAGE layout to match) which might happen due to
> continuing to adhere to this? What is more likely to Go Wrong by holding
> to this 'standard'?
The COBOL standard does not require that the record have meaningful
information in it after a WRITE unless the file is specified in a SAME
RECORD AREA clause. If you depend on the information hanging around after
that, you're in implementation-dependent territory.
-Chuck Stevens
docd...@panix.com
Chuck Stevens <charles...@unisys.com> wrote:
><docd...@panix.com> wrote in message news:cethnv$6eg$1...@panix5.panix.com...
>> In article <41124383....@news.optonline.net>,
>> >That's not as simple as possible. This is:
>> >
>> >FD INFILE.
>> >01 PIC X(160).
>>
>> Do tell, Mr Wagner... how is your record layout of X(160) simpler than any
>> other record layout of X(160)?
>
>I think he was commenting on the BLOCK CONTAINS clause.
I think so, also... and I also think that the BLOCK CONTAINS clause is a
part of the File Description, not the record layout.
>
>But I'll go you one better:
>
> FD INFILE.
>
>is sufficient in 2002 COBOL; the record description is optional.
Looks like I'll have something to implement, then, in another couple o'
decades. Speaking of which... I was talking with a lad about different
approaches in coding and put together the following two examples:
Perform Until eof
Read Infile Into wk-inrec
At End
Set eof To True
Not At End
Evaluate wk-inrec(1:1)
When 1
When 6
Continue
When 2
Perform Process-Typ2
When 5
Perform Process-Typ5
End-Evaluate
End-Read
End-Perform
... and ...
PERFORM MAINLINE THRU M-EX UNTIL EOF.
MAINLINE.
PERFORM READ-INFILE THRU RI-EX.
IF EOF
GO TO M-EX.
IF WK-INREC-CHAR1 = 1 OR 6
GO TO ME-EX.
IF WK-INREC-CHAR1 = 2
PERFORM PROCESS-TYP2 THRU P-T2-EX.
IF WK-INREC-CHAR1 = 5
PERFORM PROCESS-TYP5 THRU P-T5-EX.
... and then I started laughing. What caused me mirth is that when I
started coding in 'OLDBOL' I dropped all uses of '85-or-above
constructs... no reference-modification, no Evaluate... reflexively coding
with '74 limitations.
It reminded me of folks I know who will, say, discuss matters of calculus
in English... but when they are adding up the receipt in a restaurant will
fall back into the language in which they first learned their numbers,
German, Italian, Hindi or what-have-you.
DD
docd...@panix.com
If by 'the record' you intend what lives in the FD, what I am calling the
file buffer... then what I read you saying is that this is a reason for
continuing the practises of READ INTO/WRITE FROM. Did I get that right?
DD
Chuck Stevens
Yes. Further, it seems to me that *encouragement* of that practice is what
led to making the record description optional in the FD and adding the WRITE
FILE syntax so that it could be optional.
In fact, I'd go so far as to say that if somebody wrote a proposal to make
WRITE <record-name> officially archaic, I would probably vote in favor of
it. According to the standard, the record associated with a file is
unavailable before the file is opened, unavailable after the file is closed,
unavailable after a write or rewrite, and undefined after an unsuccessful
read or a successful open.
For me the "file buffer" is a different place from the FD's record
description; for me it's the job of the "operating environment" and not the
job of the compiler to deal with buffer management, so, for me, there's no
problem using a FD record or fields within it as if it were in
working-storage -- the space is always available, it's just space, and the
system transfers the information in the record into and out of the file
buffers.
The standard, however, has to account for implementations that don't handle
things that way, which is why it decrees the record unavailable; programs
that access such records outside of the execution-time contexts in which
they're defined as "available" are noncompliant.
Yeah, I think WRITE FILE and abandonment of the FD record, with the implicit
bizarrenesses about availability and defined content during execution, is a
good idea. Whether the standard "archaizes" WRITE <record> or not, it
strikes me that WRITE FILE is better style overall.
Now, for those of you for whom the FD's record *is* the file buffer, and
WRITE FILE ends up doing an extra move that WRITE <record> didn't, well, I
just don't know what to say about implementations that would do that!
;-)
-Chuck Stevens
William M. Klein
A little "history"
1) With pre '74 Standard OS/VS COBOL (and earlier, e.g. ANS V4 product) it was
possible to "access" the record (as described under an FD) before an OPEN and
after a CLOSE. (This was NOT documented as valid - but worked) Therefore, it
was a "medium common" to have
READ file-name
AT END
MOVE HIGH-VALUES TO record-name
IF record-name NOT = HIGH-VALUES ....
Somewhere around "LANGLVL(2)" and/or VS COBOL II (I can't remember which), this
no longer worked and LOTS of programs "died" at run-time. Therefore, the "new
Standard" of always doing a READ INTO and WRITE FROM became very common in IBM
shops. (Even though the only "real" problem was accessing the record before an
OPEN and after a CLOSE.
2) When IBM (eventually) moved ACB's (VSAM) and DCB's (QSAM) "above the 16M
line", it became possible (and in come - not all cases) for the "block" to be
read into storage above the line, but for a copy of the record to be "moved"
below the line. It was this below-the-line area that was accessed by the
program. Therefore, previously "working" (but not documented as valid) programs
that did negative subscripting to get to a variable length record's LLZZ field -
or to try and get to "block" information from the record, would fail. Again, to
avoid the "temptation" to use these techniques, the READ INTO and WRITE FROM
formats were made "shops standards".
***
Not for history (but current)
I have checked both the Enterprise COBOL "Tuning" White Paper and the
"Programming Guides" and can find no indication that there is any performance
advantage/disadvantage of one technique over the other. I am *not* an Assembler
programmer, but I believe that S/3x0 Assembler provides support for "locate" and
"move" modes for reads (writes). I seem to recall discussions of which performs
better - and why doesn't COBOL use one over the other (in certain cases).
However, there doesn't seem to be any documented way for a COBOL programmer to
"insure" which is used - much less which will perform better.
Finally, if you are positioning IBM mainframe programs for "multi-threading" you
should read the section at:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg20/4.4.4
which does explicitly mention "implicit serialization lock" with READ INTO and
WRITE FROM
--
Bill Klein
wmklein <at> ix.netcom.com
<docd...@panix.com> wrote in message news:cetdfp$mnk$1...@panix5.panix.com...
>
Walter Murray
> The standard, however, has to account for implementations that don't
handle
> things that way, which is why it decrees the record unavailable; programs
> that access such records outside of the execution-time contexts in which
> they're defined as "available" are noncompliant.
I was looking for an explicit statement to that effect in the standard. Can
you point me to it?
Walter
Chuck Stevens
noncompliance, it worries about *syntactic* noncompliance.
Taking ANSI X3.23-1985 sequential I-O as an example, and ignoring "SAME
RECORD AREA": CLOSE GR6 specifies that the record area is "no longer
available", READ GR12 specifies that the content of the record area is
"undefined", REWRITE GR5 specifies "not available", and WRITE GR2 specifies
"no longer available". ISO/IEC 1989:2002 is similar.
Perhaps a more accurate way of describing this is that a program that
accesses a record in a FD when the file that the FD describes is closed or
has just been written to is dependent on behavior that is outside what is
permitted by the standard. It's not the sort of thing the compiler could
flag as noncompliant, but the consequences of trying to do something the
standard says "you're not supposed to be able to do that" are undefined.
-Chuck Stevens
Richard
I suspect that the problem only occurred if it had:
> READ file-name
> AT END
> MOVE HIGH-VALUES TO record-name
CLOSE file-name
.
>
> IF record-name NOT = HIGH-VALUES ....
It isn't the AT END that dumped the buffer, but the CLOSE.
Walter Murray
> Walter Murray <wmu...@midtown.net> wrote:
> >Could you
> >give an example of what needs to be avoided?
>
> Arithmetic manipulations... things like ADD, SUBTRACT, MULTIPLY, DIVIDE
> and COMPUTE, for a start.
>
> FD INFILE.
> 01 INREC.
> 05 INREC-NUMFLD1 PIC S9(5)V99 COMP-3.
> 05 INREC-NUMFLD2 PIC S9(5)V99 COMP-3.
> 05 INREC-NUMFLD3 PIC S9(5)V99 COMP-3.
> 05 INREC-NUMFLD4 PIC S9(5)V99 COMP-3.
>
> ADD INREC-NUMFLD1 TO INREC-NUMFLD2.
> DIVIDE INREC-NUMFLD1 BY INREC-NUMFLD4.
> SUBTRACT 3.14 FROM INREC-NUMFLD3.
> MULTIPLY INREC-NUMFLD3 BY 5.
>
> ... and suchlike.
That's what I thought you were saying. But this is perfectly legal standard
COBOL, right? (Well, except for the missing GIVING phrases on the DIVIDE
and the MULTIPLY, and the use of COMP-3, a common extension.)
Are you saying that some compilers are defective and give the wrong results
for the statements above?
Or, perhaps, are you referring to the unpredictable things that can happen
if you access a file's record area when it is not available, such as after
the file has been closed?
Walter
Chuck Stevens
"Richard" <rip...@Azonic.co.nz> wrote in message
news:217e491a.0408...@posting.google.com...
The buffer is indeed still available after the READ but before execution of
the AT END clause, but its contents are undefined. The AT END MOVE ...
should work, but then after the CLOSE the record you just MOVEd to is no
longer "available", so if you "avail" yourself of its contents there's no
telling what you'll get. So far as the standard is concerned, as I see it,
you might get HIGH-VALUES, you might get a run-time error, you might get
rutabagas, you might get Thursday.
-Chuck Stevens
docd...@panix.com
Walter Murray <wmu...@midtown.net> wrote:
><docd...@panix.com> wrote:
>> Walter Murray <wmu...@midtown.net> wrote:
>> >Could you
>> >give an example of what needs to be avoided?
>>
>> Arithmetic manipulations... things like ADD, SUBTRACT, MULTIPLY, DIVIDE
>> and COMPUTE, for a start.
>>
>> FD INFILE.
>> 01 INREC.
>> 05 INREC-NUMFLD1 PIC S9(5)V99 COMP-3.
>> 05 INREC-NUMFLD2 PIC S9(5)V99 COMP-3.
>> 05 INREC-NUMFLD3 PIC S9(5)V99 COMP-3.
>> 05 INREC-NUMFLD4 PIC S9(5)V99 COMP-3.
>>
>> ADD INREC-NUMFLD1 TO INREC-NUMFLD2.
>> DIVIDE INREC-NUMFLD1 BY INREC-NUMFLD4.
>> SUBTRACT 3.14 FROM INREC-NUMFLD3.
>> MULTIPLY INREC-NUMFLD3 BY 5.
>>
>> ... and suchlike.
>
>That's what I thought you were saying. But this is perfectly legal standard
>COBOL, right? (Well, except for the missing GIVING phrases on the DIVIDE
>and the MULTIPLY, and the use of COMP-3, a common extension.)
>
>Are you saying that some compilers are defective and give the wrong results
>for the statements above?
I've said what I've said, sometimes twice now. For the third and last
time:
from
<http://groups.google.com/groups?selm=cetdfp%24mnk%241%40panix5.panix.com&output=gplain>
--begin quoted text:
This, of course, is what was taught to me lo, those many decades back; the
specific of 'Thou shalt not perform arithmetic manipulations in file
buffers' was expanded into the zero-tolerance rule of 'Thou shalt not
touch file buffers; all will be done in WORKING-STORAGE via READ INTO and
WRITE FROM.'
A few years back... not too long ago, maybe 1988, 1989, I was called in to
help a coder who was getting some whacky results... and sure enough, he
was doing arithmetice manipulations on the FDand the numbers were coming
out screwy. Granted, the platform was WANG VS... but the Ancient Teaching
was proven right.
--end quoted text
from
<http://groups.google.com/groups?selm=cetjbb%24ci2%241%40panix5.panix.com&output=gplain>
--begin quoted text:
From the posting to which you responded, the paragraph immediately
following the above:
--begin quoted text:
A few years back... not too long ago, maybe 1988, 1989, I was called in to
help a coder who was getting some whacky results... and sure enough, he
was doing arithmetice manipulations on the FDand the numbers were coming
out screwy. Granted, the platform was WANG VS... but the Ancient Teaching
was proven right.
--end quoted text
--end quoted text
You've read all this previously, I hope... what do you find to be unclear?
I told you what I was taught, I told you what I have experienced.
>
>Or, perhaps, are you referring to the unpredictable things that can happen
>if you access a file's record area when it is not available, such as after
>the file has been closed?
Read what I wrote, Mr Murray. What I said, what I intended and what I
referred to is all right there.
DD
Warren Simmons
reader, I'd like to xpln one more time. COBOL was designed in the
late 1050's and early 1960's. The short range group was made up of
almost all UNIVAC or former UNIVAC users.
The UNIVAC by todays standards was a simple system. Except for tape
drives, the ONLY memory was 1000 words of mercuray delay line except
for I/O buffers of 60 words each. Each word was 12 characters long
including the sign if one existed, and memory management was a
programmer's responsibility.
Conscquently, a READ in 1960 COBOL was expected to dump the input
buffer into some sixty words of the 1000 words. If you had tape out
the output was built in the memory buffer, and when write occured,
the 60 words were moved to the output buffer and hence to the tape.
(In my mind, I'm not really sure that the I/O bufferes existed. They
probably were part of the 1000 words of memory.) At any rate, when
you had one input and one output, a minimum I/O situation, 120 words
were dedicated to I/O. It was common to have two inputs and one or two
or more outputs which drastically reduced the availabe space for
program code. Once an input block was full, the program dealt with
parts of it depending upon the record size. Most common was 120
characters, 10 words. Other versions could be word, or multiple word in
groups of two as machine instructions were used. Besides word records
instuction support supported two words, and ten words. There were no
library routines to use, except the paper copies of the machine code
needed to do these things.
However, there were procedure one could use to build records in memory
from more than one tape drive at a time. So, for example, a two way
merge would use three 60 word buffers, and programs could read into
working storage a record from one file, and from another file, make
a decision, and write the output from the proper input buffer.
Our HSP only printed 120 characters per line, so no output would exceed
that unless it would appear on two lines or more, or not at all. The
output was writen to tape, carried to the printer, and the printer
had compatible buffers.
I would guess, but have no backup that computer design from the point
of COBOL 60 on considered ways to improve that initial condition. So
all of the talk about read into, and write from is grandfather spec.
I hope this helps some people understand that COBOL has changed with
the hardware (in part to do a better job, and capture more customers.)
I'm certainly for that kind of thing, and the way I look at it, there
were a lot of jobs created as a result.
Warren Simmons
JJ
would have the same question - WHY?
OK, you said "I was taught..." and "I experienced...". Didn't you want to
know WHY there was a problem? It doesn't seem to me like there should be
any problem with it.
I've been programming Cobol for 18 years on Unix & Windows systems, and I've
never encountered problems doing math on fields in FD's with those
platforms/compilers. Years ago, I did see code that insisted on moving
everything from FD fields into Working Storage after reads and vice versa
before writes/rewrites, but no one could ever give me a good reason why it
was done. The only reason I ever came up with was the usage of SAME AREA,
which only seemed useful when memory was at a premium.
<docd...@panix.com> wrote in message news:ceuj9t$cn3$1...@panix5.panix.com...
Richard
> > I suspect that the problem only occurred if it had:
> >
> > > READ file-name
> > > AT END
> > > MOVE HIGH-VALUES TO record-name
> > CLOSE file-name
> > .
> > >
> > > IF record-name NOT = HIGH-VALUES ....
> >
> > It isn't the AT END that dumped the buffer, but the CLOSE.
>
> The buffer is indeed still available after the READ but before execution of
> the AT END clause, but its contents are undefined. The AT END MOVE ...
> should work,
Exactly. The original wasn't a problem. Putting the CLOSE in the AT
END then creates the problem.
> but then after the CLOSE the record you just MOVEd to is no
> longer "available",
Exactly. If the CLOSE is left until just before STOP RUN (or
similar), or is left off, relying on the run-time to close the file,
then the buffer problem doesn't occur - well not _after_ a successful
OPEN anyway.
William M. Klein
Standard also)
From GR(21) of the READ statement,
"When the at end condition exists, execution of the READ statement is
unsuccessful."
From GR(15)
"Unless otherwise specified, at the completion of any unsuccessful
execution of a READ statement, the content of the associated record area is
undefined,"
I do NOT think this is just after the CLOSE.
--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <rip...@Azonic.co.nz> wrote in message
news:217e491a.04080...@posting.google.com...
Richard
> I've been programming Cobol for 18 years on Unix & Windows systems, and I've
> never encountered problems doing math on fields in FD's with those
> platforms/compilers. Years ago, I did see code that insisted on moving
> everything from FD fields into Working Storage after reads and vice versa
> before writes/rewrites, but no one could ever give me a good reason why it
> was done. The only reason I ever came up with was the usage of SAME AREA,
> which only seemed useful when memory was at a premium.
Some versions of Fujitsu Cobol, such as on Linux, do not allow access
to record areas before an open or after a close. It gives a
segmentation fault which presumably is because the record areas are
created dynamically upon OPEN.
Lueko Willms
schrieb docd...@panix.com
auf /COMP/LANG/COBOL
in cetdfp$mnk$1...@panix5.panix.com
ueber Revisiting an Old Prejudice: READ INTO/WRITE FROM
d> ... and that everything should be dealt with in WORKING-STORAGE using
d> READ INTO and WRITE FROM.
To me this doesn't make sense.
If one takes into account the holy principle:
Thou shalt not trust external data and check it before using it
So, when you try to do calculations with an item from an imput file
which is not a number, an error will occur.
Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WI...@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)
The Family
I wasn't aware that Cobol programming was done on ascii type
systems. At least not to any great degree.
Why would you use Cobol in these environments. I'm very curious.
Thanks,
Gary
"Richard" <rip...@Azonic.co.nz> wrote in message
news:217e491a.04080...@posting.google.com...
docd...@panix.com
>Cripes, calm down. I'm pretty sure he knew what you wrote, as do I.
This *is* calm, actually... 'so cold he burns, no wonder some think he is
on fire', as Nietzsche put it.
>But I
>would have the same question - WHY?
I was not asked 'WHY', I was asked, repeatedly, 'are you saying that'...
when what I said was, according to quotation, apparently clear.
>
>OK, you said "I was taught..." and "I experienced...". Didn't you want to
>know WHY there was a problem?
Had I wanted to know this it just might be possible that I would have
posted a thread which mentioned it in a forum of professionals who might
be able to address the matter.
>It doesn't seem to me like there should be
>any problem with it.
It doesn't seem to me that there should be any reason for bodies to be
attracted to each other with a force that is inversely proportional to the
square of the distance between their centers, as well... what's Life
without a bit of Mystery?
>
>I've been programming Cobol for 18 years on Unix & Windows systems, and I've
>never encountered problems doing math on fields in FD's with those
>platforms/compilers. Years ago, I did see code that insisted on moving
>everything from FD fields into Working Storage after reads and vice versa
>before writes/rewrites, but no one could ever give me a good reason why it
>was done. The only reason I ever came up with was the usage of SAME AREA,
>which only seemed useful when memory was at a premium.
Thrice now it has been posted what I was taught and thrice what I
experienced... perhaps someone else might be able to say more, incessant
repetition wearies me.
DD
docd...@panix.com
Lueko Willms <l.wi...@jpberlin.de> wrote:
>. Am 05.08.04
>schrieb docd...@panix.com
> auf /COMP/LANG/COBOL
> in cetdfp$mnk$1...@panix5.panix.com
> ueber Revisiting an Old Prejudice: READ INTO/WRITE FROM
>
>d> ... and that everything should be dealt with in WORKING-STORAGE using
>d> READ INTO and WRITE FROM.
>
> To me this doesn't make sense.
Perhaps not... but it was not asked to make sense, it was asked if any
harm/damage/Bad Stuff is known to happen by maintaining the practise.
>
> If one takes into account the holy principle:
> Thou shalt not trust external data and check it before using it
Another Teaching from the Oldene Dayse was 'All data are sacred, no datum
is to be trusted', sure.
>
> So, when you try to do calculations with an item from an imput file
>which is not a number, an error will occur.
This can be said for that which is in the file buffer and that which is in
WORKING-STORAGE, certainly.
DD
docd...@panix.com
Warren Simmons <wsim...@optonline.net> wrote:
[snip]
>I would guess, but have no backup that computer design from the point
>of COBOL 60 on considered ways to improve that initial condition. So
>all of the talk about read into, and write from is grandfather spec.
>
>I hope this helps some people understand that COBOL has changed with
>the hardware (in part to do a better job, and capture more customers.)
>
>I'm certainly for that kind of thing, and the way I look at it, there
>were a lot of jobs created as a result.
Thanks greatly for the perspective, Mr Simmons, and yet...
... and yet the question of 'does it do harm?' still hangs.
[snip]
JerryMouse
> I wasn't aware that Cobol programming was done on ascii type
> systems. At least not to any great degree.
>
> Why would you use Cobol in these environments. I'm very curious.
>
> Thanks,
>
> Gary
Because our customers can't afford a mainframe?
docd...@panix.com
Ignoring, for the moment, that answering a question with a question is no
answer at all... it might be that they cannot afford a mainframe... or
perhaps because they don't need a mainframe... or perhaps because the
problem at hand is best - or at least capably - addressed by using the
tool of COBOL.
DD
Chuck Stevens
After a successful CLOSE the "record area" is unavailable.
After a WRITE or REWRITE, the "logical record" is unavailable. .
After an unsuccessful READ, the contents of the record area are undefined.
-Chuck Stevens
record itself is unavailable; after a WRITE or REWRITE
"William M. Klein" <wmk...@nospam.netcom.com> wrote in message
news:9XCQc.10490$9Y6....@newsread1.news.pas.earthlink.net...
Clark F. Morris, Jr.
That extension makes the practice Doc referred to safe and not subject
to problems when the length of the record changes and all of the
corresponding records in the various FDs are not changed. My personal
preference is to have the record description in question used with all
of the appropriate FD statements and put up with, in my controversial
opinion, is the odious syntax for qualification. That way I know that
when the record description is changed, all places in the program that
deal with the record are properly updated.
Incidentally, has IBM changed from defaulting to BLOCK 1 record when the
description for a Non-VSAM file has "FD file-name."? If it hasn't, in
the environments Doc normally works in, "FD file-name BLOCK 0." is still
needed for the non-VSAM data sets.
Frank Swarbrick
like:
WRITE MY-REC
and then changed it to
WRITE MY-REC
MOVE new-data-field to MY-REC-FIELD
WRITE MY-REC
Basically they were looking to write an addition record that was mostly the
same as the previous record, only with one field being different.
Unfortunately after the first WRITE the pointer for the file buffer moved to
the next record so that the next WRITE wrote either garbage (if the file
buffer had yet to 'loop' around to the beginning) or it wrote a totally
unrelated record (the one that existed in that part of the buffer the 'last
time through', if you will. Never good.
Not sure if this is the 'reason' you are looking for.
I would say that 'creating' a record in a file buffer, manipulating it
(optionally) and then writing it is probably safe. But doing anything with
it once you've written it is not guarunteed to be safe. It's most likely
not safe, at least in my environment, if there is more than one record per
block. Don't know if it would be safe even if there was only one record per
block.
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
>>> <docd...@panix.com> 8/5/2004 10:42:03 AM >>>
Richard
> > I wasn't aware that Cobol programming was done on ascii type
> > systems. At least not to any great degree.
>
> Because our customers can't afford a mainframe?
That seems to make the assumption that all mainframes are 'EDCDIC type
systems'.
Many decades ago I worked on mainframes that, while not ASCII - they
weren't American, were 'ascii type'.
JerryMouse
My mistake. The response should have read:
"Because our customers can't afford a mainframe."
Warren Simmons
90 words. The hardware buffer was 60 words. Because we were all green
as grass (during the growing season), the Univac SE was assigned the
job of programming that file's part of the system. As I recall his
solution was to allocate three memory buffers, and process ten words
at a time until the whole record was ready to write before reading
the next record into the buffer. What ever it was, updates to that
program required "his" maintenance for a long time. Payrolls have a
way of changing, and when necessary, he would be hired to do the change
instead of trying to let someone else learn how to do it.
If I remember correctly, and that's a big jump, I used that source
program to help teach a new bunch of programmers C-10. (Univac 1 machine
language.)
Warren Simmons
docd...@panix.com
JerryMouse <nos...@bisusa.com> wrote:
>docd...@panix.com wrote:
>> In article <vOadneNaTu-...@giganews.com>,
>> JerryMouse <nos...@bisusa.com> wrote:
>>> The Family wrote:
>>>> I wasn't aware that Cobol programming was done on ascii type
>>>> systems. At least not to any great degree.
>>>>
>>>> Why would you use Cobol in these environments. I'm very curious.
>>>>
>>>> Thanks,
>>>
>>
>> Ignoring, for the moment, that answering a question with a question
>> is no answer at all... it might be that they cannot afford a
>> mainframe... or perhaps because they don't need a mainframe... or
>> perhaps because the problem at hand is best - or at least capably -
>> addressed by using the tool of COBOL.
>
>My mistake. The response should have read:
>
>"Because our customers can't afford a mainframe."
Well, now, that makes *all* the difference; my reply to your response
would then have read:
'It might be that some cannot afford a mainframe... or perhaps because
some don't need a mainframe... or perhaps because the problem at hand is
best - or at least capably - addressed by using the tool of COBOL.'
DD
The Family
Well, I guess my question should have been....
"I would be interested in learning more about Cobol on a non-main-
frame environment. Where might I look to get more information"?
Thanks - Gary
<docd...@panix.com> wrote in message news:cf143d$bdj$1...@panix5.panix.com...
JerryMouse
> Well, I guess my question should have been....
>
> "I would be interested in learning more about Cobol on a non-main-
> frame environment. Where might I look to get more information"?
>
> Thanks - Gary
You can ask here - what would you like to know?
Bear in mind that COBOL worked fine on 64K 360-Mod30 back in the '60s.
Today's desktop PCs are magnitudes more powerful so there's no real
impediment to COBOL's use.
Here's the Fujitsu COBOL main page:
Richard
> "Unless otherwise specified, at the completion of any unsuccessful
> execution of a READ statement, the content of the associated record area is
> undefined,"
>
> I do NOT think this is just after the CLOSE.
There is a difference between 'the content of the record area is
undefined' and 'the record area is undefined (or unavailable)'.
Between a sucessful open and the close the record area is accessible
and may be referenced. After an unsuccessful READ, or in many other
cases, the content is undefined, that is it may be rubbish, but if
something is moved there it may be tested later.
After a CLOSE the record area may disappear entirely, as it does in
Fujitsu NetCobol for Linux, and possibly other versions, but does not
in MicroFocus versions that I have used. When the record area becomes
unavailable a reference to it causes an abend (segmentation fault).
That is, I know of no cases where moving data into a record area and
testing that area between an AT END and the CLOSE would be a problem.
If there is then the Cobol system is broken. For example after an AT
END it is entirely possible to move a new value into a key and do a
START or a READ.
The Family
Well, I wanted to know how Cobol handled screen management,
and a myriad of other things that I won't bother you with now.
I'll look at the site, and return with specific questions, if necessary.
Thanks, for the info,
Gary
"JerryMouse" <nos...@bisusa.com> wrote in message
news:9YmdnZ9MetZ...@giganews.com...
Arnold Trembley
docd...@panix.com
Arnold Trembley <arnold....@worldnet.att.net> wrote:
[snip]
>And as to DocDwarf's original question, I was also taught to always
>READ INTO and WRITE FROM. It might not always be necessary, but I
>don't see that it hurts anything to keep doing it that way.
zzzzZZZZzzzzz.... zzzzzaaaaAAAAWWWKKKHHHhhhhh... huh? whuh? Dear me, did
someone actually address the question? Thanks much, Mr Trembley.
DD
docd...@panix.com
The Family <lgv...@swbell.net> wrote:
>
>Well, I guess my question should have been....
>
>"I would be interested in learning more about Cobol on a non-main-
>frame environment. Where might I look to get more information"?
You might start at the ever-popular
http://www.cobolreport.com/faqs/cobolfaq.htm
DD
The Family
Michael Wojcik
In article <68WQc.2416$Af4....@newssvr24.news.prodigy.com>, "The Family" <lgv...@swbell.net> writes:
>
> Well, I guess my question should have been....
>
> "I would be interested in learning more about Cobol on a non-main-
> frame environment. Where might I look to get more information"?
Straight lines like that almost make me wish I were in sales...
There are a few odds and ends about COBOL on non-mainframe platforms
(and some mainframe ones) at http://www.microfocus.com. We've been
selling COBOL for non-mainframe platforms for almost 30 years now.
COBOL is quite popular on Windows and Unix, for much the reason Doc
suggested - people want to get something done, and they have COBOL
developers available who can do it. And, sometimes, for the reason
Jerry suggested: they believe they can do it cheaper on one of those
platforms than on a mainframe.
--
Michael Wojcik michael...@microfocus.com
The antics which have been drawn together in this book are huddled here
for mutual protection like sheep. If they had half a wit apiece each
would bound off in many directions, to unsimplify the target.
-- Walt Kelly
JerryMouse
> So... I was being consulted on a program's design and mention was
> made of the FD; reflexively I responded that the record layout in the
> FD should be as simple as possible, e.g.
>
> FD INFILE
> BLOCK CONTAINS 0 RECORDS
> .
> 01 INFILE-REC PIC X(160).
>
> ... and that everything should be dealt with in WORKING-STORAGE using
>
> back; the specific of 'Thou shalt not perform arithmetic
> manipulations in file buffers' was expanded into the zero-tolerance
> rule of 'Thou shalt not touch file buffers; all will be done in
> WORKING-STORAGE via READ INTO and WRITE FROM.'
>
> A few years back... not too long ago, maybe 1988, 1989, I was called
> in to help a coder who was getting some whacky results... and sure
> enough, he was doing arithmetice manipulations on the FDand the
> numbers were coming out screwy. Granted, the platform was WANG VS...
> but the Ancient Teaching was proven right.
>
> Things have changed since then, of course, and the Thou Shalt/Shalt
> Nots dating back to ENIAC may no longer be applicable... so I wonder:
>
> be chalked up to sloppiness, e.g. changing a key's position/length
> and not updating the WORKING-STORAGE layout to match) which might
> happen due to continuing to adhere to this? What is more likely to
> Go Wrong by holding to this 'standard'?
-------
During a performance in an early 1900s NY Yiddish theatre an actor collapsed
on the stage.
A doctor from the audience jumps to the stage and kneels beside the actor.
From the back of the balcony come a yiddishia-momma voice: "Give him an
enema!"
The doctor puts his ear to the actor's chest, listens for a moment, then
stands.
From the back of the balcony: "GIVE HIM AN ENEMA!"
The doctor faces the balcony and says: "Madame, the actor is DEAD."
From the back of the balcony: "So,... it can't hurt!"
I've often said the same about READ...INTO and WRITE...FROM.
docd...@panix.com
[snip]
>> Does anyone know of harm/damage/bad stuff (outside of that which can
>> be chalked up to sloppiness, e.g. changing a key's position/length
>> and not updating the WORKING-STORAGE layout to match) which might
>> happen due to continuing to adhere to this? What is more likely to
>> Go Wrong by holding to this 'standard'?
>
>-------
[snip]
>From the back of the balcony: "GIVE HIM AN ENEMA!"
>
>The doctor faces the balcony and says: "Madame, the actor is DEAD."
>
>From the back of the balcony: "So,... it can't hurt!"
>
>I've often said the same about READ...INTO and WRITE...FROM.
You've often said that READ INTO and WRITE FROM are like giving a dead
actor an enema?
DD
The Family
Yes, I am quite familiar with Cobol, and with the fact that Micro-
Focus builds one for many platforms. However, I've never used
your product, but know others that have.
I just thought I might experiment with Cobol on a PC to see how
it works. I don't want to get into $1,000's just for experimentation.
After looking at the Fujitsu site, I can see that like most things on a
PC, 100's of decisions<g> have to be made concerning platform
(Win, .NET, etc).
Thanks - Gary
"Michael Wojcik" <mwo...@newsguy.com> wrote in message
news:cf2qt...@news3.newsguy.com...
Rick Smith
<docd...@panix.com> wrote in message news:cetdfp$mnk$1...@panix5.panix.com...
>
> So... I was being consulted on a program's design and mention was made of
> the FD; reflexively I responded that the record layout in the FD should be
> as simple as possible, e.g.
>
> FD INFILE
> BLOCK CONTAINS 0 RECORDS
> .
> 01 INFILE-REC PIC X(160).
>
> ... and that everything should be dealt with in WORKING-STORAGE using READ
> INTO and WRITE FROM.
>
> This, of course, is what was taught to me lo, those many decades back; the
> specific of 'Thou shalt not perform arithmetic manipulations in file
> buffers' was expanded into the zero-tolerance rule of 'Thou shalt not
> touch file buffers; all will be done in WORKING-STORAGE via READ INTO and
> WRITE FROM.'
>
> A few years back... not too long ago, maybe 1988, 1989, I was called in to
> help a coder who was getting some whacky results... and sure enough, he
> was doing arithmetice manipulations on the FDand the numbers were coming
> out screwy. Granted, the platform was WANG VS... but the Ancient Teaching
> was proven right.
>
> Things have changed since then, of course, and the Thou Shalt/Shalt Nots
> dating back to ENIAC may no longer be applicable... so I wonder:
>
> chalked up to sloppiness, e.g. changing a key's position/length and not
> updating the WORKING-STORAGE layout to match) which might happen due to
> continuing to adhere to this? What is more likely to Go Wrong by holding
> to this 'standard'?
While I cannot identify that which 'is more likely to GoWrong',
I can suggest that the practice may violate the 'two-year programmer
rule'.
Standard COBOL, language reference manuals, and instructional texts
place those record description entries that are associated with files in the
FILE SECTION. From the texts I have read, this is what new progammers
are taught -- it is what some of us old programmers have retained.
Mr Dwarf, it seems to me that the 'standard' you described is contrary
to the tenor of COBOL, its teachings, and, while there may have been,
as you stated, reasons for following this 'standard' in the past, the
continuation of the practice seems unneccesary.
If the 'two-year programmer rule' is intended to prevent
'harm/damage/bad stuff ', then a practice contrary to what 'two-year
programmers' have been taught is suspect.
docd...@panix.com
One step at a time, Mr Smith... are you saying, then, that a 'two-year
programmer' is not expected to be conversant with the READ INTO and WRITE
FROM constructs?
I ask this, rather incredulously, because the 'zero-tolerance rule' (and
the associated syntaces for READ INTO and WRITE FROM) I mention above was
taught in my first COBOL class; if the curriculum has changed that much
(or my own experience was that disparate) then I might do well to revisit
what I expect from a 'two-year programmer'.
>
>Standard COBOL, language reference manuals, and instructional texts
>place those record description entries that are associated with files in the
>FILE SECTION. From the texts I have read, this is what new progammers
>are taught -- it is what some of us old programmers have retained.
Sadly enough, the only text I have at hand is McCracken's 'A Simplified
Guide to Structured COBOL Programming'... granted that it does not apply
the Thou Shalt the instructor gave us but the syntaces are given and a
reason for them.
(They are covered in Chapter Eight, 'Sequential File Processing (Part II)
and Subroutines'; the sub-heading under which they appear is 'A simple
merge program' (p.230).)
If what you say is true, and, generally, texts do not emphasise that Thou
Shalt Not touch file buffers (etc)...' ... well, this might be seen as Yet
Another Reason why one needs a text *and* an instructor, both.
>
>Mr Dwarf, it seems to me that the 'standard' you described is contrary
>to the tenor of COBOL, its teachings, and, while there may have been,
>as you stated, reasons for following this 'standard' in the past, the
>continuation of the practice seems unneccesary.
Mr Smith, I have no familiarity whatsoever with the 'tenor' of COBOL;
while what 'seems' can be dependent on who is observing what I asked is a
matter of fact: 'What is more likely to Go Wrong by holding to this
'standard'?'
>
>If the 'two-year programmer rule' is intended to prevent
>'harm/damage/bad stuff ', then a practice contrary to what 'two-year
>programmers' have been taught is suspect.
There's the rub, Mr Smith... the only textbook I have available indicates
that READ INTO and WRITE FROM are, clearly and unambiguously, a part of
what is labelled 'A Simplified Guide' and are covered under the subheading
of 'a simple merge program'. If a two-year programmer is no longer
expected to be familiar with such concepts then, indeed, something might
Go Wrong when using them.
DD
James J. Gavan
Well Michael may be a superb programmer, (I don't know what his role
is). For sure, he'd make a lousy salesman :-)
Other vendors may have tutorial versions of their products, but the
following extract is more specific :-
Begin quote << A new version of Net Express University Edition has
been released, Net Express with .NET University Edition. That is Net
Express v4.0 plus the .NET add-on. If you do not want to install the .NET
stuff you do not have to you can just install v4.0. The product is the full
product with all functionalities of the GA product with only one
restriction, the maximum number of lines of code allowed per program. That
limit is 2200. And the price is $149 USD, http://www.microfocus.com/shop/.
Quite a bargain. The product does not come with standard maintenance of
course but will be updated on a regular basis as the GA product is.
The product information for that version of Net Express University Edition
can be found here;
http://www.microfocus.com/shop/description.asp?productid=39
end of quote >>
You're familiar with M/F already, and with above you are ahead of me in the game; I'm still using N/E V.3.1. The above limitation of 2,200 lines is not a serious restriction for experimentation, plus you'll also be familiar with the fact that using the "Ignore the red tape" features, you can leave out syntax you don't need. Of course if you are in the habit of using 'READ INTO ........" since Pontius was a Pilate - then that marginally increases your source line usage :-)
Not sure - but I think the University price is subtracted when you buy the full product.
As a University Edition user, you can go to M/F site and sign up for Answer Exchange, (freebie). You can post queries against the sub-heading "University Edition" - anyway you can also access the main Net Express thread for ideas.
Don't let's get delusional - the full price isn't cheap, (you would have to quiz M/F on prices). Plus there are runtime fees. But as a Fujitsu user just replied to me, "Their (F/J) prices are hitting the roof..." as well. F/J doesn't have runtime fees, but on the downside check out their Tech Support, or lack thereof (???)
Michael I'm getting awfully tired of pointing people at Answer Exchange - bitch at your sales people to give you a text extract one of you could post in response to this type of compiler query, plus of course 'suck-it-and-see' using the UE. Now if some "kind person' would give me the the upgrade to N/E 4.0 as a 'freebie' - I would happily post here whatever you want !
Jimmy, Calgary AB
Thanks.
Rick Smith
<docd...@panix.com> wrote in message news:cf5mrl$c4p$1...@panix5.panix.com...
Mr Dwarf, you wrote, above, 'I responded that the record layout in the
FD should be as simple as possible ...and that everything should be dealt
with in WORKING-STORAGE using READ INTO and WRITE FROM'.
Clearly, one cannot 'deal with' the record layout using 'READ INTO and
WRITE FROM'. 'READ INTO and WRITE FROM' are incidental to
the placement of the record layout for the file. Thus, the first step is to
determine where best to place the record layout for the file. What I stated
below was 'Standard COBOL, language reference manuals, and
instructional texts place those record description entries that are
associated
with files in the FILE SECTION.' So, eventhough a 'two-year programmer'
may be conversant with 'READ INTO and WRITE FROM', that
programmer may be unfamiliar with describing and using a file's record
layout in the WORKING-STORAGE SECTION. I do not contend that
this is a major obstacle, only that it is an obstacle that must be overcome.
One potentional problem in describing storage is that the redefinition of
record descriptions is implicit in the FILE SECTION; but must be explicit
in the WORKING-STORAGE SECTION. A programmer taught to use
the FILE SECTION may need to learn from a 'bad' experience that things
are different.
Another is the processing of variable length records using COBOL 85
syntax. As I understand it, there are cases with ODO tables where the
actual record layout must be described in the FILE SECTION. But,
maybe such is not for the two-year programmer.
> >
> >Standard COBOL, language reference manuals, and instructional texts
> >place those record description entries that are associated with files in
the
> >FILE SECTION. From the texts I have read, this is what new progammers
> >are taught -- it is what some of us old programmers have retained.
>
> Sadly enough, the only text I have at hand is McCracken's 'A Simplified
> Guide to Structured COBOL Programming'... granted that it does not apply
> the Thou Shalt the instructor gave us but the syntaces are given and a
> reason for them.
>
> (They are covered in Chapter Eight, 'Sequential File Processing (Part II)
> and Subroutines'; the sub-heading under which they appear is 'A simple
> merge program' (p.230).)
>
> If what you say is true, and, generally, texts do not emphasise that Thou
> Shalt Not touch file buffers (etc)...' ... well, this might be seen as Yet
> Another Reason why one needs a text *and* an instructor, both.
I did a cursory review of six texts looking for the location of record
description entries for files and the use of READ and WRITE. All placed
record layouts for files in the FILE SECTION. In all, except one, READ
was used to describe processing. In all, the primary use for WRITE FROM
was for printed reports.
> >
> >Mr Dwarf, it seems to me that the 'standard' you described is contrary
> >to the tenor of COBOL, its teachings, and, while there may have been,
> >as you stated, reasons for following this 'standard' in the past, the
> >continuation of the practice seems unneccesary.
>
> Mr Smith, I have no familiarity whatsoever with the 'tenor' of COBOL;
> while what 'seems' can be dependent on who is observing what I asked is a
> matter of fact: 'What is more likely to Go Wrong by holding to this
> 'standard'?'
Mr Dwarf, as I stated above, 'I cannot identify that which 'is more likely
to
GoWrong''. The reason being, in part, that I have no experience from which
to make such an identification. I have never used the practice you described
and I do not recall ever having seen it used. I do recall that an older
system
written for IBM COBOL F always used records with a key of
HIGH-VALUES on each indexed file and ended processing when the key
was encountered. I assume this was to prevent some problems that may have
occurred at end of file. But, this system still placed the record layout in
the
FILE SECTION.
Thus, I am left only to speculate that a 'two-year programmer' may be
confused why a practice not taught is followed and that this confusion may
cause problems.
> >
> >If the 'two-year programmer rule' is intended to prevent
> >'harm/damage/bad stuff ', then a practice contrary to what 'two-year
> >programmers' have been taught is suspect.
>
> There's the rub, Mr Smith... the only textbook I have available indicates
> that READ INTO and WRITE FROM are, clearly and unambiguously, a part of
> what is labelled 'A Simplified Guide' and are covered under the subheading
> of 'a simple merge program'. If a two-year programmer is no longer
> expected to be familiar with such concepts then, indeed, something might
> Go Wrong when using them.
Three recent texts, based on COBOL 85, provide many examples
including the merging of files without using READ INTO and WRITE
FROM. Mr Dwarf, I do not always know my expectations until I find
something that offends my sensibilities; but if an employer expects a
two-year programmer to be familiar with concepts no longer taught
this may result in disappointment for both.
docd...@panix.com
Rick Smith <rick...@mfi.net> wrote:
>
><docd...@panix.com> wrote in message news:cf5mrl$c4p$1...@panix5.panix.com...
[snip]
>> Mr Smith, I have no familiarity whatsoever with the 'tenor' of COBOL;
>> while what 'seems' can be dependent on who is observing what I asked is a
>> matter of fact: 'What is more likely to Go Wrong by holding to this
>> 'standard'?'
>
>Mr Dwarf, as I stated above, 'I cannot identify that which 'is more likely
>to
>GoWrong''.
Many thanks, Mr Smith, for addressing the question I asked in so direct a
fashion.
>The reason being, in part, that I have no experience from which
>to make such an identification. I have never used the practice you described
>and I do not recall ever having seen it used.
Thanks again, Mr Smith, for being so forthright about the amount of
familiarity you have with the subject about which I am inquiring; it is
good to be able to know about the experiences one has had which go into a
public pronouncement.
DD
Rick Smith
<docd...@panix.com> wrote in message news:cf684e$16l$1...@panix5.panix.com...
You are most welcome, Mr Dwarf. It is the comparative 'more likely'
and the condition 'by holding to this 'standard'' that provides the
difficulty.
To give an example of a 'What', one must have experience of both.
Effectively, one must have had a problem doing 'everything' in working
storage and needed to move the complete record layout to the file
description entry to correct the problem. By not adhering to the described
practice, I never experienced any of its potential problems. Hmm! I
suppose that I must admit that I am not sorry that I could not help more
than I may have.
docd...@panix.com
Well, Mr Smith... if it were easy then I might not have felt the need to
make this inquiry to so august a forum as this, no?
>To give an example of a 'What', one must have experience of both.
That could be why I structured the query as I did, Mr Smith; I related
what I had been taught and (as a result of this teaching) practised, along
with a half-remembered situation a few decades old on a platform which is
not the most common... and asked what others had learned and experienced.
DD
Michael Wojcik
In article <IkuRc.52368$J06.32462@pd7tw2no>, "James J. Gavan" <jjg...@shaw.ca> writes:
>
> Well Michael may be a superb programmer, (I don't know what his role
> is).
These days, it's mostly the comms infrastructure for Enterprise
Server, and before that it was various MF middleware products. It's
only recently that I've actually been using MF COBOL myself to any
significant extent.
> For sure, he'd make a lousy salesman :-)
Ah well. I shall continue to labor in the code pits.
> [snip helpful description of University Edition]
> Michael I'm getting awfully tired of pointing people at Answer
> Exchange - bitch at your sales people to give you a text extract one
> of you could post in response to this type of compiler query, plus of
> course 'suck-it-and-see' using the UE.
To be fair, I think they do provide product-description boilerplate
from time to time. I just toss it in some email folder somewhere
and forget about it. (I *would* make a lousy salesman.) You're
right, though - I should dig it out for occasions like this.
Thanks for mentioning UE.
--
Michael Wojcik michael...@microfocus.com
This is a "rubbering action game," a 2D platformer where you control a
girl equipped with an elastic rope with a fishing hook at the end.
-- review of _Umihara Kawase Shun_ for the Sony Playstation
Clark F. Morris, Jr.
> The following applies ONLY to IBM's mainframe environment.
>
> A little "history"
>
> 1) With pre '74 Standard OS/VS COBOL (and earlier, e.g. ANS V4 product) it was
> possible to "access" the record (as described under an FD) before an OPEN and
> after a CLOSE. (This was NOT documented as valid - but worked) Therefore, it
> was a "medium common" to have
>
> READ file-name
> AT END
> MOVE HIGH-VALUES TO record-name
>
> IF record-name NOT = HIGH-VALUES ....
>
> Somewhere around "LANGLVL(2)" and/or VS COBOL II (I can't remember which), this
> no longer worked and LOTS of programs "died" at run-time. Therefore, the "new
> Standard" of always doing a READ INTO and WRITE FROM became very common in IBM
> shops. (Even though the only "real" problem was accessing the record before an
> OPEN and after a CLOSE.
>
> 2) When IBM (eventually) moved ACB's (VSAM) and DCB's (QSAM) "above the 16M
> line", it became possible (and in come - not all cases) for the "block" to be
> read into storage above the line, but for a copy of the record to be "moved"
> below the line. It was this below-the-line area that was accessed by the
> program. Therefore, previously "working" (but not documented as valid) programs
> that did negative subscripting to get to a variable length record's LLZZ field -
> or to try and get to "block" information from the record, would fail. Again, to
> avoid the "temptation" to use these techniques, the READ INTO and WRITE FROM
> formats were made "shops standards".
>
As someone who coded varying flavors in varying flavors of IBM COBOL
from DOS COBOL from releases 18 - 26 of 360 DOS through COBOL for MVS
and VM, this is not the way it worked. In COBOL VS and COBOL 68, the
Get Locate mode of reading was used for sequential files other than VSAM
ESDS data sets. The AT END condition caused the record pointer to
become indeterminate or 0. System 0C4 abends - protection exceptions
resulted if you attempted to address the record area for a file after
the AT END condition occurred. VS COBOL II at the release 1.4 level if
not before changed this so that the record area for a file was
addressable after the AT END condition occurred. My guess is that this
was done to be consistent with the detection of an AT END condition on a
VSAM KSDS - Indexed file where you had to be able to move a key value to
the record area to issue a START command. This was confirmed by testing
and by showing this I was able to persuade one shop to eliminate the
standard of READ INTO since it had not been rigorously enforced anyway.
The advent of the Language Environment dumps for COBOL showing the
record areas associated with the files clinched the argument for
eliminating the sporadically enforced standard. My personal preference
has been for READ as opposed to READ INTO especially because of
considerations for Keyed files. Also it is inefficient for
multi-format, multi-length record files. Obviously there are a number
of people who vehemently disagree with me. The debate probably dates
back to when READ INTO first became available.
> ***
>
> Not for history (but current)
> I have checked both the Enterprise COBOL "Tuning" White Paper and the
> "Programming Guides" and can find no indication that there is any performance
> advantage/disadvantage of one technique over the other. I am *not* an Assembler
> programmer, but I believe that S/3x0 Assembler provides support for "locate" and
> "move" modes for reads (writes). I seem to recall discussions of which performs
> better - and why doesn't COBOL use one over the other (in certain cases).
> However, there doesn't seem to be any documented way for a COBOL programmer to
> "insure" which is used - much less which will perform better.
>
> Finally, if you are positioning IBM mainframe programs for "multi-threading" you
> should read the section at:
>
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg20/4.4.4
>
> which does explicitly mention "implicit serialization lock" with READ INTO and
> WRITE FROM
>
docd...@panix.com
Clark F. Morris, Jr. <cfm...@istar.ca> wrote:
[snip]
>My personal preference
>has been for READ as opposed to READ INTO especially because of
>considerations for Keyed files. Also it is inefficient for
>multi-format, multi-length record files.
Mr Morris, I know of no test the results would indicate such. Might you
be so kind as to point me towards one so that I could report my results to
the group?
>Obviously there are a number
>of people who vehemently disagree with me.
At this point I have insufficient information to agree or disagree, Mr
Morris... hence my request.
DD
JerryMouse
> preference
> has been for READ as opposed to READ INTO especially because of
> considerations for Keyed files. Also it is inefficient for
> multi-format, multi-length record files. Obviously there are a number
> of people who vehemently disagree with me. The debate probably dates
> back to when READ INTO first became available.
I agree about the (modest?) inefficiency. In my view, though, the loss in
production inefficiency is more than made up for by avoiding catastrophe (of
the torches and pitchfork variety) by bothering the data in an FD.
READ INTO, like giving an enema to a dead man, can't hurt.
----
PS
I just finished a Carl Hiaasen book, "SKiNNY DiP." One of the minor
characters - a one man brute squad - has an interesting hobby: He steals
roadside crosses and re-erects them in his backyard. Has over 40. His
backyard looks like a miniature Arlington.
Another very minor character says, at one point to a main character:
"Understand that I'm not a well person. I'm muddling through a rough spell
at the moment, the man said. "For instance, I've got a hunch you don't even
marginally resemble H.R. Haldeman. Bob, they used to call him at the White
House."... "Anyway, that's who I'm hallucinating when I look at you - Bob
Haldeman. So keep that in mind. Plus, I've got a hideous duet running like a
freight train through my skull -- 'Hey, Jude,' as performed by Bobbie Gentry
and Placido Domingo. It's a fucking miracle I haven't disemboweled myself."
One of the less sane characters in the book.
docd...@panix.com
JerryMouse <nos...@bisusa.com> wrote:
>Clark F. Morris, Jr. wrote:
>> My personal
>> preference
>> has been for READ as opposed to READ INTO especially because of
>> considerations for Keyed files. Also it is inefficient for
>> multi-format, multi-length record files. Obviously there are a number
>> of people who vehemently disagree with me. The debate probably dates
>> back to when READ INTO first became available.
>
>I agree about the (modest?) inefficiency.
As mentioned to Mr Clark, I know of no test the results of which would
indicate such. Outside of each WRITE requiring a MOVE from
WORKING-STORAGE to the DATA RECORD (accomplished nowadays on an IBM
mainframe by the equivalent of an MVC) the efficiency should be
identical... of course, this is not a world where 'should be' equals 'is',
hence my request for the tests upon which the conclusions about
inefficiencies are made.
>In my view, though, the loss in
>production inefficiency is more than made up for by avoiding catastrophe (of
^^
>the torches and pitchfork variety) by bothering the data in an FD.
Wow, I'm glad I've *never* done anything like that... and I'm glad I'm the
King of England, too!
DD
Joe Zitzelberger
There are many programming standards that are similar in function to
givng a corpse an enema...
docd...@panix.com
>givng a corpse an enema...
I've had to adhere to a variety of programming standards in a variety of
places, aye, but I've never attended to the latter task mentioned; I will
yield, in this evaluation, to the Voice of Experience.
DD
JerryMouse
>>
>> There are many programming standards that are similar in function to
>> givng a corpse an enema...
>
> I've had to adhere to a variety of programming standards in a variety
> of places, aye, but I've never attended to the latter task mentioned;
> I will yield, in this evaluation, to the Voice of Experience.
Maybe not an enema, but a lot of programming projects are similar to putting
lipstick on a corpse.
docd...@panix.com
I'm likewise and similarly inexperienced in such matters... but I can, at
times, write code and Just for Laffs put together an experiment.
(Platform: IBM mainframe, compiler: IBM Enterprise COBOL for z/OS and
OS/390 3.2.0)
Given a FILE-CONTROL of
SELECT IOFILE
ASSIGN IOFIL
ORGANIZATION IS INDEXED
ACCESS MODE IS DYNAMIC
FILE STATUS IS IO-STATUS
RECORD KEY IS IO-KEY-SSN OF IOFILE.
... and an FD of
FD IOFILE.
01 IOFILE-RECORD.
03 FILLER PIC X(01).
03 IO-KEY-SSN PIC X(09).
03 FILLER PIC X(238).
... and a PROCEDURE DIVISION of
OPEN I-O IOFILE.
THE-READ.
READ IOFILE NEXT.
THE-READ-INTO.
READ IOFILE NEXT INTO IO-RECORD.
THE-WRITE.
WRITE IOFILE-RECORD.
THE-WRITE-FROM.
WRITE IOFILE-RECORD FROM IO-RECORD.
THE-GOBACK.
GOBACK.
... and the compiler invocation parameters of
PARM='SIZE(MAX),LIB,NUMPROC(MIG),MAP,DYNAM,
XREF,OPT,FLAG(I,I),NOSEQ,TEST(NONE,SYM),LIST'
(chosen for the Very Good Reason of... I just happened to have them
hanging about)
... I found that the READ and the READ INTO were identical for the first
fourteen instructions. The READ terminated with (the MVI below is
instruction number twelve)
MVI 179(4),X'04' FCB=1
MVC 0(2,3),169(10) (BLW=0)+0
GN=16 EQU *
GN=15 EQU *
... while the READ INTO had (again, the MVI is the twelvth instruction):
MVI 179(4),X'04' FCB=1
MVC 0(2,3),169(10) (BLW=0)+0
GN=18 EQU *
L 5,308(0,9) BLF=0
MVC 8(248,3),0(5) IO-RECORD
GN=17 EQU *
Likewise, but reversed, the WRITE and the WRITE FROM were identical for
the last eight instructions; the WRITE FROM was prefaced with:
L 4,308(0,9) BLF=0
MVC 0(248,4),8(3) IOFILE-RECORD
... and all that follows is more-or-less the same.
Granted that the example given is for a single-format, single-indexed
file; I am still most interested in seeing the test which demonstrates
that inefficiencies wrought by these two instructions are a quantifiable
cause for concern.
DD
JerryMouse
> In article <nPqdna-brYU...@giganews.com>,
> JerryMouse <nos...@bisusa.com> wrote:
>> docd...@panix.com wrote:
>>>>
>>>> There are many programming standards that are similar in function
>>>> to givng a corpse an enema...
>>>
>>> I've had to adhere to a variety of programming standards in a
>>> variety
>>> of places, aye, but I've never attended to the latter task
>>> mentioned;
>>> I will yield, in this evaluation, to the Voice of Experience.
>>
>> Maybe not an enema, but a lot of programming projects are similar to
>> putting lipstick on a corpse.
>
> I'm likewise and similarly inexperienced in such matters... but I
> can, at times, write code and Just for Laffs put together an
> experiment.
I love experiments.
I agree that a piddly MVI instruction or two is sticking two fingers in the
dyke (dike?)* when one is sufficient. I've seen people force one finger in
the dike (dyke?) when no fingers were necessary at all. Usually the same
people who go nuts over micro-efficiency have no problem with tape sorting.
-----
* Sorry, I don't speak Dutch so I'm not sure which word is correct. I have
the same problem reading the numbers on Mexican license plates.
docd...@panix.com
JerryMouse <nos...@bisusa.com> wrote:
>docd...@panix.com wrote:
>> In article <nPqdna-brYU...@giganews.com>,
>> JerryMouse <nos...@bisusa.com> wrote:
>>> docd...@panix.com wrote:
>>>>>
>>>>> There are many programming standards that are similar in function
>>>>> to givng a corpse an enema...
>>>>
>>>> I've had to adhere to a variety of programming standards in a
>>>> variety
>>>> of places, aye, but I've never attended to the latter task
>>>> mentioned;
>>>> I will yield, in this evaluation, to the Voice of Experience.
>>>
>>> Maybe not an enema, but a lot of programming projects are similar to
>>> putting lipstick on a corpse.
>>
>> I'm likewise and similarly inexperienced in such matters... but I
>> can, at times, write code and Just for Laffs put together an
>> experiment.
>
>I love experiments.
I do also... especially when I don't know what the results are going to
be!
>
>I agree that a piddly MVI instruction or two is sticking two fingers in the
>dyke (dike?)* when one is sufficient.
Gah... not MVI, MVC. MVI is an SI-format instruction and MVC is an
SS-format... I remember reading someplace (maybe in the back of a Murach
CICS book?) that an SS-format takes about three times as long as an SI...
but long before I read that I had been taught that, when possible, to make
flags, switches, indicators, 88-levels and suchlike because 'it's faster'.
Wasn't until much later that I learned those single characters compiled to
SI-format MVI and CLI, larger ones were MVC and CLC.
And... I am not Dutch, either, but I was taught that 'dike' is the
flood-preventing berm and 'dyke' is an offensive colloquialism... but
www.dictionary.com shows things which might be interpreted otherwise.
DD
Clark F. Morris, Jr.
I base this on the generated code for the READ followed by the implied
MOVE. In the case of a single or multi-format variable length record
the move on a z series system would be to load the sending and receiving
record addresses, the sending and receiving field lengths and the fill
character into registers and then execute a MVCL - Move Character Long.
The sending field length would be 4 less than the value in the first
two bytes of the record as seen by the system (the first four bytes of
the record are not visible to the COBOL program except through
contortions). This will move the number of bytes actually in the input
record and then space fill the rest of the record as required. The MVCL
is not one of the most efficient instructions in the z series set and is
interruptible. Thus code is generated to handle the possibility of
interruption. Granted, any inefficiencies normally will be negligible
compared to all of the other processing going on. Note this problem
exists for all variable length record files whether the file is composed
of multiple record types with different fixed lengths or one record type
that is true variable length. WRITE FROM is more efficient than WRITE
for Variable Length Record sequential files on z/OS because it allows
the maximum number of records to be packed into the maximum block size
allowed.
My personal belief is that you are open to fewer surprises if you
process the records for keyed (VSAM on z/OS) files in the FD because of
the rules for that kind of file handling. I am sure other members on
the list could make good cases for the READ INTO / WRITE FROM.
>
> DD
>
LX-i
> <docd...@panix.com> wrote:
>
>>Walter Murray <wmu...@midtown.net> wrote:
>>
>>>Could you
>>>give an example of what needs to be avoided?
>>
>>Arithmetic manipulations... things like ADD, SUBTRACT, MULTIPLY, DIVIDE
>>and COMPUTE, for a start.
>>
>>FD INFILE.
>>01 INREC.
>> 05 INREC-NUMFLD1 PIC S9(5)V99 COMP-3.
>> 05 INREC-NUMFLD2 PIC S9(5)V99 COMP-3.
>> 05 INREC-NUMFLD3 PIC S9(5)V99 COMP-3.
>> 05 INREC-NUMFLD4 PIC S9(5)V99 COMP-3.
>>
>>ADD INREC-NUMFLD1 TO INREC-NUMFLD2.
>>DIVIDE INREC-NUMFLD1 BY INREC-NUMFLD4.
>>SUBTRACT 3.14 FROM INREC-NUMFLD3.
>>MULTIPLY INREC-NUMFLD3 BY 5.
>>
>>... and suchlike.
>
>
> That's what I thought you were saying. But this is perfectly legal standard
> COBOL, right? (Well, except for the missing GIVING phrases on the DIVIDE
> and the MULTIPLY, and the use of COMP-3, a common extension.)
Are you saying that the standard mandates GIVING for multiply and divide
statements? I'm not sure I concur with that... In every COBOL I've
ever used, giving was listed as [GIVING] (meaning it was optional).
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi...@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++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
LX-i
> Does anyone know of harm/damage/bad stuff (outside of that which can be
> chalked up to sloppiness, e.g. changing a key's position/length and not
> updating the WORKING-STORAGE layout to match) which might happen due to
> continuing to adhere to this? What is more likely to Go Wrong by holding
> to this 'standard'?
In my opinion, Read Into / Write From are "safer," especially in a
maintenance environment. Sure, _you_ know what you're doing, but the
next person to come along may not. And, with the intricacies of when
the contents of the FD are reliable and when they are not, it makes
sense to use the aforementioned technique. "Quick fixes" are more
likely to work, especially if they're done (as they often are) without
proper analysis first. :)
Warren Simmons
contain some identity. For example, the serial number of the compiler
that produced it showing the release and date of writing. Then down the
line it would be possible to create a reference library of such
"versions" by vendor that would identify the kinds of quirks that
existed with this file as it was created. Also, in a future extension
of the life of this file a chain of references could exist for the
possible need to decipher the data. Concerns over encryption could
be referenced and documented. Some data is lots more critical than
others. While this is just a balloon assent ion for me at this time,
more and more problems that are brought to light in this forum could
be planned for with some kind of system that addresses these kinds of
problems.
Warren Simmons
wsim...@optonline.net
docd...@panix.com
I was wondering if someone else would notice that.
DD
docd...@panix.com
LX-i <lxi...@netscape.net> wrote:
>docd...@panix.com wrote:
>
>> Does anyone know of harm/damage/bad stuff (outside of that which can be
>> chalked up to sloppiness, e.g. changing a key's position/length and not
>> updating the WORKING-STORAGE layout to match) which might happen due to
>> continuing to adhere to this? What is more likely to Go Wrong by holding
>> to this 'standard'?
>
>In my opinion, Read Into / Write From are "safer," especially in a
>maintenance environment. Sure, _you_ know what you're doing, but the
>next person to come along may not.
... especially when I am both; have you ever looked at some years-old code
and thought 'Who *wrote* this trash... oh, lookee there, I done it!'?
DD
Rick Smith
<docd...@panix.com> wrote in message news:cf7fe1$h31$1...@panix5.panix.com...
I am curious, Mr Dwarf, why did you include the restriction '(outside
of that which can be chalked up to sloppiness, e.g. changing a key's
position/length and not updating the WORKING-STORAGE layout
to match) '? I ask because these types of errors appear to that which
'is more likely to Go Wrong'. In each of the cases that comes to mind,
the example you provided as, making 'the record layout in the FD ...
as simple as possible', prevents certain compile time checks, for such
'sloppiness', allowing this 'sloppiness' to become runtime errors and
anomalies.
Also, do I understand correctly that your making 'the record layout
in the FD ... as simple as possible' is intended to enforce the
'zero-tolerance rule' (which you mentioned as having been taught in
your first COBOL class)? I ask this because both GC28-6403-0,
"IBM System/360 Disk Operating System Subset American
National Standard COBOL" (aka COBOL E), and GC28-6396-5,
"IBM OS Full American National Standard COBOL" (aka
COBOL F) show nearly identical sample programs for "Random
retrieval and updating of an indexed file". These sample programs
use only the file buffers for processing. The only item in working
storage being the NOMINAL KEY for the indexed file. The
updating of the indexed file record was the instruction
'ADD CD-AMT TO DISK-AMT', followed by a REWRITE.
Thus, not only are file buffers touched but arithmetic is done on
an item in them. I wonder, Mr Dwarf, whether the instructors 'Thou
Shalts' were the result of working with a non-conforming compiler.
For example, if the instructor had problems with using, let's say, a
COBOL 74 compiler for Wang VS and developed his 'Thou
Shalts' based upon overcoming those problems; then was it
COBOL or something else that was taught?
I found that I had a similar experience ('sloppiness') when I updated
a system. Different record descriptions were used to descibe a
record, one a complete description in the FD, the other a PIC X(xxx)
in working storage, which was used to hold a copy of the record,
temporarily. When I modified some fields in the copy book for the
complete description. I failed to notice the copy of the record.
During testing the program failed. Needless to say, I was not happy
with discovering this 'sloppiness'.
I have one, personal, program in which I use READ INTO and
WRITE FROM, exclusively. There was, at one point, eight record
descriptions for the same record type. I chose to use COPY
REPLACING (partial text replacement) to create unique data
names for processing of the records in various procedures.
Mr Dwarf, I have carefully reviewed a lot of material, including my
experience, trying to find some rational basis for the general
applicability of the 'zero-tolerance rule', I found none.
Richard
> >>ADD INREC-NUMFLD1 TO INREC-NUMFLD2.
> >>DIVIDE INREC-NUMFLD1 BY INREC-NUMFLD4.
> >>SUBTRACT 3.14 FROM INREC-NUMFLD3.
> >>MULTIPLY INREC-NUMFLD3 BY 5.
> Are you saying that the standard mandates GIVING for multiply and divide
> statements? I'm not sure I concur with that... In every COBOL I've
> ever used, giving was listed as [GIVING] (meaning it was optional).
The arithmetic operations in the original Cobol were designed such
that the result goes into the final operand, as it does for MOVE. If
there is a GIVING then that is the final and the result goes there.
In statements without GIVING such as:
ADD A TO B
SUBTRACT A FROM B
MULTIPLY A BY B
DIVIDE A INTO B
The results go into B.
However, with DIVIDE A BY B logically the result should go into A, but
this would break the rule about final operand. Thus with DIVIDE .. BY
.. the GIVING is _not_ optional. It is optional with DIVIDE .. INTO
.. and the other operations.
The MULTIPLY requires a GIVING because the final operand is a literal
which is illegal for a receiving field. If it had been MULTIPLY 5 BY
InRec-NumFld3 it would have been perfectly valid without a GIVING.
docd...@panix.com
Rick Smith <rick...@mfi.net> wrote:
[snip]
>I am curious, Mr Dwarf, why did you include the restriction '(outside
>of that which can be chalked up to sloppiness, e.g. changing a key's
>position/length and not updating the WORKING-STORAGE layout
>to match) '?
Because sloppiness, Mr Smith, can be found anywhere; it has been said that
'you can make something foolproof, but not damn-fool-proof'.
[snip]
>Also, do I understand correctly that your making 'the record layout
>in the FD ... as simple as possible' is intended to enforce the
>'zero-tolerance rule' (which you mentioned as having been taught in
>your first COBOL class)?
Quite right, Mr Smith... the less there is in the FD which is not defined
as FILLER the less there is in the FD on which to perform any sort of
manipulation.
>I ask this because both GC28-6403-0,
>"IBM System/360 Disk Operating System Subset American
>National Standard COBOL" (aka COBOL E), and GC28-6396-5,
>"IBM OS Full American National Standard COBOL" (aka
>COBOL F) show nearly identical sample programs for "Random
>retrieval and updating of an indexed file". These sample programs
>use only the file buffers for processing. The only item in working
>storage being the NOMINAL KEY for the indexed file. The
>updating of the indexed file record was the instruction
>'ADD CD-AMT TO DISK-AMT', followed by a REWRITE.
>Thus, not only are file buffers touched but arithmetic is done on
>an item in them. I wonder, Mr Dwarf, whether the instructors 'Thou
>Shalts' were the result of working with a non-conforming compiler.
>For example, if the instructor had problems with using, let's say, a
>COBOL 74 compiler for Wang VS and developed his 'Thou
>Shalts' based upon overcoming those problems; then was it
>COBOL or something else that was taught?
Mr Smith, I have absolutely no idea where or how my instructor arrived at
this particular commandment; when he taught it to the class I was too busy
trying to learn COBOL to question his resumee, pedigree or experience.
From some of the comments seen here it appears that the practise of READ
INTO/WRITE FROM was not limited to his classroom.
[snip]
>Mr Dwarf, I have carefully reviewed a lot of material, including my
>experience, trying to find some rational basis for the general
>applicability of the 'zero-tolerance rule', I found none.
That might be why, Mr Smith, that I did not ask for anyone to supply a
'rational basis', I asked if anyone knew of things that might Go Wrong
outside of the general sloppiness I exempted.
To the best of my recollection of this rather lengthy thread... nobody's
reported doing so.
DD
Rick Smith
<docd...@panix.com> wrote in message news:cfngcn$451$1...@panix5.panix.com...
> In article <10hu05v...@corp.supernews.com>,
> Rick Smith <rick...@mfi.net> wrote:
>
> [snip]
>
> >I am curious, Mr Dwarf, why did you include the restriction '(outside
> >of that which can be chalked up to sloppiness, e.g. changing a key's
> >position/length and not updating the WORKING-STORAGE layout
> >to match) '?
>
> Because sloppiness, Mr Smith, can be found anywhere; it has been said that
> 'you can make something foolproof, but not damn-fool-proof'.
Mr Dwarf, would not sloppiness include the teaching of a rule
that has the effect of introducing the potential for sloppiness?
A rule intended to address a problem of uncertain origin?
A rule that is unnecessary with conforming compilers?
Mr Dwarf, from the comments seen here, there is no evidence that
those using READ INTO and WRITE FROM also practice the
'zero-tolerance rule' you described.
> [snip]
>
> >Mr Dwarf, I have carefully reviewed a lot of material, including my
> >experience, trying to find some rational basis for the general
> >applicability of the 'zero-tolerance rule', I found none.
>
> That might be why, Mr Smith, that I did not ask for anyone to supply a
> 'rational basis', I asked if anyone knew of things that might Go Wrong
> outside of the general sloppiness I exempted.
Mr Dwarf, this is usenet and I am merely practicing something I
learned a long time ago, "Question the premises!" The requirement
for READ INTO and WRITE FROM is premised on the
'zero-tolerance rule'. That is, if the rule is irrational, then so may be
the aforementioned requirement. In effect, the rule is a problem -- it
is the rule that might make things Go Wrong.
docd...@panix.com
Rick Smith <rick...@mfi.net> wrote:
>
><docd...@panix.com> wrote in message news:cfngcn$451$1...@panix5.panix.com...
>> In article <10hu05v...@corp.supernews.com>,
>> Rick Smith <rick...@mfi.net> wrote:
>>
>> [snip]
>>
>> >I am curious, Mr Dwarf, why did you include the restriction '(outside
>> >of that which can be chalked up to sloppiness, e.g. changing a key's
>> >position/length and not updating the WORKING-STORAGE layout
>> >to match) '?
>>
>> Because sloppiness, Mr Smith, can be found anywhere; it has been said that
>> 'you can make something foolproof, but not damn-fool-proof'.
>
>Mr Dwarf, would not sloppiness include the teaching of a rule
>that has the effect of introducing the potential for sloppiness?
Mr Smith, I do not know of anything that can be taught which cannot be
applied sloppily.
>A rule intended to address a problem of uncertain origin?
Mr Smith, a problem is a problem, no matter what its origin.
>A rule that is unnecessary with conforming compilers?
Mr Smith, I do not understand what you are intending by 'necessity'; COBOL
is applicable across a variety of compilers.
That just might be why, Mr Smith, I did not ask for the reason that people
did such.
>
>> [snip]
>>
>> >Mr Dwarf, I have carefully reviewed a lot of material, including my
>> >experience, trying to find some rational basis for the general
>> >applicability of the 'zero-tolerance rule', I found none.
>>
>> That might be why, Mr Smith, that I did not ask for anyone to supply a
>> 'rational basis', I asked if anyone knew of things that might Go Wrong
>> outside of the general sloppiness I exempted.
>
>Mr Dwarf, this is usenet and I am merely practicing something I
>learned a long time ago, "Question the premises!"
The premises given, Mr Smith, were:
1) I was taught this rule and this technique.
2) My experience includes a circumstance where neglecting this technique
caused something to Go Wrong.
>The requirement
>for READ INTO and WRITE FROM is premised on the
>'zero-tolerance rule'. That is, if the rule is irrational, then so may be
>the aforementioned requirement. In effect, the rule is a problem -- it
>is the rule that might make things Go Wrong.
And in my experience, Mr Smith, I have run across a situation where
something Went Wrong because the rule was not adhered to; this was a
reinforcement of the teaching I had received. I then inquired of the
group whether someone had experience of the opposite, that being if
something would Go Wrong if the rule *was* adhered to... and to the best
of my recollection of this rather lengthy thread... nobody's reported
doing so.
DD
Walter Murray
> Walter Murray wrote:
> > <docd...@panix.com> wrote:
> >>ADD INREC-NUMFLD1 TO INREC-NUMFLD2.
> >>DIVIDE INREC-NUMFLD1 BY INREC-NUMFLD4.
> >>SUBTRACT 3.14 FROM INREC-NUMFLD3.
> >>MULTIPLY INREC-NUMFLD3 BY 5.
> > That's what I thought you were saying. But this is perfectly legal
standard
> > COBOL, right? (Well, except for the missing GIVING phrases on the
DIVIDE
> > and the MULTIPLY, and the use of COMP-3, a common extension.)
>
> Are you saying that the standard mandates GIVING for multiply and divide
> statements? I'm not sure I concur with that... In every COBOL I've
> ever used, giving was listed as [GIVING] (meaning it was optional).
Yes, for the example MULTIPLY and DIVIDE statements given, Standard COBOL
requires a GIVING phrase.
A DIVIDE ... BY always requires a GIVING phrase. A DIVIDE ... INTO requires
a GIVING phrase if the second operand is a numeric literal or if a REMAINDER
phrase is specified.
A MULTIPLY statement requires a GIVING phrase if the second operand is a
numeric literal.
Walter
Walter Murray
> However, with DIVIDE A BY B logically the result should go into A, but
> this would break the rule about final operand. Thus with DIVIDE .. BY
> .. the GIVING is _not_ optional. It is optional with DIVIDE .. INTO
> .. and the other operations.
It is optional with DIVIDE ... INTO as long as the second operand is not a
numeric literal and the REMAINDER phrase is not specified.
Walter
Clark F. Morris, Jr.
According to my 1985 Draft Standard which I assume was carried over from
previous standards, MULTIPLY A BY B does not require a GIVING clause.
The result is in B. This is contrary to the way many of us would read
the clause and adding a GIVING clause to say MULTIPLY A BY B GIVING B
would probably be clearer to the non-programmer.
Richard
> >>>>MULTIPLY INREC-NUMFLD3 BY 5.
> > In statements without GIVING such as:
> > ...
> > MULTIPLY A BY B
> > ...
> > The results go into B.
> According to my 1985 Draft Standard which I assume was carried over from
> previous standards, MULTIPLY A BY B does not require a GIVING clause.
You should note that I covered this. However, the example above is
invalid because 'B' is a literal which cannot take a result. Thus if
one wanted to have
MULTIPLY variable BY literal
then it _requires_ a GIVING (or reforming so the variale is last).
> The result is in B. This is contrary to the way many of us would read
> the clause and adding a GIVING clause to say MULTIPLY A BY B GIVING B
> would probably be clearer to the non-programmer.
The way one reads such things is the result of what one is used to. I
learned to recognise that the result went in the last operand - then
they brought in 'modern' innovations such as SET, COMPUTE which broke
this.
LX-i
:) Quite recently, in fact. There was a program I "rewrote" because it
was structured quite horridly, and didn't do what it was supposed to do
to boot. I recently looked through the program again, and thought "My
goodness - what was I thinking?" (Coincidentally, it still isn't doing
what it's supposed to be doing - but, the customer has accepted that
it's a flaw in their requirements, and are planning to fix it in the
next major release.)
In the mean time, responsibility for that program has now passed to
someone else - so, I'm sure they'll rewrite my rewrite. Maybe the 3rd
time will be the charm. ;)
LX-i
> LX-i <lxi...@netscape.net> wrote
>
>
>>>>ADD INREC-NUMFLD1 TO INREC-NUMFLD2.
>>>>DIVIDE INREC-NUMFLD1 BY INREC-NUMFLD4.
>>>>SUBTRACT 3.14 FROM INREC-NUMFLD3.
>>>>MULTIPLY INREC-NUMFLD3 BY 5.
>
>
>>Are you saying that the standard mandates GIVING for multiply and divide
>>statements? I'm not sure I concur with that... In every COBOL I've
>>ever used, giving was listed as [GIVING] (meaning it was optional).
>
>
> The arithmetic operations in the original Cobol were designed such
> that the result goes into the final operand, as it does for MOVE. If
> there is a GIVING then that is the final and the result goes there.
Do you know that this is the first time I've heard that? It makes the
seemingly backwards behavior, especially of Multiply and Divide, make
more sense.
> In statements without GIVING such as:
>
> ADD A TO B
> SUBTRACT A FROM B
> MULTIPLY A BY B
> DIVIDE A INTO B
>
> The results go into B.
>
> However, with DIVIDE A BY B logically the result should go into A, but
> this would break the rule about final operand. Thus with DIVIDE .. BY
> .. the GIVING is _not_ optional. It is optional with DIVIDE .. INTO
> .. and the other operations.
>
> The MULTIPLY requires a GIVING because the final operand is a literal
> which is illegal for a receiving field. If it had been MULTIPLY 5 BY
> InRec-NumFld3 it would have been perfectly valid without a GIVING.
Thanks for the clarification - I see now why the original comment was made.
Paul Knudsen
>Does anyone know of harm/damage/bad stuff (outside of that which can be
>chalked up to sloppiness, e.g. changing a key's position/length and not
>updating the WORKING-STORAGE layout to match) which might happen due to
>continuing to adhere to this? What is more likely to Go Wrong by holding
>to this 'standard'?
Other than the small waste of space, there's nothing "wrong" with it I
suppose.
--
Top 10 Conservative Idiots:
http://www.democraticunderground.com/top10/
Paul Knudsen
>But I
>would have the same question - WHY?
>
>OK, you said "I was taught..." and "I experienced...". Didn't you want to
>know WHY there was a problem? It doesn't seem to me like there should be
>any problem with it.
The way I heard it, it was for dumps. Apparently in the old days
they either didn't include the file area, or included the whole thing
and you had to count down to find the current record. So if the CR
was in WS, you could find it much quicker. Makes sense I suppose.
Me, I quit looking at dumps when debuggers came out. Never needed
READ INTO since.
docd...@panix.com
Paul Knudsen <Hu...@dodgeit.com> wrote:
>On 5 Aug 2004 09:42:17 -0400, docd...@panix.com wrote:
>
>>Does anyone know of harm/damage/bad stuff (outside of that which can be
>>chalked up to sloppiness, e.g. changing a key's position/length and not
>>updating the WORKING-STORAGE layout to match) which might happen due to
>>continuing to adhere to this? What is more likely to Go Wrong by holding
>>to this 'standard'?
>
>Other than the small waste of space, there's nothing "wrong" with it I
>suppose.
Thanks much for the observation.
DD
Howard Brazee
On 21-Aug-2004, Paul Knudsen <Hu...@dodgeit.com> wrote:
> The way I heard it, it was for dumps. Apparently in the old days
> they either didn't include the file area, or included the whole thing
> and you had to count down to find the current record. So if the CR
> was in WS, you could find it much quicker. Makes sense I suppose.
That's what I was told in 1980. We put fillers in our Working Storage to make
it easier to find stuff.
> Me, I quit looking at dumps when debuggers came out. Never needed
> READ INTO since.
Formatted dumps really made things easier. I haven't found a debugger yet that
made mainframe batch CoBOL easier.
Don Leahy
"Paul Knudsen" <Hu...@dodgeit.com> wrote in message
news:05qdi0544d2t2rqvo...@4ax.com...<SNIP>
> was in WS, you could find it much quicker. Makes sense I suppose.
>
> Me, I quit looking at dumps when debuggers came out. Never needed
> READ INTO since.
> --
under the debugger?
William M. Klein
Robert Wagner
The Micro Focus debugger (anim) can be run against a dump. It displays
source, same as normal debugging, and puts the cursor on the failing
line. You cannot step through code in that mode, of course, but you
can put the cursor on a data name -- either in procedure or data
division -- to see its value.
Alternatively, they offer a formatted dump (FaultFinder) similar to
that found on mainframes. The debugger approach is the better of the
two.
Robert Wagner
wrote:
> I haven't found a debugger yet that made mainframe batch CoBOL easier.
The fastest debugger can read source and SEE what it does before it's
executed even once. Preemptive debugging. It doesn't cost anything
(extra) but it's seldom used.
Joe Zitzelberger
"Howard Brazee" <how...@brazee.net> wrote:
> On 21-Aug-2004, Paul Knudsen <Hu...@dodgeit.com> wrote:
>
> > The way I heard it, it was for dumps. Apparently in the old days
> > they either didn't include the file area, or included the whole thing
> > and you had to count down to find the current record. So if the CR
> > was in WS, you could find it much quicker. Makes sense I suppose.
>
> That's what I was told in 1980. We put fillers in our Working Storage to
> make
> it easier to find stuff.
There was/is a shop standard that says each programs should have, as the
first and last item in working storage, an 01-level containing text like
"Working Storage Starts Here".
It was a cute idea.
But about the same time the Endevor group turned on the OPTIMIZE option
on the compiler.
So when looking at a dump of storage, you will often see something like:
WORKING STORAGE STARTS HERE><WORKING STORAGE ENDS HERE.OTHER UNALTERED
CONSTANTS THAT WERE IN 01-LEVEL ITEMS. BLAH. BLAH. BLAH.
The compiler felt free to reorder the 01-items, making the practice
somewhat humorous.
> > Me, I quit looking at dumps when debuggers came out. Never needed
> > READ INTO since.
>
> Formatted dumps really made things easier. I haven't found a debugger yet
> that
> made mainframe batch CoBOL easier.
Have you seen IBM Debug Tool with distributed debugger? It is
wonderful. You specify your IP address as an LE Test Parm, e.g:
EXEC PGM=WHATEVER,PARM='something/TEST(10.10.10.10)'
And run the debugger client on your workstation. When WHATEVER begins
executing your workstations debugging client will have control. It
looks alot like any other PC-IDE debugger. You can scroll through the
entire source, view all working storage in the watch box, etc.
Howard Brazee
On 25-Aug-2004, Joe Zitzelberger <joe_zitz...@nospam.com> wrote:
> Have you seen IBM Debug Tool with distributed debugger? It is
> wonderful. You specify your IP address as an LE Test Parm, e.g:
>
> EXEC PGM=WHATEVER,PARM='something/TEST(10.10.10.10)'
>
> And run the debugger client on your workstation. When WHATEVER begins
> executing your workstations debugging client will have control. It
> looks a lot like any other PC-IDE debugger. You can scroll through the
> entire source, view all working storage in the watch box, etc.
I think I tried it once at a different shop. It looks familiar.
Don Leahy
"Robert Wagner" <rob...@wagner.net.yourmammaharvests> wrote in message
news:0kloi090sd7n4gvvb...@4ax.com...
later release of anim than the one my current client is stuck with (vintage
1997) which is of no use at all for debugging mainframe abends.
Our version is so old that, in frustration, some of the programmers are
clamouring to get rid of it, acquire a host debugger, and go back to
developing systems on the mainframe. .
Robert Wagner
<leah...@nospamplease.netscape.net> wrote:
The Mainframe Express data sheet says nothing about reading dumps.
I was describing Server Express, which runs on Unix.
Have you tried running anim against a dump file? You might have to
copy the dump file to your PC. If the IDE doesn't offer that option,
just run it from the command line 'anim filename'. You might have to
copy the .idy to the current directory.
Frank Swarbrick
be) availible for VSE.
How do you initiate it for CICS transactions?
I've never actually used IBM Debug Tool, as it looked to me to not be very
user friendly or dynamically interactive, at least if used only on the
mainframe. Does anyone agree with this? Does anyone use IBM Debug Tool and
prefer it over, say, Intertest or Xpediter?
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
>>> Joe Zitzelberger<joe_zitz...@nospam.com> 8/25/2004 6:54:17 AM >>>
james8049
>Paul Knudsen wrote:
>
>
>
> >The way I heard it, it was for dumps. Apparently in the old days
> >they either didn't include the file area, or included the whole
> thing
> >and you had to count down to find the current record. So if the CR
> >was in WS, you could find it much quicker. Makes sense I suppose.
>
> steam computers.
> The standards usually mandated "READ INTO " solely because it was
> difficult to analyse the "FD" contents in a dump.
>
> I think this was (and is no longer) the sole valid reason for using
> "READ INTO".
> As for the "results are unpredicatable if the file is not open", I,
> think this also holds for "READ INTO" -- if your program is looking
> at the contents of a file before it is even open you have a logic
> error somewhere! In my opinion using "READ INTO " converts an in your
> face obvious error condition into a subtle hard to find error.
--
james8049
------------------------------------------------------------------------
Posted via http://www.codecomments.com
------------------------------------------------------------------------
Joe Zitzelberger
fields, with the program or tran you want to trap. The screen will pop
and you will be in control.
Very easy...
In article <2p6q8qF...@uni-berlin.de>,
james8049
Frank Swarbrick wrote:
> [B]Wow, that looks great! Too bad, once again, it's not (or does not
> appear to
> be) availible for VSE.
>
> How do you initiate it for CICS transactions?
>
CICS transaction DTCN will set you up for debugging.
You can specifiy any combination of Transaction ID, Program ID and User
ID plus the TCP/IP address of your work station.