Charles Lester <[EMAIL PROTECTED]> writes: > We've got an MVS application (LE C++, calling assembler which cares > nothing about LE), executing out of MVS datasets in the STEPLIB, which > we're modifying, so that the assembler now calls some LE C++ code that > uses a DLL which sits over in USS-land. We've successfully gotten the > assembler to make the LE C++ callee think it was called from a pure LE > caller (a little, but Vendor Interfaces-approved, slight of hand here > :-)), but now we're trying to figure out how to combine STEPLIBs with > MVS PDSEs with a PATH expression to where the DLL lives.
The LE C++ code that is _called_ by the assembler seems to be the critical point here. I'll call it BAR. I'll call the DLL which BAR references CUSP. I'll call the target dataset for BAR and CUSP JGROUT.LOAD (a PDSE that contains program objects) and the target dataset for side decks JGROUT.EXP (a standard 80-byte FB PDS or PDSE). Step I - Creating the CUSP program object and side deck Technique A. Bind in USS and copy out If you can give the DLL a PDSE member name (one to eight characters, all letters uppercase) in USS, you can copy it to batch with the same name without rebinding it (this works because the IMPORT statements in the side deck will have the correct DLL name). In my example, if you are in the USS directory containing the DLL (CUSP) and its side deck (CUSP.x), do the following: cp -X CUSP "//'jgrout.load(cusp)'" cp -B CUSP.x "//'jgrout.exp(cusp)'" Technique B. Rebind in batch I think this is what you're already doing. When you rebind the DLL into a PDSE member named CUSP, you would point DDNAME SYSLMOD at JGROUT.LOAD, point DDNAME SYSDEFSD at JGROUT.EXP(CUSP), bring in the DLL with an INCLUDE in SYSLIN and name the rebound DLL CUSP with a NAME CUSP(R) statement. Step II - Creating the BAR program object The description below assumes that no one tries to explicitly load CUSP... including BAR... and that BAR does not use the DLL API to call functions in CUSP. When you bind BAR, you need to include JGROUT.EXP(CUSP) in SYSLIN. A simple INCLUDE statement pointing at this is fine. I am assuming that BAR references CUSP directly, which will create references that must be resolved when BAR is bound. To check this, specify the LIST option to the binder and search for CUSP. You should find each function or variable imported from CUSP to resolve a reference named in a table of imported symbols. This table reflects how LE looks at the world... it doesn't care _WHERE_ a DLL is at run-time... all it cares about is its name (in my example, the name is CUSP). If you have an unresolved reference, check JGROUT.EXP(CUSP). It may be that the function you are trying to call was never exported... if so, that has to be fixed in USS land. If the DLL was originally designed for Unix, this is not all that unlikely (see the C/C++ manuals for the details on pragmas, attributes and compiler options that mark functions and variable for export). You can demangle long mangled names named at the end of the binder listing or in the side deck using CXXFILT (see the C/C++ User's Guide for details). Step III - Runtime If BAR was bound with no unresolved references to CUSP and JGROUT.LOAD is in JOBLIB/STEPLIB, at some point between when BAR is loaded from JGROUT.LOAD and when BAR first tries to invoke a function in CUSP, LE will load CUSP from JGROUT.LOAD. -- John R. Grout [EMAIL PROTECTED] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
