|
View previous topic :: View next topic
|
| Author |
Message |
socker_dad
Active User
Joined: 05 Dec 2006
Posts: 177
Location: Seattle, WA
|
|
|
|
I am retrofitting an old program that hasn't been touched since Y2K and had something very interesting happened that may benefit someone else.
This old program had the output record defined in the FD area - like most old programs. The record contains two parts: a "header" section and a "trailer" section (for lack of a better description - note that this is NOT true header and trailer records; just part of a single record).
The "header" is repeated for as many qualfiying "trailer" records with the only differences in the records being the trailing information. So the program builds the header information one time, then loops through a section to build the trailer section, writing a record for each occurance.
When testing, I found that the header section was only appearing on the first record of the series - not the subsequent records that should have shared the data. Now this is great on a report, but not in a data file.
What was happening?  It's really freaky to step through your code in Expeditor and watch your data disappear after the WRITE is executed! I have never heard of a "destructive" Write in COBOL!
I was told by senior personnel that Z/OS allocates FD storage areas dynamically, so where the FD storage area is on one pass may not be where it is on the second; although Working Storage remains static.
The solution was to build the record in Working Storage and then write the output record fom that area. Bingo - works great and all the data shows up.
Every day is a new adventure.....  |
|
| Back to top |
|
 |
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
Oh my...You never expect the prior record's data to be in the 01 level of an FD, unless you are writing unblockes and single buffer......
The 01 is mearly a dsect view into the I/O buffer, is changes location for each record in the block...That's why sometimes the "apply write only" is nice for large differing variable length output....
Gee, Socker Dad, you must be a "young'n".... |
|
| Back to top |
|
|
socker_dad
Active User
Joined: 05 Dec 2006
Posts: 177
Location: Seattle, WA
|
|
|
|
Thanks for the age complement!
No - I have been programming for about 20 years - I've just never seen a program try to reuse FD storage before. Oh, what a sheltered life I've led!
See - I am a GOOD programmer - I ALWAYS use working storage! |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| socker_dad wrote: |
| I am a GOOD programmer - I ALWAYS use working storage! |
Things change, but when I learned, using the buffer was just fine, as long as you did not "expect" things to still be there....
working storage or the 01 of the FD, it all depended on what you needed and wanted....  |
|
| Back to top |
|
|
TG Murphy
Active User
Joined: 23 Mar 2007
Posts: 148
Location: Ottawa Canada
|
|
|
|
| With the FD buffer you must take care not to reference the buffer after the file has been closed. I can still remember my COBOL teacher warning us about this 25 years ago. I did debug somebody's problem that was caused by exactly this problem. They referenced the buffer but the buffer was no longer there. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
I've not "tried" this recently
| Quote: |
| With the FD buffer you must take care not to reference the buffer after the file has been closed. |
but once upon a time, referencing the buffer after the close, could cause an abend - the memory had been released and the address became invalid.
Referencing the buffer after a write, got whatever was in that part of the buffer - each write re-positions the displacement into the buffer for the "next" write. You might get pure junk and abend (if you were lucky) or you might get whatever data was already there from a previous write - sometimes very tough to recognize/resolve. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| the original program probably ran in the days of bufno=1 was the default. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
| Quote: |
| the original program probably ran in the days of bufno=1 was the default. |
And lrecl = blksize. . . . |
|
| Back to top |
|
|
socker_dad
Active User
Joined: 05 Dec 2006
Posts: 177
Location: Seattle, WA
|
|
|
|
| Gosh - I think it's time to invest in a retirement home.....ya'll are making me feel real old now!!! |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hmmm. . . Thought that would make you feel younger, not older. . . .
d |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| socker_dad wrote: |
| Gosh - I think it's time to invest in a retirement home.....ya'll are making me feel real old now!!! |
Sorry, you're are paying my SS benefits...grin...
In the "Old'n days", a lot of print outputs were unblocked and (dang I can't think of it) single buffered to allow the existing data in the last write to exist to the next write... |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Once upon a time (nah, this won't be a fairy tale) printers and "punches" were called "unit record" devices - no blocking possible.
This was after canned beer, but way before aluminum, easy-open cans |
|
| Back to top |
|
|
|
|
