Migrating from COBOL-74 to COBOL/370

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.

Bill Woodger · Posted: Mon Sep 16, 2013 1:59 pm

Can you show the FD and the 01(s) for the file?

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.

Bill Woodger · Posted: Mon Sep 16, 2013 3:41 pm

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?

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.

Bill Woodger · Posted: Mon Sep 16, 2013 4:29 pm

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

Bill Woodger · Posted: Mon Sep 16, 2013 4:52 pm

OK, any data on it? Has it just been allocated and never opened? What happens if you browse/view it?

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.

Bill Woodger · Posted: Mon Sep 16, 2013 8:26 pm

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.

Bill O'Boyle · Posted: Mon Sep 16, 2013 11:18 pm

Give this a try -

Bill Woodger · Posted: Tue Sep 17, 2013 3:38 am

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.

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.