UNIX 198 "Load Error" with dynamically called MF COBOL subprogram 1

[rthiele84]

When running our UNIX job scripts we randomly get the following 198 error below. When we restart the job it works fine. The Driver and subprogram are both coded in MF COBOL and create a .gnt executable. I haven't been able to recreate the problem in test, so I'm wondering if it has something to do with Cron or possibly a memory error or memory leak. I don't see anything obvious in the COBOL subprogram DATECONV and not sure why is looking for a .so file. Any help would be greatly appreciated!

Load error : file 'DATECONV.so'
error code: 198, pc=0, call=1, seg=0
198 Load failure (fatal: _ex_unwind: can't find symbol)

 

[webrabbit]

198 is strictly a Micro Focus COBOL error code. In the past, I have never been able to pinpoint a specific cause. I think memory is being corrupted, but I'm not sure.

Of course, if the called program does not exist in the load path, you will always get this error, but you say it is random and cannot be reliably repeated.

 

[rthiele84]

Would changing the Call of DATECONV from a Dynamic to a Static call fix the problem? This program is very stable and rarely changes.

 

[webrabbit]

That is definately a possiblity.

 

[rthiele84]

I changed the call of the subprogram from dynamic to static by changing the call from

01 DATECONV PIC X(08) VALUE 'DATECONV'.
CALL DATECONV USING......

to

CALL 'DATECONV' USING......

I'm still getting the same load error as before. Anyone have any ideas on what may be the problem or something I should check?

 

[TonHu]

Is the application still in the correct directory?
Are the environment variables COB* set up properly?

 

[webrabbit]

You have to set up a hard link during the link step. I used to know how to do this, but have fogotten.

 

[jmanj]

We have lots of MF cobol programs running under unix (solaris or aix) here's a snippet of how do calls to other programs or scripts:

WS:

01 CALLS-SCRIPT.
02 CALLSWS-CMD-STRING.
03 CALLSWS-SYS-COMMAND PIC X(100) VALUE SPACES.
03 CALLSWS-NULL-CHAR PIC X(001) VALUE x"00".

PROCEDURE:

INITIALIZE CALLSWS-CMD-STRING.

STRING "CALL_mail.ksh"
DELIMITED BY SIZE
INTO CALLSWS-CMD-STRING.

CALL "SYSTEM" USING CALLSWS-CMD-STRING.


NOTE: In unix you have to have a NULL character at the end of your command string.

Hope this helps.

 

[rthiele84]

Thanks jmanj,

So for my example, my call was originally:

01 DATECONV PIC X(08) VALUE 'DATECONV'.
CALL DATECONV USING WS-DATE-FIELDS.

You are saying I should change it to:

INITIALIZE CALLSWS-CMD-STRING.
STRING "CALL_mail.ksh"
DELIMITED BY SIZE
INTO CALLSWS-CMD-STRING.
MOVE LOW-VALUES TO CALLSWS-NULL-CHAR.
CALL "DATECONV" USING CALLSW-CMD-STRING,
WS-DATE-FIELDS.

 

[rthiele84]

jmanj

Can you reply back and let me know if this is the change you are suggesting?

Thanks

 

[jmanj]

There is more to unix than just calling programs or scripts.
we use 'SYSTEM' to indicate that all scripts like perl or ksh, awk etc are treated as system commands. You will also need to provide the full path of you command executables (bin directories) in your environment variables.

If your DATECONV is a cobol program then you need to create a linkage then you can statistically or dynamically call it:
CALL 'DATECONV' using parms

Again you will need to create COBPATH variable where all the cobol execs are located.

In our case we have a C program that invoke other cobol programs. We use INVOKE instead of a call. The only difference is that we can test for return codes from the invoked programs. The micro focus manual should provide you an instruction on how to dynamically link sub programs.

It's been a while so I don't remember how I did it.

 

[rthiele84]

So it sounds like I don't need the CALL "SYSTEM". I'm doing what you have stated above. The COBPATH is pointing to the correct directory of my subprogram DATECONV.gnt. The Driver programs and subprograms are all MF COBOL. I've linked it dynamically and statically and either way I still go the Load Error periodically. I'm not sure if there is any difference between
CALL 'DATECONV' using parms
and
CALL "DATECONV" using parms
Both of these should link the DATECONV program statically to the Driver program.

If your DATECONV is a cobol program then you need to create a linkage then you can statistically or dynamically call it:
CALL 'DATECONV' using parms

 

[jmanj]

There are may cobol paths that needs to be defined in your environment (sorry but I forgot the names). You may also check the permissions to the locations and executables. There are many reason for code 198. You may have to recompile DATECONV (could be corrupted) or on rare occasion you may have not enough memory to run your program. Another thing to look at are misspelled path names.