Mike, Since I surmise that the supplied assembler module isn't your own code, you are going to have to write an "interface module" between the REXX program and the "bespoke database" module.
Your "interface module" should use one of the techniques others have described (I prefer the "name/token" method myself) to retain the data returned by the vendor-supplied routine in "working storage" as it were, as well as the address of the supplied module. The "name/token" service will allow you to getmain some storage for the arguments and remember the address of that storage in the "name/token" area. It will also allow you to load the supplied module and to remember its address in the getmained storage. Sketchy preliminary logic sample, customize as you need: 1. Use name/token services to retrieve unique name. 2. Name doesn't exist, getmain enough storage for working area and store address in new unique name/token. Also load vendor-supplied assembler routine and store module address in gotten storage. 3. Name exists, retrieve getmain address from token and module address from gotten storage. 4. Call assembler routine using the module address, with parameters as appropriate. 5. If this was a "CLOSE" call, delete the assembler module, free the getmained storage and delete the unique name/token. Alternatively of course, you could require the database vendor to supply a REXX-friendly interface module so they have to do the coding instead of you... :) IMHO, it's quite sloppy coding practice for someone to supply you with a module that depends on values retained in their program between calls. HTH Peter > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Michael Munro > Sent: Monday, September 22, 2008 5:21 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Calling Assembler module from REXX > > Hi > I am trying to help a REXX programmer with a CALL to an > Assembler routine. > > I can LINK to an assembler routine successfully, but I > cannot make successive calls. The Address LINKMVS feature (as its name > suggests) loads in a fresh version of the module on each invocation > thereby clearing any values saved from previous CALLs. > > The module to be called is an interface supplied to OPEN > READ and CLOSE a bespoke database. Because of the technique I am > using the first call opens OK, but the second call to read a record fails > because the database is not open (or so it thinks because the re-loaded > module has lost its "open" indicator). > > Any ideas please. > Mike This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- 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
