On Mon, Sep 22, 2014 at 8:24 AM, Kirk Wolf <[email protected]> wrote: > We have a batch utility program that is built in C that uses the XPLINK > version of the C runtime. A customer would like to "dynamically" call > this from COBOL, but of course the LE runtimes are not compatible: > > IGZ0179S A dynamic call to COZBATCH failed because the load module contains > one > or more routines with XPLINK linkage. > > > Is it possible to do the equivalent of a Assembler "LINK" (separate RB and > LE runtime environment) from COBOL without writing an Assembler stub > routine? > > Thanks, > > Kirk Wolf > Dovetailed Technologies > http://dovetail.com >
Hum. An interesting question. I wonder if one of the following UNIX services might be of some use? attach_execmvs: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB1C0/2.8 execmvs: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BPXZB1C0/2.30 You mention COZBATCH, and I don't know what your user is trying to do. COBOL can do a lot of UNIX work itself. If they are use the Hybrid Batch functionality, to run on a different machine, then I would definitely use the attach_execmvs() to run COZBATCH. I guess they are likely _not_ passing anything more complicated than what you can in a BATCH JCL invocation PARM= parameter. I would _not_ use execmvs() because it, like the UNIX exec() function, _replaces_ the running process image (more like an XCTL, kinda, sorta). I can write COBOL, but am not an expert. The code would look something like: 01 ATTACH-EXECMVS-DATA. 05 PROGRAM-NAME-LENGTH PIC S9(9) BINARY VALUE +8. 05 PROGRAM-NAME PIC X(8) VALUE 'COZBATCH'. 05 ARGUMENT-LENGTH PIC S9(9) BINARY VALUE ZERO. 05 ARGUMENT PIC X(8). 05 EXIT-ROUTINE-ADDR PIC S9(9) BINARY VALUE ZERO. 05 EXIT-ROUTINE-LIST-ADDR PIC S9(9) BINARY VALUE ZERO. 05 RETURN-VALUE PIC S9(9) BINARY. 05 REASON-CODE PIC S9(9) BINARY. 05 OPTIONS PIC S9(9) BINARY VALUE ZERO. 05 STATUS PIC S9(9) BINARY. 05 WORK-CODE PIC S9(9). .... CALL 'BPX1ATM' USING PROGRAM-NAME-LENGTH, PROGRAM-NAME, ARGUMENT-LENGTH, ARGUMENT, EXIT-ROUTINE-ADDR, EXIT-ROUTINE-LIST-ADDR, RETURN-VALUE, RETURN-CODE, REASON-CODE. IF RETURN-VALUE IS EQUAL TO -1 THEN DISPLAY 'ATTEMPT TO RUN COZBATCH FAILED' UPON SYSOUT DISPLAY 'RETURN-CODE=' RETURN-CODE UPON SYSOUT DISPLAY 'REASON-CODE=' REASON-CODE UPON SYSOUT END-IF CALL 'BPX1WAT' USING RETURN-VALUE, OPTIONS, ADDRESS OF STATUS, RETURN-VALUE, RETURN-CODE, REASON-CODE. I will admit the above is complicated. At least from the viewpoint of the usual z/OS COBOL programmer. The BPX1ATM routine creates a new UNIX process in the current address space. It then run the given z/OS batch program as the main routine in that process (which is a z/OS subtask). The UNIX PID value is returned in the RETURN-VALUE variable. If == -1, then something went wrong, examine RETURN-CODE and REASON-CODE to see what. Now, we need to wait for this asynchronous routine to finish. That is what BPX1WAT does. It does a UNIX wait() on the PID returned by BPX1ATM. I initialised OPTIONS to binary zeros because we don't want any options. The status return will be returned in STATUS. I am fairly sure from reading the documentation that ADDRESS OF STATUS is correct, rather than just STATUS. The RETURN-VALUE is the value from the WAIT, not from COZBATCH! It would either be 0 (wait complete) or -1 (something bad happened). If the RETURN-VALUE is ZERO, then what the COBOL program would think of as the RETURN-CODE is actually in the STATUS field. You need code somthing like the following to retrieve it. MOVE ZERO TO WORK-CODE. MOVE STATUS(3,1) TO WORK-CODE(4,1). DISPLAY "COZBATCH RETURN CODE=' WORK-CODE Of course, this reduces the RC to the range 0..255 as is normal in UNIX. Honestly, if would be much easier in HLASM or Metal-C. -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
