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

COBOL74 Compile Fails When Adding New Code


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

New User


Joined: 26 Apr 2006
Posts: 22
Location: Canada

PostPosted: Wed Sep 08, 2010 2:12 am
Reply with quote

I'm looking at a problem in a VSE environment where they are adding code to a COBOL74 program and getting the following when trying to compile:

0S03I PROGRAM CHECK INTERRUPTION - HEX LOCATION 00505794 -
INTERRUPTION CODE 01 - OPERATION EXCEPTION

I can remove 1 line of code and then compile ok. Add the 1 line back in, and the above exception occurs. Another developer said he removed many lines of code from another part of the program, but still got the error.

Not sure where to start looking, is this a COBOL74 limitation, or compile options not set correctly?

Anyone point me in the right direction?

Thanks.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Wed Sep 08, 2010 2:55 am
Reply with quote

Hello,

How many lines of non-comment code are in the source?

When it does compile successfully, how big is the object module?

Does one particular line of code cause the abend or does adding any more code cause the problem?

What warnings are generated when the compile is successful?

It may help if you post the first few lines of output from the compiler.
Back to top
View user's profile Send private message
rpenner

New User


Joined: 26 Apr 2006
Posts: 22
Location: Canada

PostPosted: Wed Sep 08, 2010 7:37 pm
Reply with quote

Program has about 22000 lines of non-comment code. Object module is 1357848 bytes.

Does not seem to be related to a particular line of code.

There are a LOT of warning messages on successful compile. Let me know if you need to see them and I will attach in a text file.

Here is some of the ouput from compile:

Code:

// EXEC PROC=COBOLVS,FLIB='TEST.TB56,PRD2.PROD',TLIB='TEST.TB56'
LIBDEF PHASE,SEARCH=(PROD.COBOLVS,TEST.TB56,PRD2.PROD),CATALOG=TEST.TB56
LIBDEF OBJ,SEARCH=(PROD.COBOLVS,TEST.TB56,PRD2.PROD)
LIBDEF SOURCE,SEARCH=(TEST.TB56,PRD2.PROD)
EOP COBOLVS
// EXEC PROC=SYSWKFLE
// DLBL IJSYS01,'===SYS.WORKFILE.SYS001',0,SD
// EXTENT SYS001,WORK01,,,1,500
// DLBL IJSYS02,'===SYS.WORKFILE.SYS002',0,SD
// EXTENT SYS002,WORK01,,,1,500
// DLBL IJSYS03,'===SYS.WORKFILE.SYS003',0,SD
// EXTENT SYS003,WORK01,,,1,500
// DLBL IJSYS04,'===SYS.WORKFILE.SYS004',0,SD
// EXTENT SYS004,WORK01,,,1,500
// DLBL IJSYS05,'===SYS.WORKFILE.SYS005',0,SD
// EXTENT SYS005,WORK01,,,1,500
// DLBL IJSYS06,'===SYS.WORKFILE.SYS006',0,SD
// EXTENT SYS006,WORK01,,,1,500
// DLBL IJSYS07,'===SYS.WORKFILE.SYS007',0,SD
// EXTENT SYS007,WORK01,,,1,500
// DLBL IJSYS11,'===SYS.WORKFILE.SYS011',0,SD
// EXTENT SYS011,WORK01,,,1,500
// DLBL IJSYSLN,'===SYS.WORKFILE.SYSLNK',0,SD
// EXTENT SYSLNK,WORK01,,,1,500
EOP SYSWKFLE
// EXEC IESINSRT
1S54I  PHASE IESINSRT IS TO BE FETCHED FROM IJSYSRS.SYSLIB
// OPTION SYSPARM='DOSV',LISTX
// EXEC FCOBOL,SIZE=400K
1S54I  PHASE FCOBOL   IS TO BE FETCHED FROM PROD.COBOLVS
     1  IBM DOS/VS COBOL                           REL 3.1               PP NO. 5746-CB1
 CBL CLIST,BUF=1024,NOZWB,SXREF,OPTIMIZE,LIB,APOST,LANGLVL(1),NOADV    DCBL00020
 CBL SXR,BUF=15000,NOZWB,OPT,LIB,FLAGE,CLI,VERB
Back to top
View user's profile Send private message
rpenner

New User


Joined: 26 Apr 2006
Posts: 22
Location: Canada

PostPosted: Wed Sep 08, 2010 7:44 pm
Reply with quote

Attaching warning messages.
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: Wed Sep 08, 2010 7:44 pm
Reply with quote

LANGLVL (1) is COBOL 68. LANGLVL (2) is COBOL 74....

Bill
Back to top
View user's profile Send private message
rpenner

New User


Joined: 26 Apr 2006
Posts: 22
Location: Canada

PostPosted: Wed Sep 08, 2010 8:02 pm
Reply with quote

Bill O'Boyle wrote:
LANGLVL (1) is COBOL 68. LANGLVL (2) is COBOL 74....

Bill


Thanks. I don't think my problem is related to that though?
Back to top
View user's profile Send private message
rpenner

New User


Joined: 26 Apr 2006
Posts: 22
Location: Canada

PostPosted: Wed Sep 08, 2010 8:26 pm
Reply with quote

I'm adding more info from the dump. Could be a limitation of the operating environment?

Code:

0S03I PROGRAM CHECK INTERRUPTION  - HEX LOCATION 00505794 - INTERRUPTION CODE 01 - OPERATION EXCEPTION
0S00I JOB RPD11E0  CANCELED
0S07I PROBLEM PROGRAM  PSW = 07CD0000 00505796

SYMPTOM RECORD

003C4100                                     00000001 E2D9F2F0 F8F6F3F6 F4F7F6C3   00                   ....SR208636476C
003C4120 F0F97AF2 F17AF0F0 7AF0F0F1 F061F0F9 61F0F8F1 F47AF2F1 7AF0F07A F0F0F5F6        09:21:00:0010/09/0814:21:00:0056
003C4140 F8F6C3C6 F8F0F6F9 F1C34000 E2C3D7D9 C5D84040 00000000 00000000 004C0074        86CF80691C .SCPREQ  .........<..
003C4160 000000C0 002B00C0 000000EB 00000000 00000000 00000000 00000000 00000000        ................................
003C4180 00000000 00000000 C1C261E2 F2F0F0F0 40D9C5C7 E261F0C4 F4F2F240 D9C5C7E2        ........AB/S2000 REGS/0D422 REGS
003C41A0 61F0C3C1 F6C540D4 E261F0E2 F0F3C940 D9C9C4E2 61D9D7C4 F1F1C5F0 40D6C6C6        /0CA6E MS/0S03I RIDS/RPD11E0 OFF
003C41C0 E261F0F0 F0F0F5F7 F9F640C1 C261E2F0 F0F0F140 D1D6C26D D5C1D4C5 7ED9D7C4        S/00005796 AB/S0001 JOB_NAME=RPD
003C41E0 F1F1C5F0 4040C4E4 D4D7C5C4 6DC4C1E3 C17EC6F1 60D7C1D9 E3C9E3C9 D6D540          11E0  DUMPED_DATA=F1-PARTITION




...00000   ILA0000I-D  COMPILER
ERROR.  COMPILATION ABANDONED...
.
.
.
........$$BCLOSE.&.."DTFXSMGT$$B
DUMP 13..ILA0004I- OUTPUT OPTION
S SUPPRESSED DUE TO ERROR SEVERI
TYEND OF COMPILATIONj.......h...
.
.
.
.&..[b]ILA0005I-D LOGIC OR MACHINE
ERROR IN TAMER.  COMPILATION ABA
NDONED.ILA0003I-D A TABLE HAS EX
CEEDED MAXIMUM SIZE.  COMPILATIO
N ABANDONED.ILA0001I-D NO MORE T
ABLE SPACE AVAILABLE.  COMPILATI
ON ABANDONED[/b].....&...&...&...&..
.&...&.b.&...&...&.2......"... .
...&&&..............&&&.........
.............&*.........FCOBOL62
3010/05/9016.32........0.00..&..
.
.
.

.REGISTER ASSIGNMENTBL =...9....
..."............................
................"........ ....0.
.................&.b............
................................
................................
.......&..........BLL =TGTOV =PG
TOV =INIT1INIT2INIT3DS30F..WORKI
NG-STORAGE STARTS AT LOCATION
    FOR A LENGTH OF      . ILA60
006I-E    MAP SUPPRESS SPECIFIED
 AND E LEVEL DIAGNOSTIC HAS OCCU
RRED. LISTX,CLIST,LINK,DECK,COUN
T OPTIONS         WILL BE SUPPRE
SSED.ILA6007I-D    TABLE OVERFLO
W. LISTX, LOAD MODULE AND DECK W
ILL BE INCOMPLETE. INCREASE PART
ITION. .......    ........    ..
......PHASE.END .......ILBDATB0E
TB0ITB0TRN0MNS0LITERAL POOL (HEX
)DISPLAY LITERALS (BCD)TLERRMSG
 .......LIT+......j...j..0h...j:
.0h...j@.0h..0h...j=.0h..&......
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Wed Sep 08, 2010 8:47 pm
Reply with quote

Hello,

Well, 22000 lines is more than big. . .

As an experiment, you might take some large PERFORMed routine and make this a called module (thereby reducing the source by as many lines as possible by a simple change). As this would really be "part" of the large module, suggest it be called statically (these should probably be in sync and not dynamic).

I would also get rid of many/most (preferably all) of the warnings.

It is also possible that a WORKFILE has gone beyond the extent. Is this WORK01,,,1,500 used for all compiles?
Back to top
View user's profile Send private message
Phrzby Phil

Senior Member


Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia

PostPosted: Wed Sep 08, 2010 8:50 pm
Reply with quote

Quote:
Another developer said he removed many lines of code from another part of the program, but still got the error.


What do you mean by "another part of the program."

Different COBOL Section?
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: Wed Sep 08, 2010 8:53 pm
Reply with quote

This seems to be a very large load module.

A S0C1 indicates a bad OP CODE.

Maybe the load module is just too big?

Perhaps breaking this behemoth down into sub-programs, although I don't know if your version of VSE COBOL and the Operating System supports Dynamic Calls, because Static Calls will put you back in the same dilemma (one giant load module).

Do you have any other Production load modules of this size or greater?

Bill
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Wed Sep 08, 2010 9:03 pm
Reply with quote

Hello,

My guess that the case of the "too large" load module hasn't been reached - yet icon_smile.gif - because the compile abends rather than the link. . . Of course, the object might be larger than some limit. . .

Another guess is that some "work table" the compiler uses has gone out of bounds. . .
Back to top
View user's profile Send private message
rpenner

New User


Joined: 26 Apr 2006
Posts: 22
Location: Canada

PostPosted: Wed Sep 08, 2010 9:31 pm
Reply with quote

Yep, it's big. I tried increasing the workfile extents, same result. I think you're right, will just need to break the program down, it's just too big.
Back to top
View user's profile Send private message
rpenner

New User


Joined: 26 Apr 2006
Posts: 22
Location: Canada

PostPosted: Wed Sep 08, 2010 9:36 pm
Reply with quote

Phrzby Phil wrote:
Quote:
Another developer said he removed many lines of code from another part of the program, but still got the error.


What do you mean by "another part of the program."

Different COBOL Section?


Sorry, should've been more clear. He apparently removed unused paragraphs of code (don't ask me why there is unused code, I have no idea) from the program. I don't know if it was commented or not.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Wed Sep 08, 2010 9:37 pm
Reply with quote

Good luck icon_smile.gif

Someone will be here if there are new "opportunities". . . icon_wink.gif

d
Back to top
View user's profile Send private message
Phrzby Phil

Senior Member


Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia

PostPosted: Wed Sep 08, 2010 9:39 pm
Reply with quote

I'd leave the warnings alone for now - they all have the usual assumptions (code in area A, assume B, etc.).
Back to top
View user's profile Send private message
rpenner

New User


Joined: 26 Apr 2006
Posts: 22
Location: Canada

PostPosted: Wed Sep 08, 2010 9:41 pm
Reply with quote

dick scherrer wrote:
Hello,

My guess that the case of the "too large" load module hasn't been reached - yet icon_smile.gif - because the compile abends rather than the link. . . Of course, the object might be larger than some limit. . .

Another guess is that some "work table" the compiler uses has gone out of bounds. . .


I'm thinking the same. It's not an issue with the program or load module size, but some kind of space issue with the compiler/operating system. Although the program is almost too big to be manageable, should be broken down anyway.
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: Wed Sep 08, 2010 11:40 pm
Reply with quote

I'm going to ask this anyway, although I might get flamed. Are there any hard-coded (and very large) WS internal tables in this program, which contain Static data?

They can be changed to Static Assembler Tables and be made available to the program (Dynamically Loaded) via a small Assembler sub-program, which issues a CDLOAD Macro and returns the LP address and length back to the Caller in a parmarea of the target table.

Addressability will then be done via the LINKAGE SECTION and the storage will be external to the program.

Just a SWAG.... icon_wink.gif

Bill
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Thu Sep 09, 2010 12:19 am
Reply with quote

Hello,

Quote:
Although the program is almost too big to be manageable
Ah, the gift of understatement. . . icon_cool.gif

Quote:
Are there any hard-coded (and very large) WS internal tables in this program, which contain Static data?
Again, and only a guess, i believe there are too many "things" and the compiler has run amok (rather than "things" that are "too big"). . .

A compiler i worked once upon a time had a fatal problem when there were too many characters of data names (not the number of names, but the over length of these names). . . We fixed this by taking the array out of memory and using disk for the really large code. . .

As the source for that cobol74 compiler is probably not available, upping limits internally is not an option icon_wink.gif
Back to top
View user's profile Send private message
rpenner

New User


Joined: 26 Apr 2006
Posts: 22
Location: Canada

PostPosted: Thu Sep 09, 2010 12:56 am
Reply with quote

Quote:
They can be changed to Static Assembler Tables and be made available to the program (Dynamically Loaded) via a small Assembler sub-program


I don't think I want to tackle that. icon_eek.gif

Quote:
Again, and only a guess, i believe there are too many "things" and the compiler has run amok (rather than "things" that are "too big"). . .


Yep, there are programs here that have been added to and added to until they are monsters.

What are your thoughts on converting to COBOL85? I was doing some experimenting and created a COBOL85 program double the size of my problem program by duplicating code and compiled it with no issues. Any thoughts as to why that would be. Does the newer compiler use less memory? The load module is siginificantly smaller as well.

Thanks for all the input.
Back to top
View user's profile Send private message
Phrzby Phil

Senior Member


Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia

PostPosted: Thu Sep 09, 2010 1:07 am
Reply with quote

Almost always worthwhile upgrading to a version that is only 25 years old, as opposed to 36 years old.

But seriously - upgrade for sure, esp. since you can't change the current program.
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: Thu Sep 09, 2010 2:08 am
Reply with quote

Quote:
What are your thoughts on converting to COBOL85? I was doing some experimenting and created a COBOL85 program double the size of my problem program by duplicating code and compiled it with no issues. Any thoughts as to why that would be. Does the newer compiler use less memory? The load module is siginificantly smaller as well.

COBOL 85 is actually COBOL II (not sure what it's known by in VSE). However, converting from ANSI 68/74 Batch to 85 isn't too bad (CICS is more involved).

You need to replace EXAMINE, TRANSFORM with INSPECT. If you're using the CURRENT-DATE and TIME-OF-DAY Special Registers, they can be substituted with their equivalent ACCEPT Verbs or by Calling LE Callable routines (providing LE is installed when you upgrade), for example "CEELOCT" will return a Date/Time in a format of CCYYMMDDHHMMSSMMM (MMM is milliseconds).

As soon as you compile the program with the newer compiler, errors should jump out like a cockroach with a hot foot. icon_wink.gif

Bill
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Thu Sep 09, 2010 2:37 am
Reply with quote

Hello,

Suggest you upgrade to a currently supported compiler rather than a compiler that is also out of date. . .

And (as Bill mentioned) CICS code may lead to additional discoveries.

fwiw
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 run rexx code with jcl CLIST & REXX 15
No new posts Compile rexx code with jcl CLIST & REXX 6
No new posts Adding QMF and SPUFI to the ISPF menu DB2 20
No new posts Sort First/last record of a subset th... DFSORT/ICETOOL 7
No new posts Adding first / last acct numerber to ... DFSORT/ICETOOL 7
Search our Forums:

Back to Top