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?
...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..&......
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
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?
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
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?
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
My guess that the case of the "too large" load module hasn't been reached - yet - 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. . .
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.
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.
My guess that the case of the "too large" load module hasn't been reached - yet - 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.
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
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.
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
Quote:
Although the program is almost too big to be manageable
Ah, the gift of understatement. . .
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
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.
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.
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
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.