Re: Which RACF/SAF profiles affect OMVS tape mounting via SVC99 with S99NOMNT=0 ?
A good starting point should be ALLOCxx member of SYS1.PARMLIB. There you might find a parameter like VOLUME_MNT POLICY(WTOR). Then ask your operating staff about how they deal with message IEF455D -- each and every tape mount is requested by this message and has to be approved by operator. I think their answer will contain the words system automation and OAM along with DFSMSrmm -- or dunno which results to same but requires that you ask system programming staff instead. Then, tape security is supported by SAF/RACF as described in chapter 6 of RACF Security Administrator Guide (SA22-7683-14). There are some flavors and it's not really easy to cope. I found a good introduction by Norbert Schlumberger on the internet, search for z/OS Tape Security with DFSMSrmm. And again that's the key word: Security in DFSMS is mainly influenced by STGADMIN profiles in RACF class FACILITY. Descriptions on these profiles are scattered around various manuals, e.g. starting at http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/DGT2BKA0;. Another central point for tape security is label processing. There are some sections regarding ICHBLP profile in the manuals. This is a RACF profile indicating MVS to bypass label processing. In short words: no label, no security. A good starting point may be again DFSMS literature or MVS JCL manuals. Cheers Michael Von:Kirk Wolf k...@dovetail.com An: IBM-MAIN@bama.ua.edu Datum: 2011-11-02 22:14 Betreff:Which RACF/SAF profiles affect OMVS tape mounting via SVC99 with S99NOMNT=0 ? Gesendet von: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Given a z/OS Unix process (OMVS address space) that uses SVC99 with S99NOMNT=0 to allocate a tape dataset, does anyone know which RACF/SAF profiles are used to limit the ability to mount tapes? I assume that TSOAUTH / MOUNT is not applicable. I saw a reference on this list to FACILITY/TAPEDEV, but I don't find it documented. (actually, the program uses BPXWDYN with MOUNT, which under the covers uses SVC99 with S99NOMNT=0) Thanks, Kirk Wolf Dovetailed Technologies http://dovetail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Which RACF/SAF profiles affect OMVS tape mounting via SVC99 with S99NOMNT=0 ?
Given a z/OS Unix process (OMVS address space) that uses SVC99 with S99NOMNT=0 to allocate a tape dataset, does anyone know which RACF/SAF profiles are used to limit the ability to mount tapes? I assume that TSOAUTH / MOUNT is not applicable. I saw a reference on this list to FACILITY/TAPEDEV, but I don't find it documented. (actually, the program uses BPXWDYN with MOUNT, which under the covers uses SVC99 with S99NOMNT=0) Thanks, Kirk Wolf Dovetailed Technologies http://dovetail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC99
Hi All, Thanks for all the comments on this issue so far. I believe this situation must have been encountered in most of the installations. Our objective is to device a solution that waits for Shared access of catalog rather than fail during allocation as it happens during the Catalog compression case. Any ideas on how to achieve this in an efficient way. Thanks, Saravanan -- 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: SVC99
On Sat, 3 May 2008 05:58:25 -0500, Saravanan J wrote: In one of our programs say XYZ, we are accessing USER catalog by dynamically allocating the Catalog using SVC 99 (in shared access mode) to get some dataset related information from the catalog. Do you really need to do that? Are you reading the catalog directly? Have you considered using CSI? -- Tom Marchant -- 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: SVC99
Edward Jaffe wrote: Paul Gilmartin wrote: Is it proper, then, to make the assumption that if two authorized programs fall into a deadlock with each other, and fail to detect or recover, a developer didn't know what he was doing, and at least one of the programs should be APARable? APAR = Authorized Program Analysis Report But, as I'm certain you know, we accept APARs for both authorized and unauthorized code. I might not have been born when this term was coined, but I'll go out on a limb to speculate that authorized meant something other than AC(1) in APAR. ;-) -- John Eells z/OS Technical Marketing IBM Poughkeepsie [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: SVC99
APAR = Authorized Program Analysis Report But, as I'm certain you know, we accept APARs for both authorized and unauthorized code. I might not have been born when this term was coined, but I'll go out on a limb to speculate that authorized meant something other than AC(1) in APAR. ;-) I know you're being facetious, but yes. It meant that sombody, within IBM, was authourised to do the analysis. When the ISC used to do tours, we were shown a video explaining the IBM support process and terminology. - Too busy driving to stop for gas! -- 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: SVC99
--snip--- Is it proper, then, to make the assumption that if two authorized programs fall into a deadlock with each other, and fail to detect or recover, a developer didn't know what he was doing, and at least one of the programs should be APARable? -unsnip--- That would depend on who developed the programs. If it's all vendor code, I'd get all the vendors involved, somehow. Otherwise, YOYO (You're On Your Own) -- 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: SVC99
snip--- May I have a go at it, too? Someone just helped me figure this out. I haven't learned how to set a trap for something like this yet to get a dump, but I imagine it isn't hard. But from an SVC dump you find the abending TCB. Then from there look at the JSCB. In the BOPTS check if the JSCBAUTH bit is on or off. If off then you are not running authorized. Is that close? -unsnip--- That's just how I'd do it, Lindy. But also look at the PSW key; keys less than 8 are also authorized. -- 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: SVC99
On Sun, 4 May 2008 09:53:18 -0500, Rick Fochtman wrote: --snip--- Is it proper, then, to make the assumption that if two authorized programs fall into a deadlock with each other, and fail to detect or recover, a developer didn't know what he was doing, and at least one of the programs should be APARable? -unsnip--- That would depend on who developed the programs. If it's all vendor code, I'd get all the vendors involved, somehow. Otherwise, YOYO (You're On Your Own) all the vendors? In the example I have in mind, the only vendor is IBM. -- gil -- 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: SVC99
At 16:23 -0500 on 05/03/2008, Tom Schmidt wrote about Re: SVC99: I suspect that the problem your program is having has less to do with the SYSDSN enqueue that S99WTDSN was designed to cope with, and more to do with the SYSVSAM enqueue that Catalog management and VSAM use for proper serialization during the catalog compression processes. I do not recall any user control over that SYSVSAM intersect via SVC99. Issuing a ENQ TYPE=TEST against SYSVSAM just before the SVC 99 would give an indication of a probable intersect problem (with the caveat that the test assumes that the ENQ status will stay the same until the SVC 99 is issued). -- 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: SVC99
On Sun, 4 May 2008 15:39:47 -0400, Robert A. Rosenberg wrote: At 16:23 -0500 on 05/03/2008, Tom Schmidt wrote about Re: SVC99: I suspect that the problem your program is having has less to do with the SYSDSN enqueue that S99WTDSN was designed to cope with, and more to do with the SYSVSAM enqueue that Catalog management and VSAM use for proper serialization during the catalog compression processes. I do not recall any user control over that SYSVSAM intersect via SVC99. Issuing a ENQ TYPE=TEST against SYSVSAM just before the SVC 99 would give an indication of a probable intersect problem (with the caveat that the test assumes that the ENQ status will stay the same until the SVC 99 is issued). I don't think that the caveat conditions will be met under the OP's circumstances. There will be intersect issues after SVC99 during OPEN as well as possible intersect issues during SVC99 processing. The catalog compression processes might well acquire/release/reacquire/re-release the various enqueues during processing, in a variable pattern depending upon the catalog's specific needs. While I'm not a big fan of WTORs in general, the process otherwise described by another poster to use WTOR multiple ECBs and a WAIT, sounds like a workaround to OP's problem. I would use the MODIFY ECB instead of WTOR. It sounds like a messy problem to have. -- Tom Schmidt -- 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: SVC99
To reconfirm again, the load module is authorised (AC=1) and we did not break the authorisation by coding STEPLIB. I found few interesting things related to wait on SVC 99 today, The program XYZ uses SVC 99 in two different places (both using the same allocation request block allocation pointer). The same program XYZ after receiving Dataset information from catalog (say for eg: USERID.TEST.DATASET in VOL123) using SVC 99 does issue an SVC 99 on USERID.TEST.DATASET at a later stage. So before executing the program XYZ, we had opened the USERID.TEST.DATASET in edit mode. So the program XYZ should have failed during SVC 99 as it had done in the case of CATALOG, instead of waiting for it. But to our surprise we found the second SVC 99 waiting to get shared access on USERID.TEST.DATASET. And when I closed the dataset opened in edit mode, the job ran fine to completion. Any thoughts on why SVC 99 does not for CATALOG alone? -- 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: SVC99
I think Tom Schmidt has already given the reason for SVC 99 wait failure due to SYSVSAM. And my previous message proves the fact that SVC 99 wait works fine with SYSDSN only. -- 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
SVC99
Hi, In one of our programs say XYZ, we are accessing USER catalog by dynamically allocating the Catalog using SVC 99 (in shared access mode) to get some dataset related information from the catalog. Before this dynamic allocation we are actually turning-on all the wait bits (S99WTVOL+S99WTDSN+S99WTUNT+S99OFFLN) in S99FLG21 byte. So far so good, but we seem to be getting allocation failures on the catalog in our program XYZ, whenever our catalog compression jobs are running (Catalog compress jobs have exclusive ENQ on the catalog during compress). As per our understanding, the dynamic allocation in XYZ program should wait for the shared access of Catalog as the catalog is locked for exclusive use by Catalog compression jobs. And since the DSN is unavailable to our program XYZ, it should wait for the DSN till the catalog compress job releases the exclusive lock on catalog. Any pointers to why the S99FLG21 wait bits are not working would be of great help to us? We also have CA-MIM would this cause any effect on the catalog allocation. Thanks Regards, Saravanan -- 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: SVC99
Are you running authorized? The FM states: Requesting a Data Set That Is In Use: Rather than wait for another user to release a data set, volume, or device to obtain use of it, dynamic allocation fails a request by an unauthorized program. If an authorized program specifically requests a wait, dynamic allocation will wait. Date: Sat, 3 May 2008 05:58:25 -0500 From: [EMAIL PROTECTED] Subject: SVC99 To: IBM-MAIN@BAMA.UA.EDU Hi, In one of our programs say XYZ, we are accessing USER catalog by dynamically allocating the Catalog using SVC 99 (in shared access mode) to get some dataset related information from the catalog. Before this dynamic allocation we are actually turning-on all the wait bits (S99WTVOL+S99WTDSN+S99WTUNT+S99OFFLN) in S99FLG21 byte. So far so good, but we seem to be getting allocation failures on the catalog in our program XYZ, whenever our catalog compression jobs are running (Catalog compress jobs have exclusive ENQ on the catalog during compress). As per our understanding, the dynamic allocation in XYZ program should wait for the shared access of Catalog as the catalog is locked for exclusive use by Catalog compression jobs. And since the DSN is unavailable to our program XYZ, it should wait for the DSN till the catalog compress job releases the exclusive lock on catalog. Any pointers to why the S99FLG21 wait bits are not working would be of great help to us? We also have CA-MIM would this cause any effect on the catalog allocation. Thanks Regards, Saravanan _ With Windows Live for mobile, your contacts travel with you. http://www.windowslive.com/mobile/overview.html?ocid=TXT_TAGLM_WL_Refresh_mobile_052008 -- 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: SVC99
On Sat, 3 May 2008 07:28:43 -0400, J R wrote: Requesting a Data Set That Is In Use: Rather than wait for another user to release a data set, volume, or device to obtain use of it, dynamic allocation fails a request by an unauthorized program. ... I've long wondered why. Is there some particular integrity or security hazard associated with a program's waiting for another user to release a data set? -- gil -- 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: SVC99
Probably to ensure that not just anybody can cause a deadly embrace: S99WTVOL / S99WTDSN / S99WTUNT / S99OFFLN / S99MOUNT : Use care when you set these flags; setting any one of them might cause a deadlock situation. For example, consider the situation where JOBA owns a resource that JOBB wants and JOBB owns a resource that JOBA wants. If one of the above flags are on, the two jobs will wait until one job is cancelled. Date: Sat, 3 May 2008 11:12:23 -0500 From: [EMAIL PROTECTED] Subject: Re: SVC99 To: IBM-MAIN@BAMA.UA.EDU On Sat, 3 May 2008 07:28:43 -0400, J R wrote: Requesting a Data Set That Is In Use: Rather than wait for another user to release a data set, volume, or device to obtain use of it, dynamic allocation fails a request by an unauthorized program. ... I've long wondered why. Is there some particular integrity or security hazard associated with a program's waiting for another user to release a data set? -- gil _ Make Windows Vista more reliable and secure with Windows Vista Service Pack 1. http://www.windowsvista.com/SP1?WT.mc_id=hotmailvistasp1banner -- 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: SVC99
Yes the program is authorised. -- 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: SVC99
On Sat, 3 May 2008 12:23:37 -0400, J R wrote: Probably to ensure that not just anybody can cause a deadly embrace: Why is a deadly embrace caused by an authorized program deemed less harmful than one caused by an unauthorized program? S99WTVOL / S99WTDSN / S99WTUNT / S99OFFLN / S99MOUNT : Use care when you set these flags; setting any one of them might cause a deadlock situation. For example, consider the situation where JOBA owns a resource that JOBB wants and JOBB owns a resource that JOBA wants. If one of the above flags are on, the two jobs will wait until one job is cancelled. -- gil -- 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: SVC99
Why is a deadly embrace caused by an authorized program deemed less harmful than one caused by an unauthorized program? I suspect you know that's not what I meant. I think the assumption is that, if you are writing authorized code, you know what you are doing and will take precautions to avoid deadlocks or detect and recover from them. Date: Sat, 3 May 2008 11:36:07 -0500 From: [EMAIL PROTECTED] Subject: Re: SVC99 To: IBM-MAIN@BAMA.UA.EDU On Sat, 3 May 2008 12:23:37 -0400, J R wrote: Probably to ensure that not just anybody can cause a deadly embrace: Why is a deadly embrace caused by an authorized program deemed less harmful than one caused by an unauthorized program? S99WTVOL / S99WTDSN / S99WTUNT / S99OFFLN / S99MOUNT : Use care when you set these flags; setting any one of them might cause a deadlock situation. For example, consider the situation where JOBA owns a resource that JOBB wants and JOBB owns a resource that JOBA wants. If one of the above flags are on, the two jobs will wait until one job is cancelled. -- gil _ Get Free (PRODUCT) RED™ Emoticons, Winks and Display Pics. http://joinred.spaces.live.com?ocid=TXT_HMTG_prodredemoticons_052008 -- 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: SVC99
That doesn't answer my question. Date: Sat, 3 May 2008 11:34:25 -0500 From: [EMAIL PROTECTED] Subject: Re: SVC99 To: IBM-MAIN@BAMA.UA.EDU Yes the program is authorised. _ Make Windows Vista more reliable and secure with Windows Vista Service Pack 1. http://www.windowsvista.com/SP1?WT.mc_id=hotmailvistasp1banner -- 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: SVC99
On Sat, 3 May 2008 14:17:44 -0400, J R wrote: That doesn't answer my question. I know this one! I.e. the program may have been bound with AC=1, but into a non-authorized library; or it may have been invoked by CALL, LINK, ATTACH, or XCTL from a non-authorized parent; or there may have been a non-authorized STEPLIB catenand; any of which would cause it to run non-authorized. (Others?) Date: Sat, 3 May 2008 11:34:25 -0500 From: [EMAIL PROTECTED] Yes the program is authorised. -- gil -- 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: SVC99
On Sat, 3 May 2008 14:14:02 -0400, J R wrote: Why is a deadly embrace caused by an authorized program deemed less harmful than one caused by an unauthorized program? I suspect you know that's not what I meant. I think the assumption is that, if you are writing authorized code, you know what you are doing and will take precautions to avoid deadlocks or detect and recover from them. Is it proper, then, to make the assumption that if two authorized programs fall into a deadlock with each other, and fail to detect or recover, a developer didn't know what he was doing, and at least one of the programs should be APARable? -- gil -- 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: SVC99
Paul Gilmartin wrote: Is it proper, then, to make the assumption that if two authorized programs fall into a deadlock with each other, and fail to detect or recover, a developer didn't know what he was doing, and at least one of the programs should be APARable? APAR = Authorized Program Analysis Report -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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: SVC99
May I have a go at it, too? Someone just helped me figure this out. I haven't learned how to set a trap for something like this yet to get a dump, but I imagine it isn't hard. But from an SVC dump you find the abending TCB. Then from there look at the JSCB. In the BOPTS check if the JSCBAUTH bit is on or off. If off then you are not running authorized. Is that close? Lindy -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: 3. toukokuuta 2008 22:22 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SVC99 On Sat, 3 May 2008 14:17:44 -0400, J R wrote: That doesn't answer my question. I know this one! I.e. the program may have been bound with AC=1, but into a non-authorized library; or it may have been invoked by CALL, LINK, ATTACH, or XCTL from a non-authorized parent; or there may have been a non-authorized STEPLIB catenand; any of which would cause it to run non-authorized. (Others?) Date: Sat, 3 May 2008 11:34:25 -0500 From: [EMAIL PROTECTED] Yes the program is authorised. -- gil -- 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: SVC99
On Sat, 3 May 2008 05:58:25 -0500, Saravanan J wrote: In one of our programs say XYZ, we are accessing USER catalog by dynamically allocating the Catalog using SVC 99 (in shared access mode) to get some dataset related information from the catalog. Before this dynamic allocation we are actually turning-on all the wait bits (S99WTVOL+S99WTDSN+S99WTUNT+S99OFFLN) in S99FLG21 byte. So far so good, but we seem to be getting allocation failures on the catalog in our program XYZ, whenever our catalog compression jobs are running (Catalog compress jobs have exclusive ENQ on the catalog during compress). As per our understanding, the dynamic allocation in XYZ program should wait for the shared access of Catalog as the catalog is locked for exclusive use by Catalog compression jobs. And since the DSN is unavailable to our program XYZ, it should wait for the DSN till the catalog compress job releases the exclusive lock on catalog. Any pointers to why the S99FLG21 wait bits are not working would be of great help to us? I suspect that the problem your program is having has less to do with the SYSDSN enqueue that S99WTDSN was designed to cope with, and more to do with the SYSVSAM enqueue that Catalog management and VSAM use for proper serialization during the catalog compression processes. I do not recall any user control over that SYSVSAM intersect via SVC99. -- Tom Schmidt -- 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: SVC99
At 05:58 -0500 on 05/03/2008, Saravanan J wrote about SVC99: As per our understanding, the dynamic allocation in XYZ program should wait for the shared access of Catalog as the catalog is locked for exclusive use by Catalog compression jobs. And since the DSN is unavailable to our program XYZ, it should wait for the DSN till the catalog compress job releases the exclusive lock on catalog. If for some reason you can not get it to work why not issue a WTOR stating that the SVC99 failed, do a timed wait on a 2nd ECB and wait on both the WTOR and STIMER ECBs. If the WTOR gets responded to, TTIMER and quit the program. The STIMER ECB getting posted would trigger a DOM of the WTOR and a retry of the SVC99. This will be the equivalent of the SVC99 wait (except for you not being on the ENQ queue and thus subject to having another EXC-ENQ getting issued during your waiting period). I KNOW that this does not answer your question but it does provide a work around of the issue. -- 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
SVC99 and MPF Exits
Any restrictions for using dynamic allocation in an MFS user exit? -- 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
SVC99 and MPF exits
Any restrictions for using dynamic allocation (SVC99)in MPF exits? -- 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: SVC99 and MPF Exits
2.9.4.2 Macro Instructions and Restrictions IEAVMXIT and MPF exit routines can issue system macros, but you should be aware of the following restrictions: a.. Do not install an exit routine that issues the WAIT macro or calls a service that issues a WAIT. WAITs and implied WAITs can terminate console communications. - Original Message - From: Rich Tabor [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Tuesday, March 13, 2007 3:56 PM Subject: SVC99 and MPF Exits Any restrictions for using dynamic allocation in an MFS user exit? -- 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: SVC99 and MPF Exits
2.9.4.2 Macro Instructions and Restrictions IEAVMXIT and MPF exit routines can issue system macros, but you should be aware of the following restrictions: a.. Do not install an exit routine that issues the WAIT macro or calls a service that issues a WAIT. WAITs and implied WAITs can terminate console communications. Allocation certainly falls into one of those potential black-hole categories that would violate the intent of the above warning. But even if it did not, you would have to consider the state of the work that is being interrupted by the exit. It is a bad idea in general to introduce new allocations to any address space without really understanding the environment where you're running. You can royally hose things up without even trying. If you do find yourself needing to do out of band I/O from an exit then you probably need to set up some sort of server space to take care of that for you. Aside from anything else, the avoidance of dynamic allocation would make the whole thing run a whole lot faster and your recovery considerations would be much easier to deal with. CC -- 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
