DLLs and STEPLIBs
Charles Lester asked about combining traditional MVS steplib data sets with HFS directories in a STEPLIB DD, which would allow DLLs to come from either data sets or files. This is a known requirement. The problem is that the result of STEPLIB processing is the output from BLDL, which can quickly be searched to find the program being requested. BLDL works directly against the concatenated DD statements in the STEPLIB. If Contents Supervisor (CSV) were to allow the intermingling of data sets and directories, it would require a significant rewriting of the CSV component. When a mix of data sets and directories are present, it would require the STEPLIB DD to be disected to determine if there were any PATH= specifications. Then it would require an independent search of each data set or directory to locate the module. Performance would be impacted. Since USS propagates STEPLIBs on fork, spawn and exec, it would also impact this USS code. There are also potentially customer and vendor code that poke around the TIOT and other control blocks when examining the STEPLIB. At the present time, we are not considering implementing this support. It would likely require a SHARE requirement with high interest to get us to look at it again. Don Ault, 8-295-1750, 845-435-1750 -- 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
Re: DLLs and STEPLIBs
In a recent note, Don Ault said: Date: Thu, 9 Feb 2006 07:27:47 -0500 This is a known requirement. The problem is that the result of STEPLIB processing is the output from BLDL, which can quickly be searched to find the program being requested. BLDL works directly against the concatenated DD statements in the STEPLIB. If Contents Supervisor (CSV) were to allow the intermingling of data sets and directories, it would require a significant rewriting of the CSV component. When a mix of data sets and directories are present, it would require the STEPLIB DD to be disected to determine if there were any PATH= specifications. ??? It's my understanding that as of z/OS 1.5 BPAM using BLDL (but ironically not DESERV) handles mixed concatenations of Classic and HFS directories transparently (note revision bars): # 1.1.2.2 z/OS V1R5.0 DFSMS: Using Data Sets _ 1.1.2.2 Basic Partitioned Access Method | Basic partitioned access method (BPAM) arranges records as members of a | partitioned data set (PDS) or a partitioned data set extended (PDSE) on | DASD. You can use BPAM to view a UNIX directory and its files as if it | were a PDS. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: DLLs and STEPLIBs
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
Re: DLLs and STEPLIBs
In [EMAIL PROTECTED], on 02/07/2006 at 12:16 PM, Lester, Charles (LNG-DAY) [EMAIL PROTECTED] said: I'm posting to the Assembler list because I mention assembler several times in this message :-) Cross-posting to IBM-MAIN. uses a DLL which sits over in USS-land. uses a DLL which sits over in USS-land. ITYM Unix-land. USS is something quite different. but now we're trying to figure out how to combine STEPLIBs with MVS PDSEs with a PATH expression to where the DLL lives. AFAIK the STEPLIB DD is restricted to PDS and PDSE, There are Unix commands to dynamically extend the STEPLIB, and those do support Unix files. All the examples I can find never mix the two types of program object libraries in an execution environment. We get: IEF689I JOB FAILED STEPLIB DID NOT OPEN. if we try to put the PATH statement into the STEPLIB concatenation. That's what I would expect. Putting the new program object (PO) into the USS library would be ugly, What are you trying to say? If the program object is in a PDSE then you can include that PDSE in STEPLIB. If you don't want it in a Unix file then why would you care that you can't concatenate a Unix file? Anybody have any suggestions? Use the Unix steplib facility if you can't put the DLL in a PDSE. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patr -- Shmuel (Seymour J.) Metz, SysPro iot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
DLLs and STEPLIBs
I'm posting to the Assembler list because I mention assembler several times in this message :-) Cross-posting to IBM-MAIN. I've looked thru the archives and manuals and some SHARE presentations, and can't seem to find the answer to this one. 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. All the examples I can find never mix the two types of program object libraries in an execution environment. We get: IEF689I JOB FAILED STEPLIB DID NOT OPEN. if we try to put the PATH statement into the STEPLIB concatenation. Putting the new program object (PO) into the USS library would be ugly, because this PO is only one of many PO being called when the job step runs. Anybody have any suggestions? -- 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
Re: DLLs and STEPLIBs
On Tue, 7 Feb 2006 12:16:49 -0500, Lester, Charles (LNG-DAY) [EMAIL PROTECTED] wrote: I'm posting to the Assembler list because I mention assembler several times in this message :-) Cross-posting to IBM-MAIN. I've looked thru the archives and manuals and some SHARE presentations, and can't seem to find the answer to this one. 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. All the examples I can find never mix the two types of program object libraries in an execution environment. We get: IEF689I JOB FAILED STEPLIB DID NOT OPEN. if we try to put the PATH statement into the STEPLIB concatenation. Putting the new program object (PO) into the USS library would be ugly, because this PO is only one of many PO being called when the job step runs. Anybody have any suggestions? Maybe I'm wrong but can not DLL's reside in MVS datasets as well as USS files -- 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
Re: DLLs and STEPLIBs
Lester, Charles (LNG-DAY) wrote: I'm posting to the Assembler list because I mention assembler several times in this message :-) Cross-posting to IBM-MAIN. I've looked thru the archives and manuals and some SHARE presentations, and can't seem to find the answer to this one. 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. All the examples I can find never mix the two types of program object libraries in an execution environment. We get: IEF689I JOB FAILED STEPLIB DID NOT OPEN. if we try to put the PATH statement into the STEPLIB concatenation. Putting the new program object (PO) into the USS library would be ugly, because this PO is only one of many PO being called when the job step runs. Anybody have any suggestions? Well, you're right that the two don't mix. STEPLIBs must be PDS/Es, and PATH is used for DLLs. Hmmm. Can you move the DLLs into your STEPLIB and set up PATH to point to the STEPLIB? Kind regards, -Steve Comstock -- 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
Re: DLLs and STEPLIBs
As has been suggested earlier, you can place DLLs into PDSEs - I have done this. There may be structural differences, one DLL becomes one PDSE containing many seperate program objects (one PDSE = one DLL). I have never created DLLs under USS, so I do not know exactly how they are organised here except I believe they are in one file. HTH Julian Subject: DLLs and STEPLIBs I'm posting to the Assembler list because I mention assembler several times in this message :-) Cross-posting to IBM-MAIN. I've looked thru the archives and manuals and some SHARE presentations, and can't seem to find the answer to this one. 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. All the examples I can find never mix the two types of program object libraries in an execution environment. We get: IEF689I JOB FAILED STEPLIB DID NOT OPEN. if we try to put the PATH statement into the STEPLIB concatenation. Putting the new program object (PO) into the USS library would be ugly, because this PO is only one of many PO being called when the job step runs. Anybody have any suggestions? -- 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 Try Capscan's new online bureau at http://www.capscanintegrity.com * Matchcode International Best International Product at IDMF * *** This e-mail is confidential and intended solely for the use of the individual to whom it was addressed. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. Please delete any copies you may have, on any computer. Any views expressed in this message are those of the individual sender and do not necessarily represent the views of Capscan Ltd and/or its subsidiaries. Please be aware that Internet communications are not secure. Capscan Limited Head Office: Capscan Limited Grand Union House 20 Kentish Town Road London NW1 9BB Registered in England no. 1183941 *** -- 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
Re: DLLs and STEPLIBs
Steve Comstock [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Thanks, Steve.
I've thought of that, not so ugly as going the other way, but then I've
got to get the application to find the DLL in the STEPLIB, and right now
it's looking for a name that is longer than 8 characters, with a .dll
extension on the end :-)
I could write a program to stuff the name it's expecting into the PDSE
as an alias (I had one about 5 years ago), but that's going to take a
couple of hours I don't have ('ees not my dog :-) long story)
Well, you're right that the two don't mix. STEPLIBs must be PDS/Es,
and
PATH is used for DLLs. Hmmm. Can you move the DLLs into your STEPLIB
and
set up PATH to point to the STEPLIB?
Kind regards,
-Steve Comstock
--
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
--
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
Re: DLLs and STEPLIBs
Cross posting to assembler-list
Results so far:
(1) Copied to PDSE using a generic name using the OGETX functionnada
(2) Re-bound from the USS library into the PDSE using the HFS file as
input, with the following binder options
ALIASES=ALL,CASE=MIXED,DYNAM=DLL,COMPAT=PM3, and the PDSE file as output
(again, with a generic 8-character name), with an ALIAS control card
specifying the real name of the DLL...again, nada
Nada==We get an abend that indicates it never found the address of the
function call in the DLL (S0C1 with R14 pointing to the point in the C++
callee where it tries to invoke the function in the DLL), which makes us
think it didn't properly find the DLL.
Lester, Charles (LNG-DAY) [EMAIL PROTECTED] wrote in
message
news:[EMAIL PROTECTED]
.net...
Steve Comstock [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Thanks, Steve.
I've thought of that, not so ugly as going the other way, but then
I've
got to get the application to find the DLL in the STEPLIB, and right
now
it's looking for a name that is longer than 8 characters, with a
.dll
extension on the end :-)
I could write a program to stuff the name it's expecting into the PDSE
as an alias (I had one about 5 years ago), but that's going to take a
couple of hours I don't have ('ees not my dog :-) long story)
Well, you're right that the two don't mix. STEPLIBs must be PDS/Es,
and
PATH is used for DLLs. Hmmm. Can you move the DLLs into your STEPLIB
and
set up PATH to point to the STEPLIB?
Kind regards,
-Steve Comstock
--
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
--
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
--
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
Re: DLLs and STEPLIBs
STEPLIBs must be PDS/Es
They can also be PDS datasets.
Or, is that what you're trying to say with the /?
Remember:
The purpose of communication is not to ensure you're understood.
It's to ensure that you ARE NOT misunderstood.
(8{]}
-
-teD
I’m an enthusiastic proselytiser of the universal panacea I believe in!
--
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
Re: DLLs and STEPLIBs
Results so far: (1) Copied to PDSE using a generic name using the OGETX functionnada (2) Re-bound from the USS library into the PDSE using the HFS file as input, with the following binder options ALIASES=ALL,CASE=MIXED,DYNAM=DLL,COMPAT=PM3, and the PDSE file as output (again, with a generic 8-character name), with an ALIAS control card specifying the real name of the DLL...again, nada Nada==We get an abend that indicates it never found the address of the function call in the DLL (S0C1 with R14 pointing to the point in the C++ callee where it tries to invoke the function in the DLL), which makes us think it didn't properly find the DLL. I don't know of any obvious reason why this wouldn't work. Did you have the import/export control file (ahem) stuff allocated? -- 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
