Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

COBOL: incorrect read ...

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
amitava
Warnings : 1

Active User


Joined: 30 Oct 2005
Posts: 186
Location: India

PostPosted: Wed Dec 05, 2007 2:33 pm    Post subject: COBOL: incorrect read ...
Reply with quote

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
View user's profile Send private message

dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Wed Dec 05, 2007 8:55 pm    Post subject:
Reply with quote

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
View user's profile Send private message
amitava
Warnings : 1

Active User


Joined: 30 Oct 2005
Posts: 186
Location: India

PostPosted: Wed Dec 05, 2007 9:21 pm    Post subject:
Reply with quote

Dick, thanks for ur reply! But can u please elaborate it little more. I am not getting u totally.
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Wed Dec 05, 2007 10:51 pm    Post subject:
Reply with quote

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
View user's profile Send private message
amitava
Warnings : 1

Active User


Joined: 30 Oct 2005
Posts: 186
Location: India

PostPosted: Thu Dec 06, 2007 9:40 am    Post subject:
Reply with quote

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
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Thu Dec 06, 2007 8:51 pm    Post subject:
Reply with quote

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
View user's profile Send private message
socker_dad

Active User


Joined: 05 Dec 2006
Posts: 147
Location: Columbia, MO

PostPosted: Fri Dec 07, 2007 2:51 am    Post subject: Reply to: COBOL: incorrect read ...
Reply with quote

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
View user's profile Send private message
nagajyothi

New User


Joined: 01 Jun 2007
Posts: 3
Location: UK

PostPosted: Fri Dec 07, 2007 9:51 am    Post subject:
Reply with quote

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
View user's profile Send private message
amitava
Warnings : 1

Active User


Joined: 30 Oct 2005
Posts: 186
Location: India

PostPosted: Fri Dec 07, 2007 10:35 am    Post subject:
Reply with quote

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
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Fri Dec 07, 2007 8:26 pm    Post subject:
Reply with quote

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
View user's profile Send private message
amitava
Warnings : 1

Active User


Joined: 30 Oct 2005
Posts: 186
Location: India

PostPosted: Sat Dec 08, 2007 2:15 pm    Post subject:
Reply with quote

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
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Sun Dec 09, 2007 2:38 am    Post subject:
Reply with quote

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
View user's profile Send private message
amitava
Warnings : 1

Active User


Joined: 30 Oct 2005
Posts: 186
Location: India

PostPosted: Mon Dec 10, 2007 9:46 am    Post subject:
Reply with quote

Thanks dick! I will do what u have advised and I will let u know about the result.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts XML Parse for COBOL 5.2 Bhanu Praveen COBOL Programming 1 Sat Jul 08, 2017 8:58 pm
No new posts Dynamic output file creation in cobol... smileheal COBOL Programming 7 Thu Jun 15, 2017 10:53 pm
No new posts Search utility(3.14) using JCl and Cobol RKS3 COBOL Programming 12 Sat Jun 10, 2017 10:24 pm
No new posts COBOL DB2 program - zIIP eligible vasanthz COBOL Programming 7 Wed May 31, 2017 5:12 am
This topic is locked: you cannot edit posts or make replies. Cobol GUI (like Editor) Kala Mainframe COBOL Programming 14 Wed May 10, 2017 12:30 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us