What does Cobol file status 9Â mean? - cobol

My issue is when I try to open on input a huge file (6GB) ,
there's a message that says:
cobol file status code 9Â
I compiled the program and it has no errors, but when I try to run it,
I use a small one (3 GB for example) my program work correctly.
Any ideas ?
Variable declaration:
SELECT
MYFILE ASSIGN MYFILE
ACCESS SEQUENTIAL
STATUS IS XZ-STATUS6.
===
OPEN INPUT MYFILE
===
READ MYFILE NEXT AT END MOVE 1 TO ZFIN-F3

You may want to have a look at this link, which includes some info which may apply in your case. Some of the info included there:
About File Status
If you have a file status data-item defined for a file, then after every input/output operation on the file (OPEN, CLOSE, READ, WRITE, REWRITE, START and DELETE) the run-time system updates it to indicate how the operation completed.
Defining a file status data-item is optional. If a file status data-item is not declared and a serious file error occurs, the COBOL run-time system displays an error message and aborts your program.
You should check the file status data-item after each input/output operation, to see if the operation completed successfully.
About a file status data-item
File status is a two-byte code. If the first byte of the file status data-item contains value 9, it indicates a COBOL run-time system error. In that case, the second byte is a binary field containing an error code.
Example code (ws-file-status corresponds to your XZ-STATUS6)
...
working-storage section.
01 ws-file-status.
05 status-key-1 pic x.
05 status-key-2 pic x.
05 binary-status redefines status-key-2 pic 99 comp-x.
...
...
procedure division.
...
perform check-status.
...
check-status.
evaluate status-key-1
when "0" next sentence
when "1" display "end of file reached"
...
when "9" display "run-time-system error"
perform check-mf-error-message
end-evaluate.
...
check-mf-error-message.
evaluate binary-status
when 002 display "file not open"
when 007 display "disk space exhausted"
when 013 display "file not found"
when 024 display "disk error "
when 065 display "file locked "
when 068 display "record locked "
when 039 display "record inconsistent"
when 146 display "no current record "
when 180 display "file malformed "
when 208 display "network error "
when 213 display "too many locks "
when other display "not error status "
display binary-status
end-evaluate.
Note sure if your (bizarre) value  will correspond with any of the listed values for binary-status (within check-mf-error-message), but at least it should help find out how to correctly display your actual file status code.

thanks all for your valuable feedbacks, the problem was in the size of an array that I use to calculate some large numbers, I have set my array to the max and it's worked fine now

Related

"RECORDING" WAS INVALID. A "RECORDING MODE" OF "V" WAS ASSUMED FOR FILE

Hi I have written a COBOL program where I am using a file, but while defining file definition it is giving me error, please tell me what to do.
FILE-CONTROL.
SELECT CONTROL0-FILE
ASSIGN TO CONTR.
SELECT APCO-FILE
ASSIGN TO APCOOUT.
FD APCO-FILE.
I A "RECORDING MODE" OF "V" WAS ASSUMED FOR FILE "APCO-FILE". //ERR MSG
RECORDING MODE IS V
S "RECORDING" WAS INVALID. SCANNING WAS RESUMED AT THE NEXT AREA "A" //ERR MSG
ITEM, LEVEL-NUMBER, OR THE START OF THE //ERR MSG
RECORD CONTAINS 30 TO 300
BLOCK CONTAINS 6152 CHARACTERS
LABEL RECORDS STANDARD.
01 APCOIN-REC-1 PIC X(30).
01 APCOIN-REC PIC X(300).
The problem is the . after APCO-FILE, it ends the file definition
FD APCO-FILE.
RECORDING MODE IS V
RECORD CONTAINS 30 TO 300
BLOCK CONTAINS 6152 CHARACTERS
LABEL RECORDS STANDARD.
Change to
FD APCO-FILE
RECORDING MODE IS V
RECORD CONTAINS 30 TO 300
BLOCK CONTAINS 6152 CHARACTERS
LABEL RECORDS STANDARD.
I think you've been given the solution. I would like to ad some comment which may help you find errors yourself in the future.
The compiler reads what it thinks is a statement, and then verifies syntax, and if an error is found, writes error message(s). It then goes on with the next statment.
So firstly, the fact that there is an error message after FD APCO-FILE. indicates that the compiler considers the statement to be complete right at this point. Secondly, the fact that there is another error message after RECORDING MODE IS V tells you that the compiler thinks this is another statement, and it doesn't understand it, hence "RECORDING" was invalid ...
So the compiler thinks the part starting with RECORDING is a new statement, while you meant it to be a continuation of the FD statement. Think about what would cause the compiler and you to disagree, and you might soon see the "." after APCO-FILE which should not be there.

COBOL: How to differentiate between end of file and junk value when both have return code 10?

I am working on Fujitsu COBOL and there is a situation where I have to read the file and if there is a junk value then I want to abend the job.
When there is a junk value the return code is 10 but the catch is that when there is EOF (end of file) even then the return code is 10.
Please help me out on how can I differentiate between these two events based on the return code?
On very early PCs (MS-DOS 1.0), a Ctrl+Z (X"1A") was used as end-of-file for text files. Your compiler is likely detecting that character and treating it as end-if-file instead of allowing the remainder of the file to be processed.
In the OEM/DOS character set, X"1A" appears as a right-pointing arrow. (You mentioned an arrow in a comment.) I created a short file with four records for testing.
The original file:
Record1
Record2
Record3
Record4
I replaced the "3" with X"1A". In a hex editor, it appears as,
Notice that the x"1A" character appears as a right-pointing arrow.
A wrote a program (not shown) to read the file displaying the output of the modified file.
Record1
Record2
Record
0003 lines read
End of file occurred at the X"1A".
The following program may be used to check for X"1A" and "identify the corrupt record occurrence ... so that [you] can correct the file".
program-id. ctrl-z.
environment division.
input-output section.
file-control.
select in-file assign "ctrl-z.txt"
organization sequential
.
data division.
file section.
fd in-file.
1 in-char pic x.
working-storage section.
1 line-count binary pic 9(4) value 0.
1 msg-txt pic x(25) value "lines read".
88 error-msg value "lines read before cntrl-z".
1 eof-in-file-flag pic 9 value 0.
88 eof-in-file value 1.
procedure division.
begin.
open input in-file
read in-file
at end set eof-in-file to true
end-read
perform until eof-in-file
evaluate in-char
when x"0A"
add 1 to line-count
when x"1A"
set error-msg to true
set eof-in-file to true
exit perform
when other
continue
end-evaluate
read in-file
at end set eof-in-file to true
end-read
end-perform
close in-file
display line-count space msg-txt
stop run
.
end program ctrl-z.
The result was:
0002 lines read before cntrl-z
In the following code, I've just shown a method of differentiating end of file and junk value when both have File Status code of 10.
In the program, a file is being read. FILE STATUS for the input file being read is WS-ST. Record layout is just 1 field named as NAME1. I'm not really sure how a junk value (in your case) is causing the FILE STATUS to have 10 as value. But, in a way to reproduce the error you're facing, I've moved 10 to WS-ST, whenever NAME1 field have SRINIVASAN as value. I've also broken the READ loop, when NAME1 has got SRINIVASAN.
After the READ loop, the FILE STATUS data item is being checked. If it holds 10, another READ is issued. Here, I just came across FILE STATUS 46.
46 - A sequential READ operation has been tried on a file open in the INPUT or I-O mode but no valid next record has been established.
Handling FILE STATUS 46 genuinely lets you know if the file has really reached its end. Going by this way, you can certainly differentiate EOF with junk value. Please go through the examples at the bottom of this answer and you may get some clarity.
ID DIVISION.
PROGRAM-ID. EOF1.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT INDD ASSIGN TO INDD
FILE STATUS IS WS-ST.
DATA DIVISION.
FILE SECTION.
FD INDD.
01 NAME1 PIC X(10).
WORKING-STORAGE SECTION.
01 WS-ST PIC 9(2) VALUE 0.
01 WS-READ PIC 9(2) VALUE 0.
01 WS-SWITCHES.
05 INDD-END PIC X(1) VALUE 'N'.
88 INDD-EOF VALUE 'Y'.
PROCEDURE DIVISION.
OPEN INPUT INDD.
PERFORM 100-READ THRU 100-EXIT UNTIL INDD-EOF.
IF WS-ST EQUAL 10
READ INDD
DISPLAY 'READ FILE STATUS: ' WS-ST
IF WS-ST EQUAL 46
DISPLAY 'END OF FILE'
ELSE
DISPLAY 'RECORD' WS-READ ' IS ERRORED!'
MOVE 16 TO RETURN-CODE
CLOSE INDD
STOP RUN
END-IF
ELSE
ADD 1 TO WS-READ
END-IF.
CLOSE INDD.
STOP RUN.
100-READ.
READ INDD
AT END
SET INDD-EOF TO TRUE
GO TO 100-EXIT
END-READ.
ADD 1 TO WS-READ.
DISPLAY 'READ FILE STATUS: ' WS-ST.
DISPLAY 'RECORD' WS-READ ': ' NAME1.
IF NAME1 EQUAL 'SRINIVASAN'
MOVE 10 TO WS-ST
SET INDD-EOF TO TRUE
END-IF.
100-EXIT. EXIT.
Several samples of Input and output are shown below:
Example 1:
Input: 3rd record is errored.
***************************** Top of Data ******************************
BHUTAN
NEPAL
SRINIVASAN
**************************** Bottom of Data ****************************
Output: Program ended with RC 16. Program didn't read further.
********************************* TOP OF DATA **********************************
RECORD01: BHUTAN
RECORD02: NEPAL
RECORD03: SRINIVASAN
RECORD03 IS ERRORED!
******************************** BOTTOM OF DATA ********************************
Example 2:
Input: No error record this time.
***************************** Top of Data ******************************
BHUTAN
NEPAL
**************************** Bottom of Data ****************************
Output: Program ended normally. RC 00.
********************************* TOP OF DATA **********************************
RECORD01: BHUTAN
RECORD02: NEPAL
END OF FILE
******************************** BOTTOM OF DATA ********************************
Example 3:
Input: Error record SRINIVASAN is in between BHUTAN and NEPAL. Might be in the border between these 2 countries :) ?
***************************** Top of Data ******************************
BHUTAN
SRINIVASAN
NEPAL
**************************** Bottom of Data ****************************
Output: Program ends with RC 16. Program didn't read 3rd record as the 2nd one is errored.
********************************* TOP OF DATA **********************************
RECORD01: BHUTAN
RECORD02: SRINIVASAN
RECORD02 IS ERRORED!
******************************** BOTTOM OF DATA ********************************
Example 4:
Input: Empty Input file
Output: Program ends normally.
********************************* TOP OF DATA **********************************
END OF FILE
******************************** BOTTOM OF DATA ********************************
Hope this helps!

Reading cobol file line by line seperated by new line character

I'm having trouble reading a file line-by-line. This is a current snippet of the code:
file-control.
select input-file
assign input-file-name
organization is sequential
file section.
fd input-file.
01 input-file-record picturex(25)
working-storage section.
01 ws-eof picture a(1).
and here's where I actually read in the file:
perform until ws-eof = 'Y'
read input-file into input-file-record
at end move 'Y' to ws-eof
not at end
display input-file-record
end-read
end-perform
close input-file
The problem is, i'm trying to read the file line by line, but it seems like it's just filling up 25 characters, then reading again instead of looping by the return character in the text file.
The text file would look something like this:
AAAA
BBBB
CCCC
DDDD
The problem is, i'm trying to read the file line by line, but it seems like it's just filling up 25 characters, then reading again instead of looping by the return character in the text file.
The system is exactly doing what you tell it to do:
organization is sequential *> sequential, fixed length
01 input-file-record picture x(25) *> the fixed length is 25 bytes
Depending on the compiler you use (it is always a good idea to specify this if there isn't a specific tag for it already that you can use, and even in this case the version number never harms) you can either use the common extension (which may even get standard with COBOL 202x):
organization is line sequential *> sequential, read until line break found
or have to read it sequential (in this case likely with a bigger size) and
inspect file-rec converting all x'0d' by x'0a' *> if you expect windows or mac line breaks
move 1 to strpoint
unstring file-rec
delimited by all x'0a'
into real-rec
with pointer strpoint
end-unstring

Find a substring in a string in COBOL

My problem is, given a variable which I read from a file, see if it contains or matches another string.
In other words, find in a file all the records whose variable
BRADD PIC X(30)
matches or contains a string introduced by keyboard.
I'm very confident this problem is resolved through the INSPECT instruction, and I've tried something like this in my code:
READ BRANCHFILE NEXT RECORD
AT END SET EndOfFile TO TRUE
END-READ.
PERFORM UNTIL EndOfFile
INSPECT BBRADD
TALLYING CONT for CHARACTERS
BEFORE INITIAL CITY
IF CONT>1
DISPLAY " BRANCH CODE :" BBRID
DISPLAY " BRANCH NAME :" BBRNAME
DISPLAY " BRANCH ADDRESS :" BBRADD
DISPLAY " PHONE :" BBRPH
DISPLAY " E-MAIL :" BEMAIL
DISPLAY " MANAGER NAME :" BMGRNAME
DISPLAY " ------------------"
DISPLAY " ------------------"
END-IF
READ BRANCHFILE NEXT RECORD
AT END SET EndOfFile TO TRUE
END-READ
MOVE 0 TO CONT
END-PERFORM.
Where CITY is the variable I introduce through keyboard.
¿Anyone knows how to find a "substring" in a "string"?
For example, if I introduced "Zaragoza" my program have to print all the records in the file which variable BBRADD contains "Zaragoza".
01 BRANCHREC.
88 EndOfFile VALUE HIGH-VALUE.
02 BBRID PIC X(6).
02 BBRNAME PIC X(15).
02 BBRADD PIC X(30).
02 BBRPH PIC X(10).
02 BEMAIL PIC X(20).
02 BMGRNAME PIC X(25).
You would need to set CONT to zero before the INSPECT, every time.
CONT just gets updated from its initial value when the INSPECT starts. After you find your first one, every record will look like it has CITY in it.
If may initially seem odd that it works that way, but if it didn't you'd be limited on the occasions when that is how you want it to work.
Ah, looking a little closer, you are setting CONT to an initial value, you are just doing it in an unexpected place. If it needs to be zero, set it to zero immediately before it should be zero. Much easier to find, less easy for someone changing the program in the future to make a mess of.
However, you have another problem. Let's say CITY is PIC X(20). The user enters SEVILLA and your INSPECT will now search for SEVILLA followed by 13 spaces. Ideally you'd want SEVILLA followed by one space.
You need to be able to test for a value that the user has entered, with a trailing blank, but not more.
The current popular way to do this is with reference-modification.
You need to take your user-input, find out how many trailing spaces it contains, calculate how long the data is, add one for the trailing blank, and hold that value in a field (preferably a BINARY field).
Then your INSPECT can look like this:
INSPECT BBRADD
TALLYING CONT for CHARACTERS
BEFORE INITIAL CITY ( 1 : length-of-data-plus-one )
However, then you have a problem if SEVILLA is actually in the start of the field.
So you make a small change, not to count characters which appear before it, but to count occurrences of it.
INSPECT BBRADD
TALLYING CONT for ALL
CITY ( 1 : length-of-data-plus-one )
Many people will instead code a PERFORM loop with reference-modification and do the test that way. With the final version of the INSPECT above have to code the termination logic yourself. For learning purposes it would be good to do it both ways.
When doing file-io, always use and check the FILE STATUS. Put your READ into a paragraph and perform it, you don't need two different pieces of code. If you use the FILE STATUS you don't need the AT END (or the END-READ) as the field you use to receive the FILE STATUS value will be "10" for end-of-file. Just use your 88 on that field, with the value of "10".
The Edit on your question now indicates where your existing 88-level is.
On the one hand, this is a good idea, because the end-of-file is associated with the record, and there can be no valid accidental content.
On the other hand, this is not a "portable" solution: if you use other COBOLs you may find that once end-of-file is reached it is no longer valid to access data under the FD. In the standard what happens in this situation is not defined, so you get differences amongst compilers.
You can retain the 88 on the group-item had have it portable by using READ ... INTO ... and having your record-layout in WORKING-STORAGE. This takes slightly longer to execute, as the data has to be transferred from one location to another.
I prefer the 88 on the FILE STATUS field and simplify the READ by being able to remove the AT END and END-READ. I already can't access the record-area under the FD so I can't accidentally get wrong values which look good.

Implicit Close of file

I have written the following COBOL program:
*************************************************************
* VERKOOP
*************************************************************
IDENTIFICATION DIVISION.
PROGRAM-ID. VERKOOP.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT PRODUCTEN ASSIGN TO "BESTANDEN/PRODUCTEN"
ACCESS MODE IS RANDOM
ORGANIZATION IS INDEXED
RECORD KEY IS PRODUCTID
FILE STATUS IS WS-FILE-STATUS.
DATA DIVISION.
FILE SECTION.
FD PRODUCTEN BLOCK CONTAINS 10 RECORDS.
01 PRODUCT.
02 PRODUCTID PIC X(6).
02 LEVERANCIERID PIC X(6).
02 AANTAL PIC 9(6).
WORKING-STORAGE SECTION.
77 FOUT PIC X.
88 PRODUCT-NIET-GEVONDEN VALUE 1.
77 WS-PRODUCTID PIC X(6).
77 WS-AANTAL PIC 9(6).
77 WS-FILE-STATUS PIC XX.
LINKAGE SECTION.
01 LS-PRODUCTID PIC X(6).
01 LS-AANTAL PIC 9(6).
PROCEDURE DIVISION.
* USING LS-PRODUCTID, LS-AANTAL.
MAIN.
PERFORM INITIALISEER
PERFORM LEES-PRODUCT-IN
PERFORM LEES-BESTAND
PERFORM SLUIT-BESTAND
STOP RUN.
INITIALISEER.
MOVE ZEROS TO PRODUCT
OPEN I-O PRODUCTEN.
* DISPLAY WS-FILE-STATUS..
LEES-PRODUCT-IN.
* MOVE LS-PRODUCTID TO WS-PRODUCTID
* MOVE LS-AANTAL TO WS-AANTAL.
DISPLAY "GEEF PRODUCTID OP: "
ACCEPT WS-PRODUCTID
DISPLAY "GEEF AANTAL OP: "
ACCEPT WS-AANTAL.
LEES-BESTAND.
* DISPLAY "LEES-BESTAND"
MOVE WS-PRODUCTID TO PRODUCTID
* DISPLAY PRODUCTID
READ PRODUCTEN INVALID KEY SET PRODUCT-NIET-GEVONDEN TO TRUE
END-READ
DISPLAY "END-READ" WS-FILE-STATUS
IF PRODUCT-NIET-GEVONDEN PERFORM FOUTJE
ELSE
MOVE WS-PRODUCTID TO PRODUCTID
SUBTRACT WS-AANTAL FROM AANTAL
PERFORM UPDATE-PRODUCT
END-IF.
UPDATE-PRODUCT.
REWRITE PRODUCT INVALID KEY PERFORM FOUTJE.
SLUIT-BESTAND.
* DISPLAY "SLUIT-BESTAND"
CLOSE PRODUCTEN.
FOUTJE.
DISPLAY "ER IS EEN FOUT OPGETREDEN"
* DISPLAY WS-FILE-STATUS
STOP RUN.
The idea is that I find a product by its productid in the file PRODUCTEN.dat and subtract the amount (aantal) by a given number. However everytime I run it I get the following error: WARNING - Implicit CLOSE of PRODUCTEN <"BESTANDEN/PRODUCTEN">. I don't really see the problem, the WS-FILE-STATUS line even gives me back a 00 status. I am 100% sure the product is in the file so I'm not trying to subtract from a non-existing product or anything.
UPDATE: I fixed it by assign PRODUCTEN to a newly declared file as the last one (somehow) got corrupt and was behaving in an unintended way.
To get that Implicit Close message, you must have a STOP RUN before you close the file.
You have a STOP RUN in paragraph FOUTJE, before the file is closed, so paragraph FOUTJE is being used.
You use paragraph FOUTJE in a PERFORM when PRODUCT-NIET-GEVONDEN is true.
PRODUCT-NIET-GEVONDEN is set to true on the INVALID KEY of the READ.
So INVALID KEY is true.
You get a FILE STATUS of ZERO. Unexpected, but fits what you have presented.
I don't have COBOL-IT and I don't know what OS you are using.
I also don't know in your set-up what a READ of a keyed file which does not explicitly reference a key does.
I don't know in any set-up, because I don't do it. If I'm doing a keyed read, I always specify the key.
I don't put data in the key on the file. I use a WORKING-STORAGE field for the key.
Why, well, implementation-dependent for the compiler, but unless your file is OPEN and unless there is a current record on the file, then the content, even the address, of a file record is/can be (implementation dependent) undefined.
As far as I am concerned, the KEY on the SELECT is to define the presence of the key on the file. The key you are using to READ the file obviously comes from elsewhere.
So, I would remove these:
MOVE ZEROS TO PRODUCT
MOVE WS-PRODUCTID TO PRODUCTID
I'd change this to include the KEY of WS-PRODUCTID
READ PRODUCTEN INVALID KEY SET PRODUCT-NIET-GEVONDEN TO TRUE
I'd not use INVALID KEY, I'd just use the value of WS-FILE-STATUS, which I'd expect to be "23" for "not found". I'd do the test with an 88. You then don't need your "flag" (FOUT and PRODUCT-NIET-GEVONDEN) anyway. Check the FILE STATUS field after each IO. This time you spelled your filename correctly, another time you won't and you may waste more time chasing your tail.
Work on consistent indentation, it will make your program easier to read, for you, and anyone else.
If you want to use DISPLAY to verify the logical path, you need to DISPLAY the value which is used to determine the logical path (FOUT in this case).
There are two "formats" of the READ statement. One is for sequential reads, one is for reads using a key. When each is reduced to its mandatory-only content, they are identical. Therefore it is not clear, per compiler, which type of READ is the default (when not explicit) or when it is the default (per file). So I always make it explicit:
READ PRODUCTEN KEY IS WS-PRODUCTID
I would then use the FILE STATUS field to determine whether the key was read (00 in the status) or not found (23) or something else (something else).
NOTE: This Answer as a resolution to your problem only works if everything is as you have described. Further information may invalidate this Answer as a Resolution.
The Answer does work as a generally clearer (therefore better) way to code your COBOL program.
Turns out to have been a suspected corrupted file. This may have caused a disparity between INVALID KEY and FILE STATUS, but in the normal course of events that is not going to happen. It is the only thing which fits all the evidence, but this is an exceptional case, perhaps not able to reproduce without the exact-same file corruption and clutching at this straw in a general case for why a given program is not working is probably the first refuge of a scoundrel.

Resources