Best practices for SMF exit routines
As those of you following my IEFU8x thread know, I've just taken over responsibility for some IEFU8x code. It needs some serious re-writing and while I've got a lot of 360 to Z experience, this is my first SMF exit, so I'd like to tap the collective wisdom of the group. - What's the best way for the IEFU8x code to "find" its companion non-exit code? In the current code the non-exit module defines itself as a subsystem, anchors a table in SSCTSUSE, and then the IEFU83 exit scans the SSCT to find it by name. Is this recommended, or is there a better way? - What's the best way to parametize an IEFU8x exit? The existing code has a customization utility named AMASPZAP . I obviously can't read a parameter file. It can't get the information from the SSCT technique described above because the sub-system name is one of the things that needs to be parametized. What do people recommend? - What's the best way for the IEFU8x code to pass messages to its companion non-exit code? The current code uses GETMAIN SP=241, CS, and an x-memory POST. It looks pretty good to me but is there a more recommended way? Thanks all. Note this code is all working so I don't need advice on getting any of the above-mentioned techniques to work (although pointing out very subtle gotchas is always helpful). I really want to know the best way to accomplish these things, big picture. Charles Mills -- 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: Best practices for SMF exit routines
On 7/19/2010 3:45 PM, Charles Mills wrote: As those of you following my IEFU8x thread know, I've just taken over responsibility for some IEFU8x code. It needs some serious re-writing and while I've got a lot of 360 to Z experience, this is my first SMF exit, so I'd like to tap the collective wisdom of the group. - What's the best way for the IEFU8x code to "find" its companion non-exit code? In the current code the non-exit module defines itself as a subsystem, anchors a table in SSCTSUSE, and then the IEFU83 exit scans the SSCT to find it by name. Is this recommended, or is there a better way? Not a big SMF exit expert , but would suggest the NAMET/TOKEN services - What's the best way to parametize an IEFU8x exit? The existing code has a customization utility named AMASPZAP. I obviously can't read a parameter file. It can't get the information from the SSCT technique described above because the sub-system name is one of the things that needs to be parametized. What do people recommend? - What's the best way for the IEFU8x code to pass messages to its companion non-exit code? The current code uses GETMAIN SP=241, CS, and an x-memory POST. It looks pretty good to me but is there a more recommended way? What do you mean about the "companion non-exit code " ? Thanks all. Note this code is all working so I don't need advice on getting any of the above-mentioned techniques to work (although pointing out very subtle gotchas is always helpful). I really want to know the best way to accomplish these things, big picture. Charles Mills -- 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
Re: Best practices for SMF exit routines
Suggestions/opinions in-stream (by no means an exhaustive or definitive list) : >>Q : What's the best way for the IEFU8x code to "find" its companion non-exit code? In the current code the non-exit module defines itself as a subsystem, anchors a table in SSCTSUSE, and then the IEFU83 exit scans the SSCT to find it by name. Is this recommended, or is there a better way? Using the SSCTSUSE field is a reasonable solution. Other alternatives include a system level name/token or an anchor in the "customer table" that hangs off the ECVT (you will need to reserve a slot from IBM). Do *not* use CVTUSER. >>Q : - What's the best way to parametize an IEFU8x exit? The existing code has >>a customization utility named AMASPZAP . I obviously can't read a parameter file. It can't get the information from the SSCT technique described above because the sub-system name is one of the things that needs to be parametized. What do people recommend? Store an anchor in the name/token or customer slot (see above) - options are set by your "server" code PARMLIB statements. If using the name/token, then the "name" can be fixed (rather than the variable style SSCT name format). If you are using the customer slot then you will have a fixed sequence of instructions to locate your anchor (v.fast). >>Q : - - What's the best way for the IEFU8x code to pass messages to its >>companion non-exit code? The current code uses GETMAIN SP=241, CS, and an x-memory POST. It looks pretty good to me but is there a more recommended way? Alternatives include : (a) PC-ss to your server to add elements to tail of pending message queue (PLO is handy instruction here), server task then drains the queue head-to-tail to write them out. The "Pending message" structure can then be private storage from the server rather than E-CSA. (b) Use a common dataspace and put its ALET in your anchor block and then flip into AR mode in IEFU8x to add messages to queue. You will probably need to write a RESMGR for your server to cleanup the anchored blocks and set/unset flags to protect users from processing status changes and user-inflicted server terminations. Rob Scott Lead Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Charles Mills Sent: 19 July 2010 14:45 To: IBM-MAIN@bama.ua.edu Subject: Best practices for SMF exit routines As those of you following my IEFU8x thread know, I've just taken over responsibility for some IEFU8x code. It needs some serious re-writing and while I've got a lot of 360 to Z experience, this is my first SMF exit, so I'd like to tap the collective wisdom of the group. - What's the best way for the IEFU8x code to "find" its companion non-exit code? In the current code the non-exit module defines itself as a subsystem, anchors a table in SSCTSUSE, and then the IEFU83 exit scans the SSCT to find it by name. Is this recommended, or is there a better way? - What's the best way to parametize an IEFU8x exit? The existing code has a customization utility named AMASPZAP . I obviously can't read a parameter file. It can't get the information from the SSCT technique described above because the sub-system name is one of the things that needs to be parametized. What do people recommend? - What's the best way for the IEFU8x code to pass messages to its companion non-exit code? The current code uses GETMAIN SP=241, CS, and an x-memory POST. It looks pretty good to me but is there a more recommended way? Thanks all. Note this code is all working so I don't need advice on getting any of the above-mentioned techniques to work (although pointing out very subtle gotchas is always helpful). I really want to know the best way to accomplish these things, big picture. Charles Mills -- 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
Re: Best practices for SMF exit routines
Are you a vendor or is this for your site? The vendor answer is more complicated. On Mon, 19 Jul 2010 06:45:24 -0700 Charles Mills wrote: :>As those of you following my IEFU8x thread know, I've just taken over :>responsibility for some IEFU8x code. It needs some serious re-writing and :>while I've got a lot of 360 to Z experience, this is my first SMF exit, so :>I'd like to tap the collective wisdom of the group. :>- What's the best way for the IEFU8x code to "find" its companion non-exit :>code? In the current code the non-exit module defines itself as a subsystem, :>anchors a table in SSCTSUSE, and then the IEFU83 exit scans the SSCT to find :>it by name. Is this recommended, or is there a better way? :>- What's the best way to parametize an IEFU8x exit? The existing code has a :>customization utility named AMASPZAP . I obviously can't read a parameter :>file. It can't get the information from the SSCT technique described above :>because the sub-system name is one of the things that needs to be :>parametized. What do people recommend? :>- What's the best way for the IEFU8x code to pass messages to its companion :>non-exit code? The current code uses GETMAIN SP=241, CS, and an x-memory :>POST. It looks pretty good to me but is there a more recommended way? :>Thanks all. Note this code is all working so I don't need advice on getting :>any of the above-mentioned techniques to work (although pointing out very :>subtle gotchas is always helpful). I really want to know the best way to :>accomplish these things, big picture. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: Best practices for SMF exit routines
> What do you mean about the "companion non-exit code"? You can't "do much" in the exit code itself because the code path has to be short, and various exits impose constraints like "no SVCs." So there has to be a companion piece of code that "does the slow stuff" (writes to a file, etc.) based on work received from the exit code itself. There may also be initialization code, parameter file scanning code, etc., all of which cannot be in the exit code itself. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Miklos Szigetvari Sent: Monday, July 19, 2010 7:04 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Best practices for SMF exit routines > - What's the best way for the IEFU8x code to pass messages to its companion > non-exit code? The current code uses GETMAIN SP=241, CS, and an x-memory > POST. It looks pretty good to me but is there a more recommended way? > > What do you mean about the "companion non-exit code " ? -- 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: Best practices for SMF exit routines
Hi Looking back to my code about 1992 ... , an SMF exit system, with "companion non-exit code " , was a subsystem , communicated with the SMF exit via PC routines and has a subsystem initialization routine etc My point is, in an environment like this, maybe you need the subsystem. On 7/19/2010 4:33 PM, Charles Mills wrote: What do you mean about the "companion non-exit code"? You can't "do much" in the exit code itself because the code path has to be short, and various exits impose constraints like "no SVCs." So there has to be a companion piece of code that "does the slow stuff" (writes to a file, etc.) based on work received from the exit code itself. There may also be initialization code, parameter file scanning code, etc., all of which cannot be in the exit code itself. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Miklos Szigetvari Sent: Monday, July 19, 2010 7:04 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Best practices for SMF exit routines - What's the best way for the IEFU8x code to pass messages to its companion non-exit code? The current code uses GETMAIN SP=241, CS, and an x-memory POST. It looks pretty good to me but is there a more recommended way? What do you mean about the "companion non-exit code " ? -- 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
Re: Best practices for SMF exit routines
Charles, This is what I do in my code. My code installs exits into IEFUSI and IEFACTRT. The server address space that installs the exits before doing anything else, queries the exits using CSVDYNEX REQUEST=LIST to determine if they are active on the system. I query for SYS., SYSJES2, SYSJES3, SYSSTC. By examining the output of the list request, you can determine if the exit you need is active. You can play around with the SMFPRMxx member to specify the exits in different exit points, and then watch the results of the list request to see how it changes. If you have XDC, its really easy to do. I have a data structure in my server that is updated with the status of he exit points as a result of the query. The server address space establishes a PC routine for use by the SMF exits. The PC routine adds work to the tail of a work-to-do chain, then posts the proper ecb. When the exit code itself is to be installed, I get ECSA storage, and move the code to it. At the beginning of the code area, there is a full word for an address, and a status flag. The status flag is checked by the exit code to determine if it should proceed, or just br 14. The full word I use as a pointer to a ECSA data area. This data area contains the status of the server address space, as well as the PC nbr to use. I do it this way so I don't have to chase the SSCT chain on every invocation of the exit. If you have a vendor word in the vendor table, use that. My code will be doing that soon. The exit code itself should be protected by an estae. And, the PC routine shoudl be protected by an arr or an estae. My server address space also sets a resource manager routine that will set the flag in the exit (if not set already), and set the ECSA data area to show the server is gone(if not set already). When the exits are installed, they are set as non-active. Last thing my server code does when it is ready to process is to run CSVDYNEX to set them active. 1st thing it does when it is terminating is to set them inactive. I believe it is CSVDYNEX REQUEST=MODIFY. The exit code itself is left in ECSA when the server comes down, but is anchored in the ECSA data area. That data area, once acquried, is there for the life of the IPL. I just need to re-activate the exit when the server comes back up. This works for me. Hope this helps. --Dave -- 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: Best practices for SMF exit routines
Vendor. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Binyamin Dissen Sent: Monday, July 19, 2010 7:16 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Best practices for SMF exit routines Are you a vendor or is this for your site? The vendor answer is more complicated. -- 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: Best practices for SMF exit routines
U84 & U85 may require an FRR in place of an ESTAE. On Mon, 19 Jul 2010 10:12:26 -0500 Dave Day wrote: :>Charles, :>This is what I do in my code. My code installs exits into IEFUSI and IEFACTRT. :> :>The server address space that installs the exits before doing anything else, queries the exits using CSVDYNEX REQUEST=LIST to determine if they are active on the system. I query for SYS., SYSJES2, SYSJES3, SYSSTC. By examining the output of the list request, you can determine if the exit you need is active. You can play around with the SMFPRMxx member to specify the exits in different exit points, and then watch the results of the list request to see how it changes. If you have XDC, its really easy to do. I have a data structure in my server that is updated with the status of he exit points as a result of the query. :> :>The server address space establishes a PC routine for use by the SMF exits. The PC routine adds work to the tail of a work-to-do chain, then posts the proper ecb. :> :>When the exit code itself is to be installed, I get ECSA storage, and move the code to it. At the beginning of the code area, there is a full word for an address, and a status flag. The status flag is checked by the exit code to determine if it should proceed, or just br 14. The full word I use as a pointer to a ECSA data area. This data area contains the status of the server address space, as well as the PC nbr to use. I do it this way so I don't have to chase the SSCT chain on every invocation of the exit. If you have a vendor word in the vendor table, use that. My code will be doing that soon. :> :>The exit code itself should be protected by an estae. And, the PC routine shoudl be protected by an arr or an estae. My server address space also sets a resource manager routine that will set the flag in the exit (if not set already), and set the ECSA data area to show the server is gone(if not set already). :> :>When the exits are installed, they are set as non-active. Last thing my server code does when it is ready to process is to run CSVDYNEX to set them active. 1st thing it does when it is terminating is to set them inactive. I believe it is CSVDYNEX REQUEST=MODIFY. The exit code itself is left in ECSA when the server comes down, but is anchored in the ECSA data area. That data area, once acquried, is there for the life of the IPL. I just need to re-activate the exit when the server comes back up. :> :>This works for me. Hope this helps. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: Best practices for SMF exit routines
Then request your vendor word in ECVTCTBL and use it as the anchor for your blocks. No need to use an SSCT unless you need to do some subsystem services. On Mon, 19 Jul 2010 08:12:33 -0700 Charles Mills wrote: :>Vendor. :> :>Charles :> :>-Original Message- :>From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf :>Of Binyamin Dissen :>Sent: Monday, July 19, 2010 7:16 AM :>To: IBM-MAIN@bama.ua.edu :>Subject: Re: Best practices for SMF exit routines :>Are you a vendor or is this for your site? The vendor answer is more :>complicated. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: Best practices for SMF exit routines
Can someone remove my name from this mailing list ? regards, Tibish From: IBM Mainframe Discussion List on behalf of Binyamin Dissen Sent: Mon 7/19/2010 8:50 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Best practices for SMF exit routines Then request your vendor word in ECVTCTBL and use it as the anchor for your blocks. No need to use an SSCT unless you need to do some subsystem services. On Mon, 19 Jul 2010 08:12:33 -0700 Charles Mills wrote: :>Vendor. :> :>Charles :> :>-Original Message- :>From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf :>Of Binyamin Dissen :>Sent: Monday, July 19, 2010 7:16 AM :>To: IBM-MAIN@bama.ua.edu :>Subject: Re: Best practices for SMF exit routines :>Are you a vendor or is this for your site? The vendor answer is more :>complicated. -- Binyamin Dissen http://www.dissensoftware.com <http://www.dissensoftware.com/> Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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 Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.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: Best practices for SMF exit routines
The answer lies at the bottom of every message "- Tibish Mathew" Sent by: "IBM Mainframe Discussion List" 19/07/2010 05:36 PM Please respond to "IBM Mainframe Discussion List" To IBM-MAIN@bama.ua.edu cc Subject Re: Best practices for SMF exit routines Can someone remove my name from this mailing list ? regards, Tibish -- 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 This e-mail message, including any attachments transmitted with it, is CONFIDENTIAL and may contain legally privileged information. This message is intended solely for the use of the individual or entity to whom it is addressed. If you have received this message in error, please notify us immediately and delete it from your system. Please visit our website to read the full disclaimer: http://www.euroclear.com/site/public/disclaimer
Re: Best practices for SMF exit routines
That name sounds familiar. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Jacobs Sent: Monday, July 19, 2010 10:30 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Best practices for SMF exit routines Looking at an old apar OW13312 it says, Ownership of each four-byte slot is assigned by IBM. You must contact IBM in order to be assigned a slot. You must not modify a table slot without IBM's having allocated that slot to you. To request that a slot be allocated to you: Contact Peter Relson 1-914-435-8390 rel...@vnet.ibm.com USIBMKW2 at IBMMAIL -- 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: Best practices for SMF exit routines
On 07/19/10 13:13, Charles Mills wrote: Thanks. request your vendor word in ECVTCTBL Can anyone point me at the right resource for that? I Googled and got nothing relevant. My client is not primarily a mainframe software company and at this point they have no IBM contact point whatsoever. Charles Looking at an old apar OW13312 it says, Ownership of each four-byte slot is assigned by IBM. You must contact IBM in order to be assigned a slot. You must not modify a table slot without IBM's having allocated that slot to you. To request that a slot be allocated to you: Contact Peter Relson 1-914-435-8390 rel...@vnet.ibm.com USIBMKW2 at IBMMAIL -- Mark Jacobs Time Customer Service Tampa, FL "If you board the wrong train, it's no use running along the corridor in the other direction," Dietrich Bonhoeffer. World War II German resistance fighter -- 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: Best practices for SMF exit routines
Thanks. > request your vendor word in ECVTCTBL Can anyone point me at the right resource for that? I Googled and got nothing relevant. My client is not primarily a mainframe software company and at this point they have no IBM contact point whatsoever. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Binyamin Dissen Sent: Monday, July 19, 2010 8:21 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Best practices for SMF exit routines Then request your vendor word in ECVTCTBL and use it as the anchor for your blocks. No need to use an SSCT unless you need to do some subsystem services. -- 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: Best practices for SMF exit routines
-- As those of you following my IEFU8x thread know, I've just taken over responsibility for some IEFU8x code. It needs some serious re-writing and while I've got a lot of 360 to Z experience, this is my first SMF exit, so I'd like to tap the collective wisdom of the group. - What's the best way for the IEFU8x code to "find" its companion non-exit code? In the current code the non-exit module defines itself as a subsystem, anchors a table in SSCTSUSE, and then the IEFU83 exit scans the SSCT to find it by name. Is this recommended, or is there a better way? --- Given my somewhat limited experience in writing "vendor products", that seems like a good way to me. -- What's the best way to parametize an IEFU8x exit? The existing code has a customization utility named AMASPZAP . I obviously can't read a parameter file. It can't get the information from the SSCT technique described above because the sub-system name is one of the things that needs to be parametized. What do people recommend? -- Could your SSCT-addressed data have a special value in it, that won't vary with the subsystem name? Perhaps a word with a special value that IEFU8x could check for? Have you considered a name/token value? --- What's the best way for the IEFU8x code to pass messages to its companion non-exit code? The current code uses GETMAIN SP=241, CS, and an x-memory POST. It looks pretty good to me but is there a more recommended way? --- Have you got some mechanism in place to chain those messages is some sort of order? IEFU8x might get driven more often than the "receiving code"? CS/CDS come to mind here to manage the chain. A small CELLPOOL might also be useful, to reduce GETMAIN/FREEMAIN overhead. Plant your CELLPOOL anchor in the SSCT data for your subsystem. --- Thanks all. Note this code is all working so I don't need advice on getting any of the above-mentioned techniques to work (although pointing out very subtle gotchas is always helpful). I really want to know the best way to accomplish these things, big picture. --- Could a be nice learning experience to me as well. Hope I was able to help. Rick -- 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
