U23379@UICVM.BITNET (Henry Young 312-413-3626) (07/12/89)
I have a problem with a program I have written. It is called as a rexx
function. The first time the routine is called it nucxloads itself before
execution. The routine has to be in the Nucleus because it calls
SQLINIT EXEC & RXSQL MODULE. These programs load various routines into
memory (USER AND!! TRANSIENT). If I don't then when control is returned
my program aborts (it gets overwritten).
My problem now is: when control is passed back from SQLINIT EXEC I get an
operation exception (in the user area!!). Somehow control is being passed
back to a location in the user area..i.e. 208A4 even though my program
resides (should) at D000-E000. Any Ideas as to what is going on?
Note: I now call SQLINIT2 which is an exec which does a NUCXMAP and then
calls the REAl Sqlinit exec and then again does a NUCXMAP. The map says
my program is still in the Nucleus. after that the PGM dies!
Any suggestions? I have tried everything I can think of.
Thanks!,
- Henry -IJIM@UMINN1.BITNET (Jim Colten) (07/12/89)
>I have a problem with a program I have written. It is called as a rexx >function. The first time the routine is called it nucxloads itself before >execution. > . > . > . > >Thanks!, > - Henry - > Henry, Assuming that your routine is 'self nucxloading': The symptom you describe might well indicate that you are not transfering control to your nucleus extension properly. You must do so in a way that will cause it to return directly to routine that called you. A typical self nucxloading routine has the following sort of linkage chain ON THE WAY IN: 1) CMS loads your program in the user area and transfers control to it. 2) your routine nucxloads itself and transfers control to its nucxloaded self 3) the nucxloaded version does the work The second half of step 2) is where you might be going wrong. If your are simply BALRing to the nucxed code or are SVC 202ing to it, then the return path leads back through the original incarnation of your program in the user program area. That original incarnation has long ago been clobbered by the the SQL stuff your nucleus extension is calling. There is more than one way to skin this one. If you insist on being automagically self nucxloading, you must first establish your nucleus extension. Then you need to restore registers and part of the PSW (via SPM) to their state just before you received control. Then you BR to your nucleus extension. Once you have done this, you have removed your original user program area incarnation from the return path and your nucleus extension will return directly to your caller (CMS). I have a completely unsupported self nucxloader shell that was adapted from another completely unsupported piece of code that you may have for the asking. HOWEVER, I have seen another way that I prefer to the above method. If you have access to the 1987 VM Workshop tools tape (available from the University of Waterloo for a very small fee OR many local VM user groups for free), which is well worth having access to ..... Look at REXXDATE ASSEMBLE. Besides providing some very nice DATE/TIME conversion functions, REXXDATE demonstrates a nice method of handling what you need to handle. You invoke REXXDATE as a CMS MODULE. It asks CMS to NUCXLOAD a version of itself (benefiting from NUCXLOAD's ADCON relocation abilities should they be needed). Then it uses the CMS NUCEXT function to establish a number of other nucleus extentions pointing to the entry points within itself which support the functions that it provides. These nucleus extensions are named RXnnnnnn, where nnnnnn is the name used to invoke the function in your REXX programs. REXX believes that names in this form will serve external functions. REXXDATE also services PURGE and RESET service calls so that you can NUCXDROP it to get rid of the functions it provides. Good Luck, Jim Colten