Home > Archive > Cobol > August 2006 > Side-effecting input FD logical record hazardous?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Side-effecting input FD logical record hazardous?
|
|
| Kenneth 2006-08-09, 6:55 pm |
| Gentlepeople,
I'll start with my conclusion reached from a recent round of debugging,
then recite some of the empirical findings supporting it, and finally
ask for confirmation/response by the group.
Here's the conclusion: Side-effecting (overwriting) any portion of the
logical record in the FD (File Descriptor) area for a variable-length
blocked file is hazardous, leading to unpredictable results such as
S0C7 and S002 Abends. Only the character positions up to the variable
length most recently READ should be considered as "belonging" to the
COBOL program. Characters beyond the length just READ, but still within
the maximum record length in the FD, belong to the Operating System
(COBOL internals or the like), should be considered "off limits" and
should not be modified.
Here's the scenario. IBM Enterprise COBOL 3.2.1. FD had two logical
records defined, as TRANSACTION-HEADER PIC X(121) and TRANSACTION-FULL
PIC X(8196). There were some "garbage" (semicolon) characters in the
input file I desired to clean up "on the fly", by performing an INSPECT
TRANSACTION-FULL REPLACING ALL ';' BY ',' immediately following the
READ TRANSACTION-FILE. Note that the READ was directly into the FD and
not a READ INTO. Also note that the "scope" of the INSPECT would have
been the full length of the 01-level record (8192 characters), and not
restricted to the actual length of the record just READ. The code did
not include an OCCURS DEPENDING ON, but the two differing lengths of
logical records should have caused the compiler to set up the file
description format as variable record lengths (V), not fixed length
(F).
The variable length records were typically a few thousand characters
long, not the full 8192 possible. Program execution showed
unpredictable results when this INSPECT was inserted into the source
and compiled. It would abend seemingly unpredictably, but reproducibly
in the same area of the input file, and a display trace of records read
showed discrepancies with what an ISPF view of the dataset showed. S0C7
sometimes occurred due to a record being read "in the middle" instead
of at the beginning-of-record; more often a QSAM routine would issue an
S002 Reason Code 4, symptomatic of a Record-Descriptor-Word (RDW)
corruption problem in the input dataset.
Amazingly :-), just where the program would abend in the input file
showed a dependency upon the replacement character in the INSPECT,
according to the replacement character's position in the EBCDIC
collating sequence! These abends were reproducible from execution to
execution.
As an experiment, I tried doing a READ INTO into a Working-Storage
area, doing the INSPECT in Working-Storage, and then MOVEing back to
the FD logical record. This also led to the Abends.
However, doing a READ INTO Working-Storage, performing the INSPECT, and
then modifying the program to refer to the Working-Storage record
rather than the FD fixed the problem.
A couple of paragraphs from the COBOL Programming Guide gives us some
hints:
"When you specify a READ INTO statement for a format-V file, the record
size read for that file is used in the MOVE statement generated by the
compiler. Consequently, you might not get the result you expect if the
record just read does not correspond to the level-01 record
description. All other rules of the MOVE statement apply. For example,
when you specify a MOVE statement for a format-V record read in by the
READ statement, the size of the record moved corresponds to its
level-01 record description.
"When you specify a READ statement for a format-V file followed by a
MOVE of the level-01 record, the actual record length is not used. The
program will attempt to move the number of bytes described by the
level-01 record description. __If this number exceeds the actual record
length and extends outside the area addressable by the program, results
are unpredictable__ (emphasis added by me)."
Hmmmm... if I understand this last statement correctly, it is stating
that character positions in the FD 01-level logical record that are
beyond the "actual length" most-recently read may reside outside the
area addressable by the program! My educated guess at this point is
that the "offending INSPECT" was trampling on some OS-dedicated area
containing pointers and such things needed by QSAM to keep track of
things.
I think what this speaks to is the risk associated with input
operations upon variable-length without taking proper safeguards with
actual-record length as tracked by the OCCURS DEPENDING ON variable.
And in general, it is hazardous to modify the 01-record in the FD of a
variable-length input file. Probably best not to do it at all. Always
do it in Working-Storage instead. I think I remember learning this once
about twenty-five years ago, and in my haste to find a quick fix,
forgot it since then. :-)
Comments, anyone?
Ken
| |
|
| In article <1155136131.073287.170930@b28g2000cwb.googlegroups.com>,
Kenneth <klshafer@worldnet.att.net> wrote:
>Gentlepeople,
Who walked in?
[snip]
>However, doing a READ INTO Working-Storage, performing the INSPECT, and
>then modifying the program to refer to the Working-Storage record
>rather than the FD fixed the problem.
[snip]
>I think what this speaks to is the risk associated with input
>operations upon variable-length without taking proper safeguards with
>actual-record length as tracked by the OCCURS DEPENDING ON variable.
>And in general, it is hazardous to modify the 01-record in the FD of a
>variable-length input file. Probably best not to do it at all. Always
>do it in Working-Storage instead. I think I remember learning this once
>about twenty-five years ago, and in my haste to find a quick fix,
>forgot it since then. :-)
>
>Comments, anyone?
As I recall the thread (which might be found at
<http://groups.google.com/group/comp...ee1c188d1805333>
or somewhere thereabouts), nobody posted any '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' insofar as adhering to the 'zero-tolerance rule
of 'Thou shalt not touch file buffers; all will be done in WORKING-STORAGE
via READ INTO and WRITE FROM.'' is concerned.
DD
| |
| Michael Russell 2006-08-09, 6:55 pm |
| Just 'as far' - 'insofar' is so not  there...
It's like a man working his whole life-long
for employers, or exercising his vote in western elections;
free & democratic? Nope, invalid terms.
Different case, of course, but generally within the scope
of using the right word.
Then again, maybe 'insofar' isn't so bad, after all.
Could be subtly ok.
But it's a lawyer's term, so it's not;
that 'not' is unqualified & non-negotiable, as it sits so near
a lawyer.
Well, yes, it has been a long day ..... and I'm just playing
around.
> which might happen' insofar as this, that or the other is concerned.
| |
| Kenneth 2006-08-09, 6:55 pm |
|
docdwarf@panix.com wrote:
> As I recall the thread (which might be found at
> <http://groups.google.com/group/comp...ee1c188d1805333>
> or somewhere thereabouts), nobody posted any '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' insofar as adhering to the 'zero-tolerance rule
> of 'Thou shalt not touch file buffers; all will be done in WORKING-STORAGE
> via READ INTO and WRITE FROM.'' is concerned.
>
> DD
Yes, thank you, Mr. DD, I just now read the thread with interest, and
received reassurance from it.
But 'zero-tolerance rule' for 'Thou shalt not touch file buffers; all
will be done in WORKING-STORAGE via READ INTO and WRITE-FROM' sounds
so, uh, severe, and harsh. Might I apply an alternative "marketing
hook" moniker, in an effort to "sell" it to my peers? Do I have your
permission to obliquely credit you, perhaps with something along the
lines of "Doctor's prescription"?
Ken
| |
| Frank Swarbrick 2006-08-09, 6:55 pm |
| Sounds reasonable.
Another possible solution might be to use the DEPENDING ON clause of the FD
statement, something like...
FILE SECTION.
FD TRANSACTION-FILE
RECORD VARYIING FROM 121 TO 8196 CHARACTERS DEPENDING ON MYREC-LEN.
01 TRANSACTION-HEADER PIC X(121).
01 TRANSACTION-FULL PIC X(8196)
WORKING-STORAGE SECTION.
77 MYREC-LEN PIC 9(4).
PROCEDURE DIVISION.
READ TRANSACTION-FILE
INSPECT TRANSACTION-FULL (1:MYREC-LEN) REPLACING ALL ';' BY ','
I haven't tried it, but I imagine it should work.
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
[color=darkred]
Gentlepeople,
I'll start with my conclusion reached from a recent round of debugging,
then recite some of the empirical findings supporting it, and finally
ask for confirmation/response by the group.
Here's the conclusion: Side-effecting (overwriting) any portion of the
logical record in the FD (File Descriptor) area for a variable-length
blocked file is hazardous, leading to unpredictable results such as
S0C7 and S002 Abends. Only the character positions up to the variable
length most recently READ should be considered as "belonging" to the
COBOL program. Characters beyond the length just READ, but still within
the maximum record length in the FD, belong to the Operating System
(COBOL internals or the like), should be considered "off limits" and
should not be modified.
Here's the scenario. IBM Enterprise COBOL 3.2.1. FD had two logical
records defined, as TRANSACTION-HEADER PIC X(121) and TRANSACTION-FULL
PIC X(8196). There were some "garbage" (semicolon) characters in the
input file I desired to clean up "on the fly", by performing an INSPECT
TRANSACTION-FULL REPLACING ALL ';' BY ',' immediately following the
READ TRANSACTION-FILE. Note that the READ was directly into the FD and
not a READ INTO. Also note that the "scope" of the INSPECT would have
been the full length of the 01-level record (8192 characters), and not
restricted to the actual length of the record just READ. The code did
not include an OCCURS DEPENDING ON, but the two differing lengths of
logical records should have caused the compiler to set up the file
description format as variable record lengths (V), not fixed length
(F).
The variable length records were typically a few thousand characters
long, not the full 8192 possible. Program execution showed
unpredictable results when this INSPECT was inserted into the source
and compiled. It would abend seemingly unpredictably, but reproducibly
in the same area of the input file, and a display trace of records read
showed discrepancies with what an ISPF view of the dataset showed. S0C7
sometimes occurred due to a record being read "in the middle" instead
of at the beginning-of-record; more often a QSAM routine would issue an
S002 Reason Code 4, symptomatic of a Record-Descriptor-Word (RDW)
corruption problem in the input dataset.
Amazingly :-), just where the program would abend in the input file
showed a dependency upon the replacement character in the INSPECT,
according to the replacement character's position in the EBCDIC
collating sequence! These abends were reproducible from execution to
execution.
As an experiment, I tried doing a READ INTO into a Working-Storage
area, doing the INSPECT in Working-Storage, and then MOVEing back to
the FD logical record. This also led to the Abends.
However, doing a READ INTO Working-Storage, performing the INSPECT, and
then modifying the program to refer to the Working-Storage record
rather than the FD fixed the problem.
A couple of paragraphs from the COBOL Programming Guide gives us some
hints:
"When you specify a READ INTO statement for a format-V file, the record
size read for that file is used in the MOVE statement generated by the
compiler. Consequently, you might not get the result you expect if the
record just read does not correspond to the level-01 record
description. All other rules of the MOVE statement apply. For example,
when you specify a MOVE statement for a format-V record read in by the
READ statement, the size of the record moved corresponds to its
level-01 record description.
"When you specify a READ statement for a format-V file followed by a
MOVE of the level-01 record, the actual record length is not used. The
program will attempt to move the number of bytes described by the
level-01 record description. __If this number exceeds the actual record
length and extends outside the area addressable by the program, results
are unpredictable__ (emphasis added by me)."
Hmmmm... if I understand this last statement correctly, it is stating
that character positions in the FD 01-level logical record that are
beyond the "actual length" most-recently read may reside outside the
area addressable by the program! My educated guess at this point is
that the "offending INSPECT" was trampling on some OS-dedicated area
containing pointers and such things needed by QSAM to keep track of
things.
I think what this speaks to is the risk associated with input
operations upon variable-length without taking proper safeguards with
actual-record length as tracked by the OCCURS DEPENDING ON variable.
And in general, it is hazardous to modify the 01-record in the FD of a
variable-length input file. Probably best not to do it at all. Always
do it in Working-Storage instead. I think I remember learning this once
about twenty-five years ago, and in my haste to find a quick fix,
forgot it since then. :-)
Comments, anyone?
Ken
| |
|
|
| Richard 2006-08-09, 6:55 pm |
|
Kenneth wrote:
> Here's the conclusion: Side-effecting (overwriting) any portion of the
> logical record in the FD (File Descriptor) area for a variable-length
> blocked file is hazardous, leading to unpredictable results such as
> S0C7 and S002 Abends. Only the character positions up to the variable
> length most recently READ should be considered as "belonging" to the
> COBOL program. Characters beyond the length just READ, but still within
> the maximum record length in the FD, belong to the Operating System
> (COBOL internals or the like), should be considered "off limits" and
> should not be modified.
>
> Here's the scenario. IBM Enterprise COBOL 3.2.1.
Is the file OPEN INPUT ?
For a file OPEN OUTPUT then the 01 level under the FD had better
_always_ be available and part of the program because I need to move
bits into every part of that in order to be able to WRITE a record.
For files OPEN I-O I may want to WRITE a completely new record of any
size I like without having to READ one of appropriate size before doing
that.
It would seem that your problem is restricted to one implemention when
file is OPEN INPUT.
| |
| Kenneth 2006-08-09, 6:55 pm |
|
Richard wrote:
>
> Is the file OPEN INPUT ?
Yes, an important detail I omitted.
| |
| Kenneth 2006-08-09, 6:55 pm |
| Agreed. I think now that being explicit about record-length by means of
DEPENDING ON, and then using the length field, is a better practice for
variable-length files than just specifying different length 01's in the
FD without the DEPENDING ON.
Frank Swarbrick wrote:
> Sounds reasonable.
>
> Another possible solution might be to use the DEPENDING ON clause of the FD
> statement, something like...
>
> FILE SECTION.
> FD TRANSACTION-FILE
> RECORD VARYIING FROM 121 TO 8196 CHARACTERS DEPENDING ON MYREC-LEN.
> 01 TRANSACTION-HEADER PIC X(121).
> 01 TRANSACTION-FULL PIC X(8196)
> WORKING-STORAGE SECTION.
> 77 MYREC-LEN PIC 9(4).
> PROCEDURE DIVISION.
> READ TRANSACTION-FILE
> INSPECT TRANSACTION-FULL (1:MYREC-LEN) REPLACING ALL ';' BY ','
>
> I haven't tried it, but I imagine it should work.
>
> Frank
>
> ---
> Frank Swarbrick
> Senior Developer/Analyst - Mainframe Applications
> FirstBank Data Corporation - Lakewood, CO USA
| |
| William M. Klein 2006-08-09, 6:55 pm |
| Ken,
One question I would ask you is whether you were using the
Record Varying in Size from n to m
or the
Record contains n TO m
phrase in your FD.
***
However, you are correct that "playing with" data in an 01-level under an FD
that is BEYOND the size of the last record read in *IS* a *very* bad thing to
do - and you should program around it. (Lots of ways to avoid this - and using
READ INTO is just one of them).
ONE solution that would let you INSPECT in the "logical record area" is the
following:
FD Var-File
record varying ins size from 1 to 8196 depending on WS-Length.
01 Logical-Record.
05 Each-Byte occurs 1 to 8190 times depending on WS-Length Pic X.
....
Working-Storage Section.
01 WS-Length Pic 9(04).
....
Read Var-File
Inspect Logical-Record
REPLACING ALL ';' BY ','
***
You should NEVER ABEND (because of reading outside the current record) if you
use this technique.
--
Bill Klein
wmklein <at> ix.netcom.com
"Kenneth" <klshafer@worldnet.att.net> wrote in message
news:1155136131.073287.170930@b28g2000cwb.googlegroups.com...
> Gentlepeople,
>
> I'll start with my conclusion reached from a recent round of debugging,
> then recite some of the empirical findings supporting it, and finally
> ask for confirmation/response by the group.
>
> Here's the conclusion: Side-effecting (overwriting) any portion of the
> logical record in the FD (File Descriptor) area for a variable-length
> blocked file is hazardous, leading to unpredictable results such as
> S0C7 and S002 Abends. Only the character positions up to the variable
> length most recently READ should be considered as "belonging" to the
> COBOL program. Characters beyond the length just READ, but still within
> the maximum record length in the FD, belong to the Operating System
> (COBOL internals or the like), should be considered "off limits" and
> should not be modified.
>
> Here's the scenario. IBM Enterprise COBOL 3.2.1. FD had two logical
> records defined, as TRANSACTION-HEADER PIC X(121) and TRANSACTION-FULL
> PIC X(8196). There were some "garbage" (semicolon) characters in the
> input file I desired to clean up "on the fly", by performing an INSPECT
> TRANSACTION-FULL REPLACING ALL ';' BY ',' immediately following the
> READ TRANSACTION-FILE. Note that the READ was directly into the FD and
> not a READ INTO. Also note that the "scope" of the INSPECT would have
> been the full length of the 01-level record (8192 characters), and not
> restricted to the actual length of the record just READ. The code did
> not include an OCCURS DEPENDING ON, but the two differing lengths of
> logical records should have caused the compiler to set up the file
> description format as variable record lengths (V), not fixed length
> (F).
>
> The variable length records were typically a few thousand characters
> long, not the full 8192 possible. Program execution showed
> unpredictable results when this INSPECT was inserted into the source
> and compiled. It would abend seemingly unpredictably, but reproducibly
> in the same area of the input file, and a display trace of records read
> showed discrepancies with what an ISPF view of the dataset showed. S0C7
> sometimes occurred due to a record being read "in the middle" instead
> of at the beginning-of-record; more often a QSAM routine would issue an
> S002 Reason Code 4, symptomatic of a Record-Descriptor-Word (RDW)
> corruption problem in the input dataset.
>
> Amazingly :-), just where the program would abend in the input file
> showed a dependency upon the replacement character in the INSPECT,
> according to the replacement character's position in the EBCDIC
> collating sequence! These abends were reproducible from execution to
> execution.
>
> As an experiment, I tried doing a READ INTO into a Working-Storage
> area, doing the INSPECT in Working-Storage, and then MOVEing back to
> the FD logical record. This also led to the Abends.
>
> However, doing a READ INTO Working-Storage, performing the INSPECT, and
> then modifying the program to refer to the Working-Storage record
> rather than the FD fixed the problem.
>
> A couple of paragraphs from the COBOL Programming Guide gives us some
> hints:
>
> "When you specify a READ INTO statement for a format-V file, the record
> size read for that file is used in the MOVE statement generated by the
> compiler. Consequently, you might not get the result you expect if the
> record just read does not correspond to the level-01 record
> description. All other rules of the MOVE statement apply. For example,
> when you specify a MOVE statement for a format-V record read in by the
> READ statement, the size of the record moved corresponds to its
> level-01 record description.
>
> "When you specify a READ statement for a format-V file followed by a
> MOVE of the level-01 record, the actual record length is not used. The
> program will attempt to move the number of bytes described by the
> level-01 record description. __If this number exceeds the actual record
> length and extends outside the area addressable by the program, results
> are unpredictable__ (emphasis added by me)."
>
> Hmmmm... if I understand this last statement correctly, it is stating
> that character positions in the FD 01-level logical record that are
> beyond the "actual length" most-recently read may reside outside the
> area addressable by the program! My educated guess at this point is
> that the "offending INSPECT" was trampling on some OS-dedicated area
> containing pointers and such things needed by QSAM to keep track of
> things.
>
> I think what this speaks to is the risk associated with input
> operations upon variable-length without taking proper safeguards with
> actual-record length as tracked by the OCCURS DEPENDING ON variable.
> And in general, it is hazardous to modify the 01-record in the FD of a
> variable-length input file. Probably best not to do it at all. Always
> do it in Working-Storage instead. I think I remember learning this once
> about twenty-five years ago, and in my haste to find a quick fix,
> forgot it since then. :-)
>
> Comments, anyone?
>
> Ken
>
| |
| Kenneth 2006-08-09, 6:55 pm |
| My comments below...
William M. Klein wrote:
> Ken,
> One question I would ask you is whether you were using the
>
> Record Varying in Size from n to m
> or the
> Record contains n TO m
>
> phrase in your FD.
>
Answer: I was using neither. The FD contained two 01-level records. One
PIC X(121) and the other PIC X(8196).
Here is what the IBM COBOL Programming Guide has to say...
<< Begin Excerpt>>
The compiler determines the recording mode to be V if the largest
level-01 record associated with the file is not greater than the block
size set in the BLOCK CONTAINS clause, and you take one of the
following actions:
1. Use the RECORD IS VARYING clause (format-3 RECORD clause). [stuff
deleted]
2. Use the RECORD CONTAINS integer-1 TO integer-2 clause (format-2
RECORD clause).[stuff deleted]
3. Omit the RECORD clause, but code multiple level-01 records
(associated with the file) that are of different sizes or contain an
OCCURS DEPENDING ON clause. The maximum record length is determined to
be the size of the largest level-01 record description entry associated
with the file.
<<End Excerpt>>
Disclaimer here: I'm only the maintenance programmer :-). I didn't set
up the FD, I inherited the FD, which used Option 3 above (with no
OCCURS DEPENDING ON) as a way of "specifying" variable-length, and was
following the maintenance programmer's creed, "change the minimum
number of lines of code to fix the problem." Until bitten by this bug,
it didn't occur to me to include the VARYING IN SIZE, or RECORD
CONTAINS, or OCCURS DEPENDING ON clause.
So now it seems to me that using two different length 01's in the FD
(with no OCCURS DEPENDING ON) is not as good a practice as OCCURS
DEPENDING ON or Options 1 or 2.
> ***
>
> However, you are correct that "playing with" data in an 01-level under an FD
> that is BEYOND the size of the last record read in *IS* a *very* bad thing to
> do - and you should program around it. (Lots of ways to avoid this - and using
> READ INTO is just one of them).
>
> ONE solution that would let you INSPECT in the "logical record area" is the
> following:
>
> FD Var-File
> record varying ins size from 1 to 8196 depending on WS-Length.
> 01 Logical-Record.
> 05 Each-Byte occurs 1 to 8190 times depending on WS-Length Pic X.
> ...
> Working-Storage Section.
> 01 WS-Length Pic 9(04).
> ...
> Read Var-File
> Inspect Logical-Record
> REPLACING ALL ';' BY ','
>
> ***
>
> You should NEVER ABEND (because of reading outside the current record) if you
> use this technique.
>
Hmmm... I think I see. The DEPENDING ON WS-LENGTH, although at the
05-level, will have the consequence that the INSPECT LOGICAL-RECORD
statement, even though it references an 01-level, will look at only
WS-LENGTH number of characters, and not the full maximum of characters?
Thanks for the tip,
Ken
| |
| Frank Swarbrick 2006-08-09, 6:55 pm |
| Hey! You copied my idea! And I was just about to patent it.
:-)
Actually, yours is slightly different and perhaps better?
Frank
[color=darkred]
Ken,
One question I would ask you is whether you were using the
Record Varying in Size from n to m
or the
Record contains n TO m
phrase in your FD.
***
However, you are correct that "playing with" data in an 01-level under an FD
that is BEYOND the size of the last record read in *IS* a *very* bad thing
to
do - and you should program around it. (Lots of ways to avoid this - and
using
READ INTO is just one of them).
ONE solution that would let you INSPECT in the "logical record area" is the
following:
FD Var-File
record varying ins size from 1 to 8196 depending on WS-Length.
01 Logical-Record.
05 Each-Byte occurs 1 to 8190 times depending on WS-Length Pic X.
....
Working-Storage Section.
01 WS-Length Pic 9(04).
....
Read Var-File
Inspect Logical-Record
REPLACING ALL ';' BY ','
***
You should NEVER ABEND (because of reading outside the current record) if
you
use this technique.
| |
| Richard 2006-08-09, 6:55 pm |
|
Kenneth wrote:
> Richard wrote:
>
> Yes, an important detail I omitted.
Exactly. I would suggest that for that specific implementation for
sequential files OPEN INPUT you should consider the whole FD and record
area within it to be read-only. It is probably just mapping the record
area to the file buffer so you are directly changing OS areas and
falling off them sometimes.
It may be that the file buffer, for entirely different reasons, gets
written back to the disk making your grafiti permanent.
I also suspect that this only applies to sequential files as for an
indexed file it is necessary to change the key before doing a random
read even if the file is OPEN INPUT.
It is unlikely to be of interest to anyone not using that
implementation.
| |
| Clark F Morris 2006-08-09, 6:55 pm |
| On Wed, 9 Aug 2006 15:38:57 -0600, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> wrote:
>Hey! You copied my idea! And I was just about to patent it.
>:-)
>
>Actually, yours is slightly different and perhaps better?
>
>Frank
>
>Ken,
> One question I would ask you is whether you were using the
>
>Record Varying in Size from n to m
> or the
>Record contains n TO m
>
>phrase in your FD.
>
> ***
>
>However, you are correct that "playing with" data in an 01-level under an FD
>
If you want to use READ file-name INTO work-area and are concerned
about efficiency because the implicit instructions are READ followed
by a MOVE that will space fill for anything other than the maximum
length record there is an alternative. Define the FD with a VARYING
IN SIZE DEPENDING ON record-size-field. Do a READ file-name followed
by MOVE maximum-length-record (1 : record-size-field) TO work-record
(1 : record-size-field). This will avoid the space fill.
>that is BEYOND the size of the last record read in *IS* a *very* bad thing
>to
>do - and you should program around it. (Lots of ways to avoid this - and
>using
>READ INTO is just one of them).
>
>ONE solution that would let you INSPECT in the "logical record area" is the
>
>following:
>
>FD Var-File
> record varying ins size from 1 to 8196 depending on WS-Length.
>01 Logical-Record.
> 05 Each-Byte occurs 1 to 8190 times depending on WS-Length Pic X.
>...
>Working-Storage Section.
>01 WS-Length Pic 9(04).
>...
>Read Var-File
>Inspect Logical-Record
> REPLACING ALL ';' BY ','
>
>***
>
>You should NEVER ABEND (because of reading outside the current record) if
>you
>use this technique.
| |
| charles hottel 2006-08-09, 6:55 pm |
|
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1155164790.568919.274370@i3g2000cwc.googlegroups.com...
>
> Kenneth wrote:
>
> Exactly. I would suggest that for that specific implementation for
> sequential files OPEN INPUT you should consider the whole FD and record
> area within it to be read-only. It is probably just mapping the record
> area to the file buffer so you are directly changing OS areas and
> falling off them sometimes.
>
> It may be that the file buffer, for entirely different reasons, gets
> written back to the disk making your grafiti permanent.
<snip>
I think Richard is right about it just mapping the buffer. I believe IBM
COBOL uses locate mode input for VB sequential files, which just returns a
pointer to the record in the buffer. Many, many, many years ago I tried to
increase the length of a variable length record and in so doing I wiped out
the record length of the following record. This is when I learned how to
locate input buffers in a dump. I had to do my record extending in
WORKING-STORAGE.
| |
|
| In article <1155148832.863422.101230@i3g2000cwc.googlegroups.com>,
Kenneth <klshafer@worldnet.att.net> wrote:
>
>docdwarf@panix.com wrote:
>
><http://groups.google.com/group/comp...ee1c188d1805333>
>
>Yes, thank you, Mr. DD, I just now read the thread with interest, and
>received reassurance from it.
Shucks, t'warn't nothin'... brings to mind something about new things
under the sun and all that.
>
>But 'zero-tolerance rule' for 'Thou shalt not touch file buffers; all
>will be done in WORKING-STORAGE via READ INTO and WRITE-FROM' sounds
>so, uh, severe, and harsh.
'Sounding' is a matter of the ear that hears... there are few sounds more
harsh in my own petty life than 'We've got an ABEND in Prod and we're
losing the window'.
>Might I apply an alternative "marketing
>hook" moniker, in an effort to "sell" it to my peers?
You may wrap it in a pretty pink ribbon and send it off to Grandma's with
Little Red Riding Hood, if you so see fit... I was taught it as I related
it.
>Do I have your
>permission to obliquely credit you, perhaps with something along the
>lines of "Doctor's prescription"?
I am neither MD nor PhD nor 'medically' (in the terms of, say, definitions
found in Stedman's) dwarved... so not 'Doctor', please, jes' ol' Doc. I
believe I was taught it by a fellow named Mullen... but my memory is,
admittedly, porous, and he did not claim it as his own but just supported
its validity by saying 'If you don't do it you'll get points off on your
assignments'.
DD
| |
| Arnold Trembley 2006-08-09, 9:55 pm |
|
William M. Klein wrote:
> Ken,
> One question I would ask you is whether you were using the
>
> Record Varying in Size from n to m
> or the
> Record contains n TO m
>
> phrase in your FD.
>
> ***
>
> However, you are correct that "playing with" data in an 01-level under an FD
> that is BEYOND the size of the last record read in *IS* a *very* bad thing to
> do - and you should program around it. (Lots of ways to avoid this - and using
> READ INTO is just one of them).
>
> ONE solution that would let you INSPECT in the "logical record area" is the
> following:
>
> FD Var-File
> record varying ins size from 1 to 8196 depending on WS-Length.
> 01 Logical-Record.
> 05 Each-Byte occurs 1 to 8190 times depending on WS-Length Pic X.
> ...
> Working-Storage Section.
> 01 WS-Length Pic 9(04).
This reminds me of a story told to me by Old Charlie at the shop. It
seems they had a COBOL application with an input file defined very
similarly to your example.
The input file usually had some 40 million records on it, and it took
a while to run. They "Strobed" the program to look for ways to
improve run-time performance and one of the curious things they found
was that the program was spending a large amount of time in a single
MOVE statement, something like this:
READ VAR-FILE.
MOVE LOGICAL-RECORD TO 100-LOGICAL-RECORD-WS.
The problem was that a few records would be quite long, but the
average record length was much closer to 500 bytes. But when they
moved LOGICAL-RECORD to 100-LOGICAL-RECORD-WS, the rules of COBOL
required padding the target record with spaces, which required a call
to a runtime library routine.
They decided that since they already knew the length of the data, that
they would change the code as follows:
READ VAR-FILE.
MOVE LOGICAL-RECORD TO 100-LOGICAL-RECORD-WS (1 : WS-LENGTH)
And the program ran considerably faster, since it no longer required a
call to a library routine for most of the input 40 million records.
I think of it as another side-effect of working with variable length
records in the FD buffers.
With kindest regards,
--
http://arnold.trembley.home.att.net/
| |
| HeyBub 2006-08-10, 6:55 pm |
| Clark F Morris wrote:
>
> If you want to use READ file-name INTO work-area and are concerned
> about efficiency because the implicit instructions are READ followed
> by a MOVE that will space fill for anything other than the maximum
> length record there is an alternative.
The alternative is to NOT be concerned with micro-efficiency. Concern with
efficiency at the micro level is usually of insignificant effect and, at
worst, craps out the whole enchalada. In the case of moving a field and
space-filling, we're talking about nanoseconds per record in extra
processing time. With, say, a million records involved, only an additional
second or two is added to the job.
That's my story and I'm sticking to it.
| |
| Clark F Morris 2006-08-10, 6:55 pm |
| On Thu, 10 Aug 2006 09:40:31 -0500, "HeyBub" <heybubNOSPAM@gmail.com>
wrote:
>Clark F Morris wrote:
>
>The alternative is to NOT be concerned with micro-efficiency. Concern with
>efficiency at the micro level is usually of insignificant effect and, at
>worst, craps out the whole enchalada. In the case of moving a field and
>space-filling, we're talking about nanoseconds per record in extra
>processing time. With, say, a million records involved, only an additional
>second or two is added to the job.
For most batch, you are right. The devil is in the details such as
total number of reads within what time frame. However, even on
today's processors, depending on the implementation, it could be
microseconds rather than nanoseconds. If reasonable coding practices
are followed, optimization that worries about things at this level
should be rarely needed. However it is a good idea to understand when
to do this.
>
>That's my story and I'm sticking to it.
>
>
|
|
|
|
|