[archive] How to create a subroutine library

[Migrated content. Thread originally posted on 19 March 2010]

Michael,

I seem to remember from my time at Acu that multiple programs in a single source file were always a problem. I think a tool got created that split them out into single source files, but I can't remember the details, sorry.

Nigel

I've done this using other COBOL compilers, that is, create a .lib or .DLL or .so file that contains multiple subroutines to be called by an application.

I have one COBOL source file that contains hundreds of of programs, ea:

INDENTIFICATION DIVISION
ENVIRONMENT DIVISION
DATA DIVISION
PROCEDURE DIVISION
code..
code...
END PROGRAM
**************
INDENTIFICATION DIVISION
ENVIRONMENT DIVISION
DATA DIVISION
PROCEDURE DIVISION
code..
code...
END PROGRAM
**************
INDENTIFICATION DIVISION
ENVIRONMENT DIVISION
DATA DIVISION
PROCEDURE DIVISION
code..
code...
END PROGRAM
**************


The example above is Hypothetical, the actual code is pushing 10,000 lines of cobol and hundreds of programs, I really don't want to break it up into separate source files.

When I try to compile it into an ACU file using
"ccbl32 -Sp S:\\copylib -o s:\\vplus\\sp2vplus32.acu -v -La -Dw64 -Cp -o S:\\vplus\\@.acu -x -Ga sp2vplus32.cbl"
it only compiles the first program, it seems to stop at the first "END PROGRAM".
their must be a way to get AcuCobol to compile all programs in the file, and place the resulting object code into one acu file, or a .DLL, .LIB, or .so

Any help will be much appreciated!
Michael. :confused:

[Migrated content. Thread originally posted on 19 March 2010]

Michael,

I seem to remember from my time at Acu that multiple programs in a single source file were always a problem. I think a tool got created that split them out into single source files, but I can't remember the details, sorry.

Nigel

To make the question simpler, I have the same problem using this compile command:

ccbl32 -v -La sp2vplus32.cbl

NOTE: THE 125 LINES BELOW! That's where the first END PROGRAM is found.

STATISTICS

Total Lines: 125
# of Files: 0
# of Data Items: 21
# of Paragraphs: 9

Elapsed Time: 0.0 seconds
Lines/Minute: 187500


Code Size: 607 (00025F)
Data Size: 138 (00008A)
Shared Data: 56 (000038)
Extra Segment: 42 (00002A)
Thread Segment: 36 (000024)
Address Table: 360 (000168)
Program Size: 1239 (0004D7)

0 Error(s), 0 Warning(s), 0 Caution(s)
Compilation complete

[Migrated content. Thread originally posted on 19 March 2010]

Michael,

I seem to remember from my time at Acu that multiple programs in a single source file were always a problem. I think a tool got created that split them out into single source files, but I can't remember the details, sorry.

Nigel

To make the question simpler, I have the same problem using this compile command:

ccbl32 -v -La sp2vplus32.cbl

NOTE: THE 125 LINES BELOW! That's where the first END PROGRAM is found.

STATISTICS

Total Lines: 125
# of Files: 0
# of Data Items: 21
# of Paragraphs: 9

Elapsed Time: 0.0 seconds
Lines/Minute: 187500


Code Size: 607 (00025F)
Data Size: 138 (00008A)
Shared Data: 56 (000038)
Extra Segment: 42 (00002A)
Thread Segment: 36 (000024)
Address Table: 360 (000168)
Program Size: 1239 (0004D7)

0 Error(s), 0 Warning(s), 0 Caution(s)
Compilation complete

[Migrated content. Thread originally posted on 19 March 2010]

Michael,

I seem to remember from my time at Acu that multiple programs in a single source file were always a problem. I think a tool got created that split them out into single source files, but I can't remember the details, sorry.

Nigel

To make the question simpler, I have the same problem using this compile command:

ccbl32 -v -La sp2vplus32.cbl

NOTE: THE 125 LINES BELOW! That's where the first END PROGRAM is found.

STATISTICS

Total Lines: 125
# of Files: 0
# of Data Items: 21
# of Paragraphs: 9

Elapsed Time: 0.0 seconds
Lines/Minute: 187500


Code Size: 607 (00025F)
Data Size: 138 (00008A)
Shared Data: 56 (000038)
Extra Segment: 42 (00002A)
Thread Segment: 36 (000024)
Address Table: 360 (000168)
Program Size: 1239 (0004D7)

0 Error(s), 0 Warning(s), 0 Caution(s)
Compilation complete

[Migrated content. Thread originally posted on 19 March 2010]

Michael,

I seem to remember from my time at Acu that multiple programs in a single source file were always a problem. I think a tool got created that split them out into single source files, but I can't remember the details, sorry.

Nigel

Now once they are all compiled, how can I put them into one library file?

There is a utility (cobutil32?) that does this, at least I think it does. But it can't be tested because when all routines are combined into one file.acu using the utility I can't seem to make calls to any of the routines. The error is NOT A COBOL PROGRAM.

I guess the best way to do all of this with AcuCobol is to re-write using Entry Points. :(

Any other options?

[Migrated content. Thread originally posted on 19 March 2010]

Michael,

I seem to remember from my time at Acu that multiple programs in a single source file were always a problem. I think a tool got created that split them out into single source files, but I can't remember the details, sorry.

Nigel

Yes, you can do this. First, you must split the source into separate files. Acu doesn't support multiple programs in a single source file (entry points, yes, but not separate programs).

Then combine the objects into a library with cblutl32 (on Windows) or cblutil (on Unix/Linux):

[INDENT]cblutl32 -lib -o mylib.lib prog1.acu prog2.acu prog3.acu[/INDENT]


Then preload the library with the -y runtime option (it only preloads the addresses of the programs within the library, not all of the code):

[INDENT]wrun32 -y mylib.lib prog1[/INDENT]


and within prog1 you can call the others. On a call, the preloaded object library will be searched first, then if not found the runtime will search for a .acu file on disk.

Note that once you've preloaded the library, you refer to the contained programs by their PROGRAM-ID's, not the physical .acu filenames. It's a good practice to always make them the same, though :)

And, finally, the Acu compiler doesn't compile to .dll, .so, or .exe formats. Never has, never will...

[Migrated content. Thread originally posted on 19 March 2010]

Michael,

I seem to remember from my time at Acu that multiple programs in a single source file were always a problem. I think a tool got created that split them out into single source files, but I can't remember the details, sorry.

Nigel

Michael,

I seem to remember from my time at Acu that multiple programs in a single source file were always a problem. I think a tool got created that split them out into single source files, but I can't remember the details, sorry.

Nigel

Nigel, you're probably thinking of "libutil", which is a utility designed to run on an MPE (hp3000) system to split KSAM copylibs into separate files for use on other systems that don't support KSAM. But as far as I know, we never built anything to deal with the multiple programs in a single file.

Chuck

[Migrated content. Thread originally posted on 19 March 2010]

Michael,

I seem to remember from my time at Acu that multiple programs in a single source file were always a problem. I think a tool got created that split them out into single source files, but I can't remember the details, sorry.

Nigel

Michael,

I seem to remember from my time at Acu that multiple programs in a single source file were always a problem. I think a tool got created that split them out into single source files, but I can't remember the details, sorry.

Nigel

Nigel, you're probably thinking of "libutil", which is a utility designed to run on an MPE (hp3000) system to split KSAM copylibs into separate files for use on other systems that don't support KSAM. But as far as I know, we never built anything to deal with the multiple programs in a single file.

Chuck

[Migrated content. Thread originally posted on 19 March 2010]

Michael,

I seem to remember from my time at Acu that multiple programs in a single source file were always a problem. I think a tool got created that split them out into single source files, but I can't remember the details, sorry.

Nigel

Michael,

I seem to remember from my time at Acu that multiple programs in a single source file were always a problem. I think a tool got created that split them out into single source files, but I can't remember the details, sorry.

Nigel

Nigel, you're probably thinking of "libutil", which is a utility designed to run on an MPE (hp3000) system to split KSAM copylibs into separate files for use on other systems that don't support KSAM. But as far as I know, we never built anything to deal with the multiple programs in a single file.

Chuck

[Migrated content. Thread originally posted on 19 March 2010]

Michael,

I seem to remember from my time at Acu that multiple programs in a single source file were always a problem. I think a tool got created that split them out into single source files, but I can't remember the details, sorry.

Nigel

... try to compile it into an ACU file using
"ccbl32 -Sp S:\\copylib -o s:\\vplus\\sp2vplus32.acu -v -La -Dw64 -Cp -o S:\\vplus\\@.acu -x -Ga sp2vplus32.cbl"

Michael, I notice in your compile command that you have the -o option repeated. Only the LAST one will be used, although in this case they both resolve to the same filename.

[Migrated content. Thread originally posted on 19 March 2010]

Michael,

I seem to remember from my time at Acu that multiple programs in a single source file were always a problem. I think a tool got created that split them out into single source files, but I can't remember the details, sorry.

Nigel

Nigel, you're probably thinking of "libutil", which is a utility designed to run on an MPE (hp3000) system to split KSAM copylibs into separate files for use on other systems that don't support KSAM. But as far as I know, we never built anything to deal with the multiple programs in a single file.

Chuck

Hi Chuck, I think it was one of those "gotta finish this one day" projects that never got high enough on the radar. I probably have a completely unfinished prototype lying around somewhere... ;)