IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Migrating from COBOL-74 to COBOL/370


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
anuraglahiri

New User


Joined: 22 Jul 2011
Posts: 5
Location: India

PostPosted: Mon Sep 16, 2013 12:30 pm
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Mon Sep 16, 2013 1:59 pm
Reply with quote

Can you show the FD and the 01(s) for the file?
Back to top
View user's profile Send private message
anuraglahiri

New User


Joined: 22 Jul 2011
Posts: 5
Location: India

PostPosted: Mon Sep 16, 2013 2:21 pm
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Mon Sep 16, 2013 3:41 pm
Reply with quote

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
View user's profile Send private message
anuraglahiri

New User


Joined: 22 Jul 2011
Posts: 5
Location: India

PostPosted: Mon Sep 16, 2013 4:03 pm
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Mon Sep 16, 2013 4:29 pm
Reply with quote

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
View user's profile Send private message
anuraglahiri

New User


Joined: 22 Jul 2011
Posts: 5
Location: India

PostPosted: Mon Sep 16, 2013 4:46 pm
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Mon Sep 16, 2013 4:52 pm
Reply with quote

OK, any data on it? Has it just been allocated and never opened? What happens if you browse/view it?
Back to top
View user's profile Send private message
anuraglahiri

New User


Joined: 22 Jul 2011
Posts: 5
Location: India

PostPosted: Mon Sep 16, 2013 5:18 pm
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Mon Sep 16, 2013 8:26 pm
Reply with quote

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
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Mon Sep 16, 2013 11:18 pm
Reply with quote

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
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Tue Sep 17, 2013 3:38 am
Reply with quote

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
View user's profile Send private message
ApexNC

New User


Joined: 10 Feb 2006
Posts: 19
Location: USA

PostPosted: Tue Sep 17, 2013 9:08 pm
Reply with quote

[ 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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts Replace each space in cobol string wi... COBOL Programming 3
No new posts COBOL -Linkage Section-Case Sensitive COBOL Programming 1
No new posts COBOL ZOS Web Enablement Toolkit HTTP... COBOL Programming 0
No new posts Calling DFSORT from Cobol, using OUTF... DFSORT/ICETOOL 5
No new posts Generate random number from range of ... COBOL Programming 3
Search our Forums:

Back to Top