rtsora32 error codes
in [Cobol]
|
Prev: compiling ProCOBOL
Next: .NET. Is it the Holy Grail?
From: Derek Schrock on 16 Apr 2010 08:24 On Apr 15, 4:58 pm, Richard <rip...(a)Azonic.co.nz> wrote: > On Apr 16, 7:23 am, Derek Schrock <derekschr...(a)gmail.com> wrote: > > > > > On Apr 15, 2:32 pm, Richard <rip...(a)Azonic.co.nz> wrote: > > > > On Apr 16, 2:29 am, Derek Schrock <derekschr...(a)gmail.com> wrote: > > > > > Can I assume error codes returned by rtsora32 should be the same as > > > > what comes out of cobrun? > > > > >http://supportline.microfocus.com/Documentation/books/sx40sp2/rhrerr0... > > > > is my reference. > > > > > I'm trying to understand the 102 error code. > > > > "Sequential file with non-integral number of records" > > > > The file size is not a multiple of the record size. Reading the last > > > record in the file gave only part record. > > > > > This is the return code of an rtsora32 command after the the programs > > > > run in-full. > > > That's what I was thinking but wouldn't it kill the program since it's > > a fatal error? > > Where would the 102 code be? The file status storage? If it's at the > > end of the file when it files the incomplete record the status would > > be 102 then 10 at the "same time?" > > If you have a file status for the file you will get a 9/102 status > value. ie first byte 9 second byte x"66" (decimal 102). This is > because it is a failure to reach a proper end of file. > > If you had not specified the file status clause for the file then to > 102 error would kill the program because it is fatal. > > It may be that you have specified an incorrect record size or that the > file has become corrupted. Also, after removing all file status vars the program still does not stop. It ends with the ending "STOP RUN." statement.
From: Derek Schrock on 16 Apr 2010 11:48 On Apr 15, 4:58 pm, Richard <rip...(a)Azonic.co.nz> wrote: > On Apr 16, 7:23 am, Derek Schrock <derekschr...(a)gmail.com> wrote: > > > > > On Apr 15, 2:32 pm, Richard <rip...(a)Azonic.co.nz> wrote: > > > > On Apr 16, 2:29 am, Derek Schrock <derekschr...(a)gmail.com> wrote: > > > > > Can I assume error codes returned by rtsora32 should be the same as > > > > what comes out of cobrun? > > > > >http://supportline.microfocus.com/Documentation/books/sx40sp2/rhrerr0... > > > > is my reference. > > > > > I'm trying to understand the 102 error code. > > > > "Sequential file with non-integral number of records" > > > > The file size is not a multiple of the record size. Reading the last > > > record in the file gave only part record. > > > > > This is the return code of an rtsora32 command after the the programs > > > > run in-full. > > > That's what I was thinking but wouldn't it kill the program since it's > > a fatal error? > > Where would the 102 code be? The file status storage? If it's at the > > end of the file when it files the incomplete record the status would > > be 102 then 10 at the "same time?" > > If you have a file status for the file you will get a 9/102 status > value. ie first byte 9 second byte x"66" (decimal 102). This is > because it is a failure to reach a proper end of file. > > If you had not specified the file status clause for the file then to > 102 error would kill the program because it is fatal. > > It may be that you have specified an incorrect record size or that the > file has become corrupted. Turns out it's an Oracle issue... SQLBEX is setting RETURN-CODE to 102 early is the program's life. Assuming error codes don't change that much.. (duck) http://download-uk.oracle.com/docs/cd/A87862_01/NT817CLI/server.817/a76999/pcbeus.htm PCB-00102 Input file name length exceeds the maximum length Cause: The file name length specified exceeded the maximum length. Some operating systems have a maximum file name length. Action: Use a file name of length less than or equal to the maximum platform specific file name length. This is preprocessed code too... ..... 1004 CALL "SQLBEX" USING 1005 SQLCTX 1006 SQLEXD 1007 SQLFPN ..... SQLFPN = ^^BN0711P.pco Interesting...
From: Anonymous on 16 Apr 2010 11:54 In article <be2da34b-eac8-4793-aa03-55072bf4159b(a)30g2000yqi.googlegroups.com>, Derek Schrock <derekschrock(a)gmail.com> wrote: >On Apr 15, 4:58?pm, Richard <rip...(a)Azonic.co.nz> wrote: >> On Apr 16, 7:23?am, Derek Schrock <derekschr...(a)gmail.com> wrote: [snip] >Turns out it's an Oracle issue... SQLBEX is setting RETURN-CODE to 102 >early is the program's life. .... and this may be seen as a reason for some folks saying 'Debugging code is like peeling an onion... a layer at a time, and sometimes you cry.' DD
From: James J. Gavan on 16 Apr 2010 16:24 Derek Schrock wrote: > Turns out it's an Oracle issue... SQLBEX is setting RETURN-CODE to 102 > early is the program's life. > > Assuming error codes don't change that much.. (duck) > > http://download-uk.oracle.com/docs/cd/A87862_01/NT817CLI/server.817/a76999/pcbeus.htm > > PCB-00102 Input file name length exceeds the maximum length > > Cause: The file name length specified exceeded the maximum length. > Some operating systems have a maximum file name length. > > Action: Use a file name of length less than or equal to the > maximum platform specific file name length. > > This is preprocessed code too... > > .... > 1004 CALL "SQLBEX" USING > 1005 SQLCTX > 1006 SQLEXD > 1007 SQLFPN > .... > > SQLFPN = ^^BN0711P.pco > > Interesting... > Nice when you find out what the REAL problem is :-) Might try a bit of XP(e(X)treme (P)rogramming) on this one as you have hit the particular error. Within ORACLE :- IF length of input-Filename > Max-Platform-Length we have a problem generate an error-message The other thing is you were misled by the Error 102 - there is no way that M/F File handling would have generated a three-digit file-status code which is a pic x(02). If file-status-1 = "9" then you have to do a convert on file-status-2 to get the numeric value. Somewhere in your manuals you will find an M/F example to convert status-codes starting with "9" into a three-digit code. Here's a current reference to their file-status codes :- http://kb.microfocus.com/display/1n/index.aspx?c=12&cpc=BTakh05i2p2gM801Slr08SHyX275E544jc&cid=2&cat=&catURL=&r=0.519614815711975 *> REPEAT : *> http://kb.microfocus.com/display/1n/index.aspx? *>c=12&cpc=BTakh05i2p2gM801Slr08SHyX275E544jc&cid=2&cat=&catURL *>=&r=0.519614815711975 Jimmy, Calgary AB
From: Derek Schrock on 19 Apr 2010 09:00
On Apr 16, 11:48 am, Derek Schrock <derekschr...(a)gmail.com> wrote: > On Apr 15, 4:58 pm, Richard <rip...(a)Azonic.co.nz> wrote: > > > > > On Apr 16, 7:23 am, Derek Schrock <derekschr...(a)gmail.com> wrote: > > > > On Apr 15, 2:32 pm, Richard <rip...(a)Azonic.co.nz> wrote: > > > > > On Apr 16, 2:29 am, Derek Schrock <derekschr...(a)gmail.com> wrote: > > > > > > Can I assume error codes returned by rtsora32 should be the same as > > > > > what comes out of cobrun? > > > > > >http://supportline.microfocus.com/Documentation/books/sx40sp2/rhrerr0... > > > > > is my reference. > > > > > > I'm trying to understand the 102 error code. > > > > > "Sequential file with non-integral number of records" > > > > > The file size is not a multiple of the record size. Reading the last > > > > record in the file gave only part record. > > > > > > This is the return code of an rtsora32 command after the the programs > > > > > run in-full. > > > > That's what I was thinking but wouldn't it kill the program since it's > > > a fatal error? > > > Where would the 102 code be? The file status storage? If it's at the > > > end of the file when it files the incomplete record the status would > > > be 102 then 10 at the "same time?" > > > If you have a file status for the file you will get a 9/102 status > > value. ie first byte 9 second byte x"66" (decimal 102). This is > > because it is a failure to reach a proper end of file. > > > If you had not specified the file status clause for the file then to > > 102 error would kill the program because it is fatal. > > > It may be that you have specified an incorrect record size or that the > > file has become corrupted. > > Turns out it's an Oracle issue... SQLBEX is setting RETURN-CODE to 102 > early is the program's life. > > Assuming error codes don't change that much.. (duck) > > http://download-uk.oracle.com/docs/cd/A87862_01/NT817CLI/server.817/a... > > PCB-00102 Input file name length exceeds the maximum length > > Cause: The file name length specified exceeded the maximum length.. > Some operating systems have a maximum file name length. > > Action: Use a file name of length less than or equal to the > maximum platform specific file name length. > > This is preprocessed code too... > > .... > 1004 CALL "SQLBEX" USING > 1005 SQLCTX > 1006 SQLEXD > 1007 SQLFPN > .... > > SQLFPN = ^^BN0711P.pco > > Interesting... So it turns out the above error isn't the correct message... and the funny thing is.. there isn't a message: http://www.stanford.edu/dept/itss/docs/oracle/10g/appdev.101/a96109/pcoabops.htm B.1.6 RETURN-CODE Special Register May Be Unpredictable. The contents of the RETURN-CODE special register (for those systems that support it) are unpredictable after any SQL statement or SQLLIB function. During the closing part of the cobol program adding a EXEC SQL COMMIT EXEC fixed the problem. The odd thing is that we're not using cursors or updates, just standard selects. So why the need for a commit statement? I could have just as easily ran a CALL cobol statement to set RETURN-CODE to 0. I don't see any where in Oracle's docs that require ending all Pro*COBOL programs with a commit... interesting to say the least. |