View previous topic :: View next topic
|
Author |
Message |
socker_dad
Active User
Joined: 05 Dec 2006 Posts: 177 Location: Seattle, WA
|
|
|
|
We should just outlaw variable length files: DASD is cheap, programmers expensive!
Code: |
FD NIGHTLY-PERSON
RECORDING MODE IS V
LABEL RECORDS ARE STANDARD
BLOCK CONTAINS 0 RECORDS.
01 PERSON-REC.
++INCLUDE E1075500. |
FileAid shows the record layout as
Code: |
-------- FIELD LEVEL/NAME --------- --PICTURE-- FLD START END LENGTH
E5500-PERSON-INFO 1 8335 8335
5 E5500-PERSON-INFO GROUP 1 1 933 933
10 E5500-SSN X(9) 2 1 9 9 |
The source file is defines as
Code: |
Organization . . . : PS
Record format . . . : VB
Record length . . . : 8339
Block size . . . . : 27998 |
AbendAid says
Code: |
An error occurred when opening or closing a file.
An attempt to OPEN file IPERNITE failed due to a file attribute
conflict. The file attributes described in the program file description
(FD) conflict with either:
1. The DCB parameters specified on the DD statement
in the JCL
2. The actual attributes of the dataset.
DSN: SEB107.#RW.W9371.NIGHTLY.PERSON.FILE
VOLSER: SHB913
DDNAME: IPERNITE
RECFM: VB
LRECL: 8339
BLKSIZE: 25019
Variable records - Blocksize-4 not a multiple of LRECL
The IBM message that corresponds to the condition is:
IGZ0035S There was an unsuccessful OPEN or CLOSE of file IPERNITE in
program B1075677 at relative location X'1E5C'. Neither FILE
STATUS nor an ERROR declarative were specified. The status
code was 39. |
Using a FileAid copy, I can force the blocksize to be whatever, but no value works. I've tried (8339 * 3), (8339 * 3 +4), and various calculations based on 8335. I've even gone so far as to define 1 record per block (8335/8339, 8339/8343) to no avail.
And the DD names match JCL - already checked that.
Any suggestions? |
|
Back to top |
|
|
socker_dad
Active User
Joined: 05 Dec 2006 Posts: 177 Location: Seattle, WA
|
|
|
|
(Oh, the displays may not match each other - I've got about 30 interations of my attempts. |
|
Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
|
|
|
|
socker_dad wrote: |
...
Code: |
Organization . . . : PS
Record format . . . : VB
Record length . . . : 8339
Block size . . . . : 27998 |
AbendAid says
Code: |
An error occurred when opening or closing a file.
An attempt to OPEN file IPERNITE failed due to a file attribute
conflict. The file attributes described in the program file description
(FD) conflict with either:
1. The DCB parameters specified on the DD statement
in the JCL
2. The actual attributes of the dataset.
DSN: SEB107.#RW.W9371.NIGHTLY.PERSON.FILE
VOLSER: SHB913
DDNAME: IPERNITE
RECFM: VB
LRECL: 8339
BLKSIZE: 25019
Variable records - Blocksize-4 not a multiple of LRECL |
... |
Now it seems to me there are two issues. First there seem to be conflicting claims about BLKSIZE. One place says 27998; another place claims 25019. Check both.
Quote: |
Variable records - Blocksize-4 not a multiple of LRECL |
I recall a brief period when this theory floated around. But think about it. The assumption seems to be the records are fixed length. But the records are variable length! In RECFM V, LRECL defines the maximum length record. Period. End of story. Obviously it must be less than or equal to BLKSIZE-4, but that's all. Why force assumptions that apply to data sets with fixed length records to data sets with variable length records.
Abend-Aide should specify three things to check, not 2.- The DCB parameters in the actual DCB being opened.
- The DCB parameters specified by the DD statement that is being opened.
- The actual attributes of the data set.
The first is used, then the second, and last, the attributes of the data set. I fear the BLKSIZE came from the DCB, which, in a Cobol program is how the FD is specified. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Quote: |
FileAid shows the record layout as |
Who cares what File Aid says? COBOL is telling you there is a mismatch between the physical data set (or the JCL definition for that physical data set) and what the COBOL file definition is. If you had posted the FD 01 variable length from the compile output, THAT would be telling us something. What you've posted so far merely indicates that COBOL doesn't have the correct file definition yet.
Quote: |
And the DD names match JCL - already checked that. |
If there was a mismatch, you would get a file status 35, not a 39 -- 39 is very specific to variable length record lengths (or alternate index record lengths, or block size mismatches -- there are multiple possible causes for a file status 39).
Also, is this a new program or one that has been changed? If it has been changed and was working before being changed, you should start by looking at the changes -- standard debugging methodology. |
|
Back to top |
|
|
socker_dad
Active User
Joined: 05 Dec 2006 Posts: 177 Location: Seattle, WA
|
|
|
|
I mentioned that the block sizes between the two examples didn't match because there are about 30 interations of the test.
This is a new program, converting the old file to a shorter new file; both variable length. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
File Aid is an independent program from a software vendor. What it tells you may -- or may not -- be relevant to the COBOL code.
If you really wanted a solution, instead of complaining, you would have posted the requested information -- the compile information showing what COBOL says the FD 01 length is. Since you are getting a file status 39, only COBOL information will help resolve your issue -- if you want it resolved. |
|
Back to top |
|
|
|