conversion of COBOL85 program to ECOBOL program

[pramod...@gmail.com]

Hello.,I am currently running a cobol program which is close to 14KLOC and 3 identification divisions. Splitting up further is really difficult.
Now, when ever i add more code, i get
**** BINDER ERROR 17 **** Code space overflow in proc: MEASTCM. Code block length is: 64997
PAGE 318 \<SOURCE code location> Compaq COBOL85 for NonStop Himalaya Systems
No object file created.
*** 1 Binder Error

i have used ?LESS-CODE 1, ?ICODE, ?CHECK 3, ?COMPACT directives and SET
USERLIBRARY ON bind command.

Since I also want to use code coverage tool, i wanted to use Ecobol in specific.
Additionally, Is there any way to use more than 18 digits for a numeric value.
I am currently using NATIVE-8.
Any help is highly appreciated

[Keith Dick]

I am nearly certain that the BIND problem is that one of your procedure divisions, probably the one whose PROGRAM-ID is MEASTCM, has more code than can fit in a single TNS code segment.

If your program contains only standard COBOL statements and does not rely on external subprograms written in C or TAL, converting it to native mode COBOL probably would be very easy. Have you tried to compile with ECOBOL? Very often, that is all you have to do -- it just works.

If your program does depend on external C or TAL subprograms, converting to native mode probably is possible, but might take a bit of work. Not terribly hard work, but more than just compiling with ECOBOL.

If you want to try to keep the program as a COBOL85 program, you would have to split MEASTCM into two programs. I notice that you say that you have already done some splitting and it is getting hard to split it further. So maybe you can't go any further with COBOL85 and need to move to native COBOL.

If you have not already tried to compile with ECOBOL, try that and see whether you encounter any problems. If you run into problems that you cannot figure out for yourself, post details about the problems here and we'll try to help.

As far as I know, neither COBOL85 nor ECOBOL allows more than 18 digits in an exact numeric field. If you can tolerate inexact numbers (floating point), you could store floating point values in those NATIVE-8 fields, but you would have to use some C or TAL subprograms to do any operations on them, including converting to and from ASCII for display or user input. You probably wouldn't want to do that.

I believe there are open source libraries that implement integer operations on fields larger than 64-bits, which would retain exact representation of the values, but all the operations on those fields would have to be done by calls to the library, which isn't very convenient.

[pramod...@gmail.com]

Thank you Keith, for the immediate response.
As far as converting into ECOBOL, I am using a lot of TAL measure APIs in the code.
In my build , i use crossref, tal and cobol85 compilers, I have changed cobol85 to ecobol and tal to eptal.
I also have cobolex0 , cobollib, cbl85utl routines and BINSERV and SYMSERV for the build.
I then do a BIND and OCA the file.
Are there any changes needed to do into any of the files other than cobol to ecobol. I hope tal to eptal should be OK.

[wbreidbach]

I am somewhat surprised about BIND and OCA. If you are using native compilers you have to use ELD instead of BIND, OCA is not needed anymore.

[Keith Dick]

You will need to remove the references to BINSERV, SYMSERV, and OCA. I imagine CROSSREF will still work, but if it doesn't, that is not necessary for creating an executable.

For each routine in COBOLLIB and CBL85UTL that you use, look it up in the ECOBOL manual and see whether there are any differences to using it in ECOBOL. Frequently the name has changed. If you have ?SEARCH directives for COBOLLIB and CBL85UTL, the filenames for those will be different. That will be part of the differences you will find in how to use the routines from ECOBOL.

You must change COBOLEX0 to ECOBEX0.

The TAL may need some changes to work with EPTAL. Try compiling with EPTAL and see what problems it reports. If you get errors, start with chapter 5 of the manual "TNS/E Native Application Conversion Guide" and try to follow the directions there. You might also need to look at the "pTAL Conversion Guide" and "pTAL Reference Manual". You might need to make some changes for some of the address-handling code, but you might be lucky and not need much change in the TAL. If you have trouble figuring out how to make some of the changes, post your questions here.

*** IMPORTANT ****: You MUST include the SYMBOLS directive on your EPTAL commands because ECOBOL depends on the debugging information to learn enough about the procedures to be able to compile the calls to them. ECOBOL reports that it cannot find the procedures if you forget SYMBOLS on the EPTAL command. A very misleading error message. This was not true of COBOL85, and I'm pretty sure it was not true of NMCOBOL, so watch out for that difference.

The BIND will need to be changed to ELD and the commands are completely different. It probably would be easiest to compile the COBOL program that is the main program last, include the RUNNABLE directive on the command line, and make sure all of your object files needed are mentioned in ?SEARCH directives in the COBOL files that call routines contained in them, and let ECOBOL run ELD for you. If there is some ELD command that you find that you need, there is an ELD directive that you can give in the compilation that includes RUNNABLE to specify whatever extra ELD command you need, but try it first without any extra ELD commands.

There are sections in the COBOL manual for TNS and TNS/R and in the COBOL manual for TNS/E that discuss conversion from TNS to TNS/R and TNS/R to TNS/E that might show you some things that I haven't mentioned here. The COBOL manual for TNS/E also has a chapter on Libraries and Utility Routines that will help with converting calls to those library routines. Some don't require much change at all, while others are a little different.

You'll probably have a little trouble with some of the TAL and a little less trouble with some of the COBOLLIB and CBL85UTL calls, but you'll probably be able to figure out what to do with the help of the manuals. If not, post questions here and we'll try to help.

[Robert Hutchings]

When I encountered this problem many years ago I was able to create "contained subprograms" that were all in the same source-code file. This spread the code over several code segments. That was G06 Guardian, so I'm not sure this would apply to ecobol. I created COMMON subprograms.

Another option would be separately-compiles subprograms, with different source-code files. You compile them individually and then link/bind them into a single run-unit.

[pramod...@gmail.com]

On Wednesday, May 29, 2013 7:53:42 PM UTC+5:30, Robert Hutchings wrote:
> When I encountered this problem many years ago I was able to create "contained subprograms" that were all in the same source-code file. This spread the code over several code segments. That was G06 Guardian, so I'm not sure this would apply to ecobol. I created COMMON subprograms.
>
>
>
> Another option would be separately-compiles subprograms, with different source-code files. You compile them individually and then link/bind them into a single run-unit.

Thank you all.
The TAL program when compiled with EPTAL didnt pose any problem.
I compiled the cobol program straight with ecobol program by removing all ?SEARCH and replacing them with ASSIGNs. The cobol program posed some error with the library routines. I am pretty much sure that the library routines may have a different name under ecobol. NOw, where can i look for the old and new names mappings. EG: If i have a routine in COBOLLIB, where do i look for the corresponding routine in COBOLLIB for ECOBOL. The normal COBOLLIB and CBL85UTL doesnt seem to have them.

Thanks in advance.

[Keith Dick]

I'm puzzled about the part of your description where you say you replaced ?SEARCH with ASSIGN -- those two do completely different things. Unless I greatly misunderstand something, you need those ?SEARCH directives so the compiler can learn the correct calling sequence for the library routines you are calling. But that wasn't your question.

I believe you will find what you need to know about the changes in the library routines in chapter 14 of the "COBOL Manual for TNS/E Programs". If you don't know how to access the online manuals, post again to ask about doing that, and one of us will tell you how to get to the online library.

[pramod...@gmail.com]

I think that was a typo. I interchanged ?search and ?consult, Used the assigns to map the actual files.

I changed all the standard API names in cobol and tal. they all work fine with just one problem remaining.

There are 2 user defined APIs used for removeing the undefined externals problem - now, I get the error as below
*** Error: ^
--> External name not found [Error 603]
3586. ENTER TAL "SETINDEXFREELIST" OF OTALNAME.

to give a little context of what is being done here is,
the 2 procedures are written in a TAL Source and it was being compiled with TAL to get a 100 coded object named as OTALNAME.

I compiled the same source with EPTAL (below command) to get 800 coded object
"RUN $SYSTEM.SYSTEM.EPTAL/IN STALNAME,OUT $S.#TAL/OTALNAME"
however, got the error as mentioned above.

I used ELD to to make the externals visible with command "ELD / out pkd / OTALNAME -o OTALNAME1 -export_all -shared" and still find the problem.

As additional info, this is how i use the procs in the cobol source to get rid of undefined externals.
ENTER TAL "SETDATAFREELIST" OF OTALNAME.
ENTER TAL "SETINDEXFREELIST" OF OTALNAME.
STOP RUN.

If I comment these 2 lines, compilation is all successful with a slight change in the object behavior. (I get unwanted messages during normal termination)

Thanks in advance.

[dave....@gmail.com]

I am not sure you need to rename otalname to export_all but you should remove the 'of otalname' from the cobol code and use a consult= to link the tal object.

Dave

[Keith Dick]

Did you remember to include the SYMBOLS directive when compiling the EPTAL file? For some reason, ECOBOL needs information about the procedures being called that only is put into the object file when the SYMBOLS directive is included.

[pramod...@gmail.com]

Things started working fine. I selected the symbols on tal and then used eld to invoke both tal and cobol program which finally started working fine..

Thanks a lot everyone to help me..

[Keith Dick]

Thank you for letting us know the result. I'm happy to learn that you did finally get it to work.

[annd...@gmail.com]

Could you please let me know how did you use the eld to get compiled successfully.
I am getting same error 603 but for other utility.

Thanks.

[Keith Dick]

If you are having the same problem that was described in the previous posts in this discussion, that is, you are trying to call an externally-compiled subprogram from a CCOBOL program compiled with eCobol or xCobol and getting an error 603, that means the COBOL compiler could not find the externally-compiled subprogram. One common cause of that error is forgetting to include the SYMBOLS compiler option when compiling the externally-compiled program. Another common cause is not using SEARCH and CONSULT directives correctly.

Maybe those hints will be enough to let you figure out the problem. If not, you are going to have to post again and describe what you are doing in some detail and exactly where you are seeing the error 603. Then we'll probably be able to spot what to do to correct things.

[annd...@gmail.com]

Hi Kieth,
I compiled my program with symbols but still getting error for statement
ENTER TAL "CONVERT^JULIAN^TO^DATE"
Could you please suggest how can I fix this. I tried going through eld manual but didn't get how to use it.

Regards,
Ann

[Keith Dick]

Did you compile the TAL code using the EPTAL compiler (or the XPTAL compiler if you are using XCOBOL)? If not, that could be your problem.

If that is not the cause of the problem, then I would need to have an overview of how you are trying to build the program. I cannot give "the" answer because there are a number of ways you could have arranged to build the program, and the answer for your situation depends on which way you took.

I assume you have a COBOL main program, and at least this one TAL subprogram. Do you have any more COBOL subprograms? What does the call tree (which file contains calls to which other files) look like?

If you have just one COBOL source file and one TAL source file, and are working in Guardian (not in OSS), one simple way to arrange things is:

compile the TAL with EPTAL and include the SYMBOLS directive
compile the COBOL with ECOBOL and include a SEARCH directive that names the object file produced by the EPTAL compilation

If you have more than one COBOL source file and the TAL is called from more than one of the COBOL files, the best way to arrange things depends on the call tree, and might involve using CONSULT directives and ELD rather than SEARCH directives, or some CONSULT directives and some SEARCH directives. If you can describe the call tree, I probably could give you a precise suggestion.

Is there any reason besides getting the call of the TAL code to work that you want to use ELD? Are you working in OSS rather than in Guardian?

[annd...@gmail.com]

I am compiling the program in guardian with Symbols. I have one main cobol program with two TALs that is
ENTER TAL "CONVERT^JULIAN^TO^DATE
ENTER TAL "CONVERT^DATE^TO^JULIAN
One pathsend call to a java program configured in a server.
One pathsend call to same cobol program configured in a with a different server name.

Normally, I just make the basic native changes required and compile the cobol program with ECOBOL compiler and its works but its not working for this program.

[Keith Dick]

That should be pretty simple.

Just to be sure -- when you use ECOBOL to compile the COBOL main program, you get the error 603 from the ECOBOL compiler and the text of the message says it cannot find the subprogram you are calling. Is that what you are seeing? If that is not what you are seeing, explain at what point you get the error 603 and what the text of that error message says.

Things to check:

1. When you compiled the TAL, you used the EPTAL compiler and you included the SYMBOLS directive when doing that compilation.
(if the two TAL subprograms are in different source files and you compile them separately, this applies to both compilations)

2. When you compiled the COBOL, you used the ECOBOL compiler and you included a SEARCH directive that named the file that
the EPTAL compilation created. (If the TAL was compiled with two compilations, the SEARCH directive named the files produced
by both EPTAL compilations.)

If you have done both those things, and still get the 603 error, are you getting any other error messages when you try to compile the program?

[Bill Honaker]

Ann,

The TAL compiler creates a Code 100 (TNS) binary. The EOBOL compiler creates a Code 800 (Native TNS-E, Itanium) binary. You can't combine the two, they are not compatible.

You'll need to find the TAL source that contains the 2 routines, and compile it with the PTAL compiler. This may require you to make some source changes.

Then you can point the ?SEARCH directive of the ECOBOL source to the output from the PTAL compiler. (You probably should not overwrite the original library, as older programs may still rely on it).

I hope that helps.

Bill Honaker

[annd...@gmail.com]

Hi Keith and Bill,

Thank you so much! I found the missing TAL source compiled with PTAL compiler and added the output file in ?SEARCH directive of ECOBOL source. After which I was able to compile the program successfully.

[Bill Honaker]

Ann,

Thanks for sharing your success story with us. Glad we could help you to find your way!
Bill