STELIOS@GRCRUN11.BITNET (Stelios Fragakis) (08/30/90)
On SC24-5284-0 (CMS Macros and Functios References) page 73, note 7 says:
7. It is your responsibility to issue a HNDEXT CLR in the application that
issued a HNDEXT SET,address. Under certain environments, no
cleanup is performed by DMSINT after the execution of the program.
My question is whats the "certain" enviroment mentioned above. I want to be
able to keep the HNDEXT active for a while (say 4 minutes) after the program
has terminated. Any danger on that ?
- SteliosRZA31LH@DB0ADW11.BITNET (Lutz Hamann) (08/31/90)
On Thu, 30 Aug 90 09:36:59 LCL Stelios Fragakis said: >On SC24-5284-0 (CMS Macros and Functios References) page 73, note 7 says: > >7. It is your responsibility to issue a HNDEXT CLR in the application that > issued a HNDEXT SET,address. Under certain environments, no > cleanup is performed by DMSINT after the execution of the program. > For instance, when you terminate the programm using 'HX'. On our computer the interrupt-handling routine is in this case still active (but we have an early release of VM/SP, may be not 100% compatible with the IBM-Original). >My question is whats the "certain" enviroment mentioned above. I want to be >able to keep the HNDEXT active for a while (say 4 minutes) after the program >has terminated. Any danger on that ? > It depends on what you will do in this 4 minutes or where the interrupt- handling routine was loaded. If it was nearby address x'20000', than better do nothing (no xedit, no call of user-programs). If it is a nucleus extention, it should work (if the extention was not dropped). Bye Lutz P.S. Question please only through the list (we're not yet in the BITEARN NODES)
KXH105@PSUVM.BITNET ("Ken Hornstein 862-7007", 814) (02/20/91)
Hi. I've written some code that I'm sending to other sites, but I'm running
into a problem with my use of the HNDEXT macro. What I'm currently doing is
this:
HNDEXT SET,(R4)
Which works fine on our ESA system, XA systems, and some other CMS systems.
But other sites generate a P-list which looks like this:
DC CL8'TRAP'
DC A((R4))
Which isn't what I want to do at all :-( I've tried using the MF=L form,
but it seems like the sites that generate the lousy P-lists also don't
recognize MF=L as a valid parameter. I'd hard-code the P-list myself,
except that XA uses something else to trap externals instead of TRAP, and I'd
like to use it also.
Any suggestions? Do I just have to send people an update file with a fix,
or is there a way to make this assemble at all sites without any changes?
Thanks!
---
Build a system that even a fool can use and only a fool will want to use it.
Ken Hornstein kxh105@psuvm.psu.edu Phone: 814/862-7007FERZAN@TREARN.BITNET (OR) (02/20/91)
IF YOU WANT TO USE YOUR EXTERNAL INTERRUPT ROUTINE,
YOU CAN USE DIRECTLY EXTOPSW AND EXTNPSW,
THIS WAY RUNS AT ALL S/370 BASED SYSTEMSnews@ucf1vm.BITNET (02/21/91)
I know that this may sound dumb, but try using (4) instead of (R4); I have found that this works with SOME of the IBM macros.
VSLAWR@WEIZMANN.BITNET ("Lawrence S. Kalman") (02/21/91)
On Wed, 20 Feb 91 00:35:00 EST Ken Hornstein (814) 862-7007 said: >Hi. I've written some code that I'm sending to other sites, but I'm running >into a problem with my use of the HNDEXT macro. What I'm currently doing is >this: > > HNDEXT SET,(R4) > >Which works fine on our ESA system, XA systems, and some other CMS systems. >But other sites generate a P-list which looks like this: > > DC CL8'TRAP' > DC A((R4)) You have encountered the thorny problem of incompatibility between systems. The valid format of the HNDEXT macro in CMS 5 and earlier releases (I can't speak for CMS 6) is much more restrictive, as it provides only HNDEXT SET,address or HNDEXT CLR and <address> must be a reference to storage. (Note that it could be an external reference.) There is no provision for register specification of the address, list and execute forms, or any of the other goodies provided in CMS 5.6. Assuming that the address in R4 is dynamically obtained, you are caught between a rock and a hard place. You have to resort to what is known as "dual pathing". This can be done either at the source or execution level. If at the source level, you will want to insert conditional assembly statements which will cause the selection of the appropriate statements based on the level of CMS. If at the execution level, you can determine under which level of CMS the program is running (see the CMSLEVEL macro - the value is stored at CMSPROG in NUCON) and execute one of two paths accordingly. Of course, either choice requires access to the documentation and the ability to test on all the systems for which you want to provide support ;-(. - Lawrence