Skip to main content

I-O 99 error.

  • March 16, 2023
  • 2 replies
  • 3 views
Al Fedeli

I am getting this error in a program that opens an indexed file in open mode of I/O.  Copies of this program is called by several processes at the same time - meaning the same program runs in parallel with each other.  Each program reads this file and skips any records it should not process.  This happens at a client site, and running this results in a 99 error code intermittently.   I don't see documentation of what a 99 i/O error is - but think it may be record locking.   We do have code that handled this by looking at a return code of a 9D (locked record condition) and when the program got that, it looped back to do the same read that eventually will get it from another process no longer locking it.  We tested this at our shop where program 1 would read the first record in the file and artificially 'pause' while the other 2 thru 12 programs would read that same record and get 9D's.

However, if I know what a 99 I/O was, it would help to discover the issue.  It may not be a record lock issue at all.

Here is info on the environment it's running in :  

{tav62adm}cat /opt/microfocus/VisualCOBOL6.0/VisualCOBOLEclipse/etc/cobopt

-u -C 'INITCALL "libcfun.so" NOSEG RM"ANSI" NOALTER ANS85 AUTOLOCK PERFORM-TYPE"RM" SPZERO TRUNC IBMCOMP CALLFH"FHREDIR" makesyn "COMP-5" == "COMP-4" NOBOUND'

set GCC_LIB=/usr/lib/gcc/i686-redhat-linux/4.8.2

set GCC_SEARCH_PATH=$GCC_LIB:/usr/lib:/lib

set GCC_EXCEP_LIB=gcc_s

    2 replies

    Al Fedeli
    • Al Fedeli
    • Author
    • New Participant
    • March 16, 2023

    I am getting this error in a program that opens an indexed file in open mode of I/O.  Copies of this program is called by several processes at the same time - meaning the same program runs in parallel with each other.  Each program reads this file and skips any records it should not process.  This happens at a client site, and running this results in a 99 error code intermittently.   I don't see documentation of what a 99 i/O error is - but think it may be record locking.   We do have code that handled this by looking at a return code of a 9D (locked record condition) and when the program got that, it looped back to do the same read that eventually will get it from another process no longer locking it.  We tested this at our shop where program 1 would read the first record in the file and artificially 'pause' while the other 2 thru 12 programs would read that same record and get 9D's.

    However, if I know what a 99 I/O was, it would help to discover the issue.  It may not be a record lock issue at all.

    Here is info on the environment it's running in :  

    {tav62adm}cat /opt/microfocus/VisualCOBOL6.0/VisualCOBOLEclipse/etc/cobopt

    -u -C 'INITCALL "libcfun.so" NOSEG RM"ANSI" NOALTER ANS85 AUTOLOCK PERFORM-TYPE"RM" SPZERO TRUNC IBMCOMP CALLFH"FHREDIR" makesyn "COMP-5" == "COMP-4" NOBOUND'

    set GCC_LIB=/usr/lib/gcc/i686-redhat-linux/4.8.2

    set GCC_SEARCH_PATH=$GCC_LIB:/usr/lib:/lib

    set GCC_EXCEP_LIB=gcc_s

    I guess what am trying to ask the group - what is a 99 IO error

    Blair McDonald

    I am getting this error in a program that opens an indexed file in open mode of I/O.  Copies of this program is called by several processes at the same time - meaning the same program runs in parallel with each other.  Each program reads this file and skips any records it should not process.  This happens at a client site, and running this results in a 99 error code intermittently.   I don't see documentation of what a 99 i/O error is - but think it may be record locking.   We do have code that handled this by looking at a return code of a 9D (locked record condition) and when the program got that, it looped back to do the same read that eventually will get it from another process no longer locking it.  We tested this at our shop where program 1 would read the first record in the file and artificially 'pause' while the other 2 thru 12 programs would read that same record and get 9D's.

    However, if I know what a 99 I/O was, it would help to discover the issue.  It may not be a record lock issue at all.

    Here is info on the environment it's running in :  

    {tav62adm}cat /opt/microfocus/VisualCOBOL6.0/VisualCOBOLEclipse/etc/cobopt

    -u -C 'INITCALL "libcfun.so" NOSEG RM"ANSI" NOALTER ANS85 AUTOLOCK PERFORM-TYPE"RM" SPZERO TRUNC IBMCOMP CALLFH"FHREDIR" makesyn "COMP-5" == "COMP-4" NOBOUND'

    set GCC_LIB=/usr/lib/gcc/i686-redhat-linux/4.8.2

    set GCC_SEARCH_PATH=$GCC_LIB:/usr/lib:/lib

    set GCC_EXCEP_LIB=gcc_s

    Hi Al Fedeli,

     

    Here are some things to consider for the problem you described. You mentioned that your COBOL program currently checks for "9D" file status. It sounds like your program might have the File Status field defined as alphanumeric characters, i.e. PIC XX. In Micro Focus COBOL, when a returned File Status contains a 9 in the first byte, this indicates that the second byte will contain an extended File Status code as a binary value. These binary values should correspond to a COBOL Runtime System error; these are documented here.

     

    It is generally possible to interpret second character from its alphanumeric value. The "D" character you mentioned in ASCII is a decimal 68, so the related error in that case is COBOL Runtime System Error 68, documented as COBRT068 Record locked (Recoverable). This matches up with what you've said your program understands for that "9D" File Status.

     

    Next, you've asked about a file status of "99" received at your customer site. This does not seem to indicate a Record Locked error. Assuming that the second "9" character of this status is again an alphameric character, that would be an ASCII Decimal value of 57. However, it does not appear that COBOL Runtime System Error 57 is a defined error. If you confirm that the second 9 is an alphanumeric value, I would recommend opening a Support Case, so that the issue can be investigated further.

     

    If instead the second "9" you've reported is already being interpreted within your program as a binary value, this would correspond directly to a COBOL Runtime System Error 9, which is nominally defined as Directory Not Found. You can see further possible meanings on this page.

     

    https://www.microfocus.com/documentation/visual-cobol/vc60/EclUNIX/HRERRHRERR0B.html

     

    In case it helps, a COBOL program can be coded to interpret the extended files status codes (9/xxx). This page in the docs provides an example of how to define the file status to handle the binary values and interpret them.

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement