|
View previous topic :: View next topic
|
| Author |
Message |
amitava
Warnings : 1
Active User
Joined: 30 Oct 2005
Posts: 186
Location: India
|
|
|
|
Guys, I need some assistance from u all. I had a COBOL program which used the following logic to read the input file -
| Code: |
READ INFILE INTO <Copybook 01 level variable name>
AT END
MOVE 'Y' TO WS-EOF
END-READ
|
Initially the job (having the program in it) ran successfully with the program which read the input-file correctly. But all of a sudden, one day the program when read the input file it replaced some bits at the ending of the copybook variable with junk value. But when we opened the input file with copybook mapping (by some tool - u can say - like FILE-AID), it was showing the correct data in the input file. The copybook format is also correct. But still the program when tried to read the input file, it replaced some bits at the ending with junk values. We did not able to find out the problem. And we did the following changes -
| Code: |
READ INFILE
AT END
MOVE 'Y' TO WS-EOF
END-READ
MOVE IN-REC TO <Copybook 01 level variable name> |
Now the program starts reading with correct data. We did not find out the actual reason for it. However, length of the copybook and obviously, IN-REC was having a length of 300. We don't know the reason. Can you please elaborate on this issue. It sounds something related to mainframe performance issue or something like that. Is it so? I have already posted the problem in IBMMAINFRAME. Refer the link - http://ibmmainframes.com/viewtopic.php?t=26100&highlight=lbc005 |
|
| Back to top |
|
 |
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
After an AT END, the data area should not be used any more.
Either way it may cause you problems sometime.
Care should be taken to avoid referencing the "input" when none was read. The old IBM caution applies - "the results may be unpredictable". The worst way to discover this is after the code runs for some time and the fails - and it is not an abend. Itf the code abends, it must be dealt with8. If the code happens to provide some wrong data, it may not be detected right away and may corrupt the database or other external files and/or reports. |
|
| Back to top |
|
|
amitava
Warnings : 1
Active User
Joined: 30 Oct 2005
Posts: 186
Location: India
|
|
|
|
| Dick, thanks for ur reply! But can u please elaborate it little more. I am not getting u totally. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
When the AT END is raised, no data was returned from the access method to the program. If no data was "read", whatever happens to be in the data area shold not be used - the content is unpredictable. |
|
| Back to top |
|
|
amitava
Warnings : 1
Active User
Joined: 30 Oct 2005
Posts: 186
Location: India
|
|
|
|
Dick,
I am not getting the junk values AT END condition! I am getting it after - say - 11658 reads while the input file is having nearly 25000 records. So at that time of reading 11658 record, AT END condition is not raised. Right? Even we shortened the input file records to - say - 20000 records. Then also it is coming at 11658th record but when we shortened the records of the input file to 10000, those junk read was not coming at all.
But when we used -
| Code: |
READ INFILE
AT END
MOVE 'Y' TO WS-EOF
END-READ
MOVE IN-REC TO <Copybook 01 level variable name> |
the problem was totally removed. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| So at that time of reading 11658 record, AT END condition is not raised. Right? |
Yes, that is correct. When the code snippets were posted, they had to do with AT END, so that is where i focused.
Please post the FD for this file.
If you browse the input file, what do the records near 11658 look like?
I suspect that there is something else in the code that has not been posted. The code that does not produce "junk" data will possibly have problems when AT END is raised. It will move data that was not read . . . |
|
| Back to top |
|
|
socker_dad
Active User
Joined: 05 Dec 2006
Posts: 177
Location: Seattle, WA
|
|
|
|
I agree with Dick - the problem sounds more data-related than program.
Are you always processing the same data, or does the input file periodically change?
Grab a copy of the input file and take it through the code in debug. Time-consuming? Yes. Tedious? Oh, heck yes. Find the problem? You betcha. |
|
| Back to top |
|
|
nagajyothi
New User
Joined: 01 Jun 2007
Posts: 3
Location: UK
|
|
|
|
Hi,
I agree totally agree with socker, There may be lot of other possibility of getting junk values in inout file, but this might be one of cause that there is possibality that input file may contain the header and trailor records, for 11658th record may be header o trailor record, so in your code, you can insert small condition code to check header, detail and trailor record and mention that if record is header or trailor then ignire the record else if its detail record, then read the record.
But before that you need to make sure that the input file contains header and trailors or not. |
|
| Back to top |
|
|
amitava
Warnings : 1
Active User
Joined: 30 Oct 2005
Posts: 186
Location: India
|
|
|
|
Ohhhh! No guys. The input file is not having some special records or any junk data at all. However for your clarity, I am attaching the input file format -
| Code: |
0136329179016 MC018D 15 # 000000000000002040907 MASSER BARB8018910001I206050120710012070908143300 Q00 Q000000000000000123200548
0420401936026 MC021D 15 # 000000000000002060401 RAWSON ALIC7416334001I206050120704012061227174800 Q00 Q207030700000000000000548
0825402415001 MC021D 15 # 000000000000002061103 ONEILL STEP7252055002I206050120701012061106100512 Q20 Q000000000000000028800548
0939114761002 MC016D 12 # 000000000000002071105 YARME HOWA8177696001I206050120801012071105046680 Q00 Q000000000000000000000574 MC017D 1
0720541930000 MC018D 15 # 000000000000002070225 POULOS ELIZ7494118002I207020120704012070225023423 Q00 Q000000000000000000000578
0216018781014 MC021D 15 # 000000000000002061007 MARCHETTI DOME7188387002I206040120701012061021113076 Q00 Q207030700000000073590609
0224547951005 MC018D 15 # 000000000000002060325 YOUDE OLGA7565580004I206030120707012061209095820 Q20 Q207030700000000073590609
0425274179030 MC018D 15 # 000000000000002060325 YOUDE HERB7565579004I206030120707012061209095820 Q20 Q000000000000000073590609
1119311990011 MC018D 15 # 000000000000002070319 DORGAN ANN 7566990003I206030120707012070319095820 Q00 Q207090600000000118050609
1123434417003 MC018D 15 # 000000000000002070909 MILLS THER8024937004I206030120801012070911140280 Q20 Q000000000000000056325636
1220548171108 MC018D 15 # 000000000000002060129 RODERICK MARY7416561002I206020220704012061227078555 Q00 Q000000000000000000000637
1038048196000 MC021D 15 # 000000000000002070919 DERDERIAN MALC8027474001I206020120710012070921324200 Q00 Q000000000000000179154657
0134059167007 MC021D 15 # 206010120601122060131 SEAVOR LAWR7416936001I206011220704012061227230754 Q00 Q000000000000000000000668
0137121947000 MC015D 16 # 000000000000002061102 DEUS ANTO8115384001I206010120701012071025043200 Q00 Q000000000000000000000668
0233207587011 MC021D 15 # 000000000000002060616 BETTEZ RUDO7404808001I206010120602012070107015400 Q00 Q000000000000000000000668
0340321990028 MC018D 15 # 207100120801012071001 TETRAULT ANN 8178574004I206010120801012071110150552 Q00 Q207030720706080106092668
|
Dick, for debugging purpose, I put some display just after READ statement. With the initial code, it shows that at the particular record - say 15222 - it is showing some junk value near about from 200th position of the copybook 01 level group variable. After that, it came to my mind that may be this is an issue with mainframe capacity/ performance. I need you peoples' opinion about this. However Dick, I am attaching the FD section of the input file also-
BUT NOTE IT : IN THE PROCEDURE DIVISION, after doing initialization (not even the input copybook variables) WE ARE READING THE INPUT FILE AND AFTER EACH READ, I WAS DISPLAYING THE INPUT COPYBOOK'S 01 LEVEL GROUP VARIABLE. AND HERE I AM GETTING THE JUNK VALUE AFTER CERTAIN RECORDS READ - say 15222 AFTER A SPECIFIED POSITION OF THE INPUT COPYBOOK'S 01 LEVEL VARIABLE - say 200th position onwards.
BUT IF I CHANGED THE READ INTO THE LAST FORMAT MENTIONED ABOVE, THIS JUNK READ IS REMOVED. WHAT'S THE BASIC DIFFERENCE BETWEEN THE TWO READS? FOR MORE CLARITY, REFER THE BELOW CODES -
Modified Code : Running fine now after fix -
| Code: |
050-READ-INPUT-FILE.
INITIALIZE INPUT-REC
LBC005-SUB-BILL-IO-AREA
READ INPUT-FILE
AT END
GO TO 650-SUMMARY-RPT.
DISPLAY INPUT-REC
DISPLAY LBC005-SUB-BILL-IO-AREA
ADD 1 TO WS-INPUT-READ.
MOVE INPUT-REC TO LBC005-SUB-BILL-IO-AREA
|
Erroneous read - Initially went fine for some time (14-15 days run)
| Code: |
READ LBC005-SUB-BILL-IO-AREA
AT END
GO TO 650-SUMMARY-RPT.
ADD 1 TO WS-INPUT-READ.
DISPLAY LBC005-SUB-BILL-IO-AREA
|
FD Section -
FILE SECTION.
| Code: |
FD INPUT-FILE
RECORDING MODE IS F
RECORD CONTAINS 300 CHARACTERS
DATA RECORD IS INPUT-REC.
01 INPUT-REC.
02 FILLER PIC X(300).
EJECT
|
[/code] |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
The way you have attached the data, any "bad" values will probably not be shown. An important thing to learn was what was the hex values of the "bad" data that was discovered by the program. A good way (IMHO) to see the record content is to view the data outside of your code - maybe by using tso/ispf and using HEX ON. If the code will show the "bad" values, great, but if it won't, an external view of the data is a good idea.
| Quote: |
| After that, it came to my mind that may be this is an issue with mainframe capacity/ performance |
No, this will not be an issue. . . It will certainly not cause good records to be read incorrectly. FWIW several of my regular processes process several hundred million records with nothing like this ever happening. Even if there was some kind of "flaky mainframe" thing happening, it would most likely not happen on the same record every time.
| Quote: |
| WHAT'S THE BASIC DIFFERENCE BETWEEN THE TWO READS? |
The difference is that in one case the READ accomplishes the move and in the other it is an explicit MOVE. The explicit will pad the receiving field with spaces if the sending data is shorter than the receiving data.
If the 2 produce different results, you need to determine excactly why because otherwise, you may have an abend or data corruption in some later run (when this situation is long forgotten). 100% of what happens in code is explainable and understandable - it may take some work, but there is no mystery. If you have code that is not understood or cannot be explained, you have reason to be concerned.
Why is there an INITIALIZE of the input area? This is not good. . . |
|
| Back to top |
|
|
amitava
Warnings : 1
Active User
Joined: 30 Oct 2005
Posts: 186
Location: India
|
|
|
|
Dick,
| Quote: |
| The way you have attached the data, any "bad" values will probably not be shown. An important thing to learn was what was the hex values of the "bad" data that was discovered by the program. A good way (IMHO) to see the record content is to view the data outside of your code - maybe by using tso/ispf and using HEX ON. If the code will show the "bad" values, great, but if it won't, an external view of the data is a good idea. |
I have also checked with putting the command HEX ON. It is coming fine with out any junk value. Still I really don't know the reason of such behavior. Again
| Quote: |
| hy is there an INITIALIZE of the input area? This is not good. . . |
I know this is a bad coding style but I was such skeptical that I did not want to take any risk. The thing is - I think so - we are still unable to find out the actual reason of the problem.
You know one thing that yesterday I tried to redo the logic from
| Code: |
INITIALIZE INPUT-REC
LBC005-SUB-BILL-IO-AREA
READ INPUT-FILE
AT END
GO TO 650-SUMMARY-RPT.
DISPLAY INPUT-REC
DISPLAY LBC005-SUB-BILL-IO-AREA
ADD 1 TO WS-INPUT-READ.
MOVE INPUT-REC TO LBC005-SUB-BILL-IO-AREA |
to
| Code: |
READ LBC005-SUB-BILL-IO-AREA
AT END
GO TO 650-SUMMARY-RPT.
ADD 1 TO WS-INPUT-READ.
DISPLAY LBC005-SUB-BILL-IO-AREA |
And it was coming fine now. Ohhh! I think I misled u all people by saying that my earlier (when I posted this problem in this forum) job was getting an abend. Yop! It was getting an abend - its S0C7 and that too for the incorrect read. Guys again this problem does not have any explanation at all - I think so! Any more focus ... |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| Guys again this problem does not have any explanation at all |
100% of this type of problem has an explanation - some are just tougher to explain. From what you have posted, it is nearly certain that the problem is in the code (rather than the data).
Is there any looping/indexing/subscripting in the program? Has this program ever worked (or is it a new program)? If this program was recently modified, what was changed?
Also, from what has been posted, i'd suggest that the program is not working correctly even when it does not abend. I'd even suggest that the problem is because some i/o area or working-storage area is "being walked on".
Something you might want to do is clone the program and discard all of the processing logic. Keep only the FD, the open, and the read (don't do a READ INTO or a MOVE TO ws - just read te records. Run this clone and see if the program goes to successful eoj after reading the entire file. You might include a record count and display the count at eoj. This should take 10 or 15 minutes to create and however long it takes to read the file to test. |
|
| Back to top |
|
|
amitava
Warnings : 1
Active User
Joined: 30 Oct 2005
Posts: 186
Location: India
|
|
|
|
| Thanks dick! I will do what u have advised and I will let u know about the result. |
|
| Back to top |
|
|
|
|
