View previous topic :: View next topic
|
Author |
Message |
anuraglahiri
New User
Joined: 22 Jul 2011 Posts: 5 Location: India
|
|
|
|
Hello All,
We are converting from COBOL-74 to COBOL/370. We are facing the below issue, can someone guide us.
The COBOL-74 program is called twice in same PROC.
In the first case, the input file is VB and LRECL is 124. In the second case it is VB of LRECL 66. It was working fine in both scenarios.
In the program the FD clause has a record length of 120.
Now after converting its working fine for first case but for second case failing with ABEND U4038.
Error Message:
IGZ0035S There was an unsuccessful OPEN or CLOSE of file "FILENAME" in program "PROGRAM" at relative location X'1340'.
Neither FILE STATUS nor an ERROR declarative were specified. The status code was 39. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Can you show the FD and the 01(s) for the file? |
|
Back to top |
|
|
anuraglahiri
New User
Joined: 22 Jul 2011 Posts: 5 Location: India
|
|
|
|
Hi Bill,
Below is the new FD cluase.
FD FILENAME-FILE
RECORDING MODE IS V
BLOCK CONTAINS 0 CHARACTERS
LABEL RECORDS ARE STANDARD.
01 FILENAME-RECORD PIC X(120).
The Cobol-74 version has below statement along woth the above.
RECORD CONTAINS 120 CHARACTERS. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Well, I'd expect you have compiler diagnostics telling you that the V was changed to F.
You need either, multiple 01s, or RECORD IS VARYING... or OCCURS DEPENDING ON.
Even COBOL 370 is out of service. OS/VS COBOL I'd guess for many, many, years. Why don't you go to somehting modern, and supported, like Enterpriseve COBOL V3.4? |
|
Back to top |
|
|
anuraglahiri
New User
Joined: 22 Jul 2011 Posts: 5 Location: India
|
|
|
|
Hi Bill,
Thanks for your reply.
I'm not sure of the compiler diagnostics, but the compilation was successful with return-code 0 and listing also does not show me any related messages.
I've checked with multiple 01 levels and using OCCURS DEPENDING ON as well, but the same issue while using VB file with LRECL as 66.
01 FILENAME-RECORD PIC X(120).
01 FILLER PIC X(62).
01 FILENAME-RECORD.
05 FILLER OCCURS 1 TO 120 DEPENDING ON
WS-FILENAME-REC-LEN PIC X(01).
While using the ODO, I guess because of Max-value it is always allocating 120 bytes. And the length varaible is defined in Working-Srorage.
The Admin guys might have decided to upgrade to COBOL 370. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Quote: |
The OPEN statement was unsuccessful because a conflict was detected between the fixed file attributes and the attributes specified for that file in the program. These attributes include the organization of the file (sequential, relative, or indexed), the prime record key, the alternate record keys, the code set, the maximum record size, the record type (fixed or variable), and the blocking factor. |
Have you checked that the second file is actually VB?
What does the file look like on the DMAP in your compile listing? |
|
Back to top |
|
|
anuraglahiri
New User
Joined: 22 Jul 2011 Posts: 5 Location: India
|
|
|
|
HI Bill,
Yes the second file is a VB, attributes and DMAP specified below.
Data class . . . . . : DEFAULT
Organization . . . : PS
Record format . . . : VB
Record length . . . : 66
Block size . . . . : 27998
1st extent tracks . : 1
Secondary tracks . : 1
Hierarchy and Base Hex-Displacement Asmblr Data Data Def
Data Name Locator Blk Structure Definition Data Type Attributes
PROGRAM-ID PROGRAM-----------------------------------------------------------------------------------------------------*
FD FILENAME-FILE . . . . . . . . . . . . . . . . QSAM VB
1 FILENAME-RECORD . . . . . . . . . . . . . . . BLF=00000 000 DS 120C Display
1 FILLER. . . . . . . . . . . . . . . . . . . . BLF=00000 000 DS 62C Display |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
OK, any data on it? Has it just been allocated and never opened? What happens if you browse/view it? |
|
Back to top |
|
|
anuraglahiri
New User
Joined: 22 Jul 2011 Posts: 5 Location: India
|
|
|
|
Hi bill,
It has few records, able to view it without any issues. If I do a Sort Copy and change the File attributes to VB-124. The program is running as expected. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
OK. I hope they provided you with access to the approprate Migration Guide.
If not, you might find some useful material in the Migration Guide for Enterprise COBOL V3.4.
Check your JCL, but if it works when the small records are converted to the larger size, I'd guess it would be OK. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Give this a try -
Code: |
FD FILENAME-FILE
RECORDING MODE IS V
RECORD IS VARYING IN SIZE
FROM 66 TO 120 CHARACTERS
DEPENDING ON WS-RECORD-LGTH
BLOCK CONTAINS 0 CHARACTERS
LABEL RECORDS ARE STANDARD.
01 FILENAME-RECORD PIC X(120).
WORKING-STORAGE SECTION.
01 WS-RECORD-LGTH PIC 9(08) BINARY.
01 WS-RECORD-AREA PIC X(120).
|
After a record is READ, field WS-RECORD-LGTH will contain the length of the record just read. Note that WS-RECORD-LGTH must be defined as UNSIGNED, preferably as a fullword-binary (as illustrated), the most efficient definition.
You can then move from FILENAME-RECORD to WS-RECORD-AREA (when WS-RECORD-LGTH is the maximum of 120) or use WS-RECORD-LGTH as the 2nd-part (length) of a reference modification move (1:WS-RECORD-LGTH), clearing WS-RECORD-AREA to SPACES beforehand as a failsafe.
This same feature can be used for variable-length record WRITE's, by setting the RECORD-LGTH to the desired value beforehand.
It was introduced with COBOL II version 4.0, the predecessor to COBOL/370 and is valid in all other subsequent COBOL versions, right through the latest/greatest version of Enterprise.
HTH.... |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Well, Mr Bill has shown the best way to do it.
The thing is, if this is going to work, all the other attempts would work. And they didn't, so thiis won't either.
However, thinking about that got me to the answer.
When reading the LRECL 66 file, the COBOL program still has the expectatin of receiveing a record with 120 bytes of data. When it sees the LRECL of 66 it says "oh no you don't, you musrt have given me the wrong file".
So, to test the theory, put LRECL=124 om your input ~DD when you specify the LRECL 66 file. When that works (which it will), you shoud permanently change the LRECL of 66 to 124, and document it so no-one changes it back. It causes no problem, uses no more space, it is just to allow it ot work in the COBOL program. |
|
Back to top |
|
|
ApexNC
New User
Joined: 10 Feb 2006 Posts: 19 Location: USA
|
|
|
|
[ From www.linkedin.com/groups/Handling-unknown-length-VB-file-55779.S.273977826 ]
Let me see if I understand this correctly: (1) There is one program with one FD, defined with RECORD FORMAT V either explicitly or by default. (2) There are two variable length files; One with LRECL=66, the other with LRECL=124, (3) The program executes twice, first using the LRECL=124 file, then using the LRECL=66 file. (4) The program works fine with the LRECL=124 file, but abends trying to open the LRECL=66 file.
This makes perfect sense. RECORD FORMAT V requires a file with LRECL matching the largest 01 Level definition. If you try to read an LRECL=66 file using a program with a 120 byte 01 Level under the FD, you're going to blow. Doesn't mean you can't read a 66 byte record, just that the record has to come from a file with a matching [max] LRECL (i.e. 124).
Make both files LRECL=124, put the 124 byte record in one and the 66 byte record in the other, then read each file separately in two job steps. Problem should then go away. |
|
Back to top |
|
|
|