Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
No. Clark Morris wrote: On 23 Jul 2012 12:49:31 -0700, in bit.listserv.ibm-main you wrote: snip Is there a comparable facility for JES3? Clark Morris snip - Support is provided to allow jobs for which journaling is used to be stopped after a currently running step has finished and held for restart in the following step. This is intended to allow less-disruptive system shutdowns. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
In 245275432281.wa.paulgboulderaim@listserv.ua.edu, on 07/23/2012 at 03:55 PM, Paul Gilmartin paulgboul...@aim.com said: As I stated initially, one of my motives was portability. In a conventional UNIX system, processes needn't register to receive SIGTERM. In a conventional Unix system, applications are written to expect SIGTERM. That is not the case in z/OS. Likewise, it should be unnecessary in z/OS UNIX (USS). It's not necessary in Unformatted System Services. It is necessary in z/OS that you not arbitrarily terminated all of the address spaces that have been dubbed. Given the behavior of SIGTERM, it is not appropriate to use it as a global shutdown mechanism for address spaces that are not expecting it. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
The orderly shutdown of z/OS address spaces requires not just telling each address space it needs to terminate, but to shut down address spaces in an order that is heavily installation-dependent. In general a server address space (like HSM, DB2, Tape Management, Job management, TCP/IP, Vtape, etc.) has no way of knowing what other address spaces may generate future requests, and some of those future requests may be required for the other address space to terminate normally. In our installation an approximate order (ignoring UNIX stuff) was: (1)shut down batch jobs first (because they could be using job automation, tape management, DB2, CICS, TCP/IP, HSM). Allow some opportunity for short jobs to quiesce at job boundaries to simplify job-stream restart, else force termination. (2)shut down CICS regions (CICS regions use DB2, VTAM, TCP/IP and may try to submit jobs). (3)shut down general TSO use (source of batch jobs, HSM requests, DB2 requests, VTAM/TCP/IP) (3)Initiate DB2 shutdown (could be using Tape Management system and Vtape, VTAM, TCP/IP) (4) Shut down various remaining server address spaces (Vtape, HSM, Tape Management, Job Scheduler Restart systems, etc). (5) Shut down VTAM, TCP/IP (6) Shut down JES2 This is an over simplification because there are TEST CICS regions dependent on a TEST DB2 environment and PROD CICS regions dependent on a PROD DB2 requirement, as well as a interdependency ordering of the CICS reqions themselves. There are also some other dependency ordering among server address spaces not explicitly mentioned, but you get the idea. If you just tell all address spaces to start termination in parallel without regard to proper sequencing, many will not go down normally or possibly even hang, and you may even end up with more confusion than if you just pulled the plug by deactivating the entire LPAR abruptly (from which things like CICS and DB2 are designed to recover) with no attempt at orderly termination. The only way to get a normal shut down is for each installation to determine the order of address space shut down that makes sense in their environment; and to minimize the time involved to shut down, use some automation tools to implement that shut down ordering. J. C. Ewing 07/22/2012 05:45 PM, Scott Ford wrote: Gil, I am with you and zMan what's so difficult about an orderly shutdown on OMVS and z/os address spaces..z/Pdt has vtamappl, everything shutdown fine... Scott ford www.identityforge.com On Jul 22, 2012, at 6:37 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Sun, 22 Jul 2012 18:23:36 -0400, zMan wrote: Some years ago, I suggested in MVS-OE that MVS shutdown should send SIGTERM to all dubbed processes so that processes coded to UNIX conventions could perform orderly shutdown. The suggestion was not well received. Can you elaborate? Why would orderly shutdown not be A Good Thing? They didn't say. Too UNIXy for them. But I'll conjecture: Many address spaces get dubbed nowadays by incidental use of UNIX services such as TCP/IP. The default action for SIGTERM if a process doesn't handle it is that the process is terminated. This would be unwelcomed by a process that was waiting rather for a legacy MODIFY command to shut itself down. -- gil ... -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
SIGNAL SHUTDOWN is, I believe, a VM construct. It is not a machine construct. fully-architected hardware external interrupt (in the PoPs) that indicates that the LPAR is being shut down. FWIW, there is no such external interrupt. There is a service signal interrupt and z/OS does receive some of those interrupts (not all). The particular events that are the subject of a service signal interrupt are not documented in the Principles of Operation. The functionality being alluded to is an event that asks the running entity (e.g., z/OS) to enter a wait state (presumably by doing some sort of quiesce operation) before a certain timeout limit has been exceeded. If it has not done so, then once that time limit has been reached the LPAR shut down goes forward anyway. It is my understanding that this timeout value is 5 minutes which might or might not be long enough for a reasonable z/OS orderly shut down. If true, then writing a message will not be enough. Non-software support would be needed to identify a longer timeout value (hence increasing the bill). Note also that it would be a bad thing to unconditionally force every LPAR shut down to wait an extra 5 minutes as there will be customers who do not care to set up monitoring for such a message. Having the customer inform z/OS of interest is another necessary, not difficult, part of the solution. as long as an automation package or maybe even system rexx could intercept the message and take action that was desired. I'm sure just about every site has a protocol for what it considers an orderly shutdown. z/OS itself has very little clue. When a customer wants an orderly shutdown, I presume that they initiate one. And if the action that was desired exceeds the time threshold, the deactivation will occur before it is desired. This is perhaps a naive question but is the problem that the person who is getting rid of an LPAR does not talk to the person in charge of the system running on the LPAR (to me that's similar to holding the power-off button on your PC instead of doing a shutdown) and just does the LPAR deactivation? I'll readily grant that it would be nicer if that communication did not need to occur, but I really find it a bit hard to believe that such communication is anything other than a necessity. I don't know if it will be felt that it is nicer enough to justify the cost. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
Don't know if z/OS itself is part of this, but have you looked at http://www.ibm.com/developerworks/rfe/? From: David Boyes dbo...@sinenomine.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Sunday, July 22, 2012 2:17 PM Subject: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message How can I go about submitting a requirement for z/OS to acknowledge and handle the same external interrupt as VM, VSE and Linux use to trigger a controlled shutdown (or at least acknowledge it by printing a message we can capture via console automation and trigger the shutdown ourselves)? For those of you who haven't seen it, VM, VSE and Linux register for a specific fully-architected hardware external interrupt (in the PoPs) that indicates that the LPAR is being shut down. VSE issues a message, VM reflects the interrupt to all virtual machines which are registered to receive it, and Linux (if configured to register for it) triggers a user-specified command (usually 'shutdown -h now'). I'd like to have z/OS register for that interrupt, and at least print a unique message if/when that specific interrupt arrives. Any suggestions on how to get this done without taking decades? It doesn't seem like a lot to ask for, and it's a fully-defined legitimate hardware interrupt that z/OS ought to be able to handle if it got one. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
It would be nice if an JES INIT could be set to abend a job at the end of a step to allow faster shutdown, cleaner restart. I.E. a status of draining-step would continue to run, but when the step ends .the job is cancelled. You would not want to apply this to some inits, because a STC or online region might have a clean-up step after the main step closes. On Mon, Jul 23, 2012 at 10:46 AM, Joel C. Ewing jcew...@acm.org wrote: deleted (1)shut down batch jobs first (because they could be using job automation, tape management, DB2, CICS, TCP/IP, HSM). Allow some opportunity for short jobs to quiesce at job boundaries to simplify job-stream restart, else force termination. (2)shut down CICS regions (CICS regions use DB2, VTAM, TCP/IP and may try to submit jobs). deleted -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
I guess I don't understand what David is asking..I thought that the z/Pdt cmd 'oprmsg ' routes a message or command to z/os from Linux ... Scott ford www.identityforge.com On Jul 23, 2012, at 2:00 PM, Frank Swarbrick frank.swarbr...@yahoo.com wrote: Don't know if z/OS itself is part of this, but have you looked at http://www.ibm.com/developerworks/rfe/? From: David Boyes dbo...@sinenomine.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Sunday, July 22, 2012 2:17 PM Subject: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message How can I go about submitting a requirement for z/OS to acknowledge and handle the same external interrupt as VM, VSE and Linux use to trigger a controlled shutdown (or at least acknowledge it by printing a message we can capture via console automation and trigger the shutdown ourselves)? For those of you who haven't seen it, VM, VSE and Linux register for a specific fully-architected hardware external interrupt (in the PoPs) that indicates that the LPAR is being shut down. VSE issues a message, VM reflects the interrupt to all virtual machines which are registered to receive it, and Linux (if configured to register for it) triggers a user-specified command (usually 'shutdown -h now'). I'd like to have z/OS register for that interrupt, and at least print a unique message if/when that specific interrupt arrives. Any suggestions on how to get this done without taking decades? It doesn't seem like a lot to ask for, and it's a fully-defined legitimate hardware interrupt that z/OS ought to be able to handle if it got one. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
Mike Schwab wrote: It would be nice if an JES INIT could be set to abend a job at the end of a step to allow faster shutdown, cleaner restart. I.E. a status of draining-step would continue to run, but when the step ends .the job is cancelled. You would not want to apply this to some inits, because a STC or online region might have a clean-up step after the main step closes. That sounds pretty close to this function we announced for z/OS R13: In z/OS V1.13, several batch enhancements are provided for JES2 environments that are intended to help simplify the development of batch applications. snip - Support is provided to allow jobs for which journaling is used to be stopped after a currently running step has finished and held for restart in the following step. This is intended to allow less-disruptive system shutdowns. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
On 23 Jul 2012 12:49:31 -0700, in bit.listserv.ibm-main you wrote: Mike Schwab wrote: It would be nice if an JES INIT could be set to abend a job at the end of a step to allow faster shutdown, cleaner restart. I.E. a status of draining-step would continue to run, but when the step ends .the job is cancelled. You would not want to apply this to some inits, because a STC or online region might have a clean-up step after the main step closes. That sounds pretty close to this function we announced for z/OS R13: In z/OS V1.13, several batch enhancements are provided for JES2 environments that are intended to help simplify the development of batch applications. Is there a comparable facility for JES3? Clark Morris snip - Support is provided to allow jobs for which journaling is used to be stopped after a currently running step has finished and held for restart in the following step. This is intended to allow less-disruptive system shutdowns. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
In b870629719727b4ba82a6c06a31c29123249662...@hqmailsvr01.voltage.com, on 07/22/2012 at 07:26 PM, Phil Smith p...@voltage.com said: Couldn't CP PVMSG send something that automation could pick up? What if you're not running z/VM? Does the CP in PR/SM support PVMSG? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
Metz wrote: What if you're not running z/VM? Does the CP in PR/SM support PVMSG? No. But if you have access to the HMC, you should be able to get to the console. The thing with z/VM is that you might have a ton of guests and you're IPLing z/VM. If you're taking the CEC down, well...that's all-hands-on-deck anyway, isn't it? ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
On Sun, 22 Jul 2012 15:17:11 -0500, David Boyes wrote: For those of you who haven't seen it, VM, VSE and Linux register for a specific fully-architected hardware external interrupt (in the PoPs) that indicates that the LPAR is being shut down. VSE issues a message, VM reflects the interrupt to all virtual machines which are registered to receive it, and Linux (if configured to register for it) triggers a user-specified command (usually 'shutdown -h now'). I'd like to have z/OS register for that interrupt, and at least print a unique message if/when that specific interrupt arrives. In Linux, which process handles the shutdown signal? Init? Or is it sent to all processes with a default of ignore, with at least one superuser process handling it by issuing shutdown? Some years ago, I suggested in MVS-OE that MVS shutdown should send SIGTERM to all dubbed processes so that processes coded to UNIX conventions could perform orderly shutdown. The suggestion was not well received. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
On Sun, 22 Jul 2012 18:23:36 -0400, zMan wrote: Some years ago, I suggested in MVS-OE that MVS shutdown should send SIGTERM to all dubbed processes so that processes coded to UNIX conventions could perform orderly shutdown. The suggestion was not well received. Can you elaborate? Why would orderly shutdown not be A Good Thing? They didn't say. Too UNIXy for them. But I'll conjecture: Many address spaces get dubbed nowadays by incidental use of UNIX services such as TCP/IP. The default action for SIGTERM if a process doesn't handle it is that the process is terminated. This would be unwelcomed by a process that was waiting rather for a legacy MODIFY command to shut itself down. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
Gil, I am with you and zMan what's so difficult about an orderly shutdown on OMVS and z/os address spaces..z/Pdt has vtamappl, everything shutdown fine... Scott ford www.identityforge.com On Jul 22, 2012, at 6:37 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Sun, 22 Jul 2012 18:23:36 -0400, zMan wrote: Some years ago, I suggested in MVS-OE that MVS shutdown should send SIGTERM to all dubbed processes so that processes coded to UNIX conventions could perform orderly shutdown. The suggestion was not well received. Can you elaborate? Why would orderly shutdown not be A Good Thing? They didn't say. Too UNIXy for them. But I'll conjecture: Many address spaces get dubbed nowadays by incidental use of UNIX services such as TCP/IP. The default action for SIGTERM if a process doesn't handle it is that the process is terminated. This would be unwelcomed by a process that was waiting rather for a legacy MODIFY command to shut itself down. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
I think the problem is that in z/OS there is no one way of notification (I know you are asking for one). There are at least 2 (3 if you count z) commands to stop an application, P and ,technically F I know F is usually modify but it is also used as stop. All the applications would have to be re-written. An interface would have to be created (again programs would have to be altered and or re- written). I am not against it per se it would be a few years to implement I am sure. Plus there is an issue of timing on how things happen. I smell an ugly up rising. Ed On Jul 22, 2012, at 5:45 PM, Scott Ford wrote: Gil, I am with you and zMan what's so difficult about an orderly shutdown on OMVS and z/os address spaces..z/Pdt has vtamappl, everything shutdown fine... Scott ford www.identityforge.com On Jul 22, 2012, at 6:37 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Sun, 22 Jul 2012 18:23:36 -0400, zMan wrote: Some years ago, I suggested in MVS-OE that MVS shutdown should send SIGTERM to all dubbed processes so that processes coded to UNIX conventions could perform orderly shutdown. The suggestion was not well received. Can you elaborate? Why would orderly shutdown not be A Good Thing? They didn't say. Too UNIXy for them. But I'll conjecture: Many address spaces get dubbed nowadays by incidental use of UNIX services such as TCP/IP. The default action for SIGTERM if a process doesn't handle it is that the process is terminated. This would be unwelcomed by a process that was waiting rather for a legacy MODIFY command to shut itself down. -- gil - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM- MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
How can I go about submitting a requirement for z/OS to acknowledge and handle the same external interrupt as VM, VSE and Linux use to trigger a controlled shutdown (or at least acknowledge it by printing a message we can capture via console automation and trigger the shutdown ourselves)? David, the best way to submit a requirement is through Share. Anyone can submit a requirement. Share has a new website that you'll need to sign up for, but you don't have to be a Share member. http://reqs4.share.org/Reqs4Who.jsp is the link to the requirements system. You can also submit a MR (Marketing Requirement) through your IBM Rep. IBM has had a renewed focus on Share requirements over the last couple of years. If you need assistance, please feel free to contact me off list. Mary Anne -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
David, What issuing a z/Pdt cmd OPRMSG 'cmd ...'. Scott ford www.identityforge.com On Jul 22, 2012, at 4:17 PM, David Boyes dbo...@sinenomine.net wrote: How can I go about submitting a requirement for z/OS to acknowledge and handle the same external interrupt as VM, VSE and Linux use to trigger a controlled shutdown (or at least acknowledge it by printing a message we can capture via console automation and trigger the shutdown ourselves)? For those of you who haven't seen it, VM, VSE and Linux register for a specific fully-architected hardware external interrupt (in the PoPs) that indicates that the LPAR is being shut down. VSE issues a message, VM reflects the interrupt to all virtual machines which are registered to receive it, and Linux (if configured to register for it) triggers a user-specified command (usually 'shutdown -h now'). I'd like to have z/OS register for that interrupt, and at least print a unique message if/when that specific interrupt arrives. Any suggestions on how to get this done without taking decades? It doesn't seem like a lot to ask for, and it's a fully-defined legitimate hardware interrupt that z/OS ought to be able to handle if it got one. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
At 18:18 -0500 on 07/22/2012, Ed Gould wrote about Re: Submitting a requirement for z/OS to at least acknowled: I think the problem is that in z/OS there is no one way of notification (I know you are asking for one). There are at least 2 (3 if you count z) commands to stop an application, P and ,technically F I know F is usually modify but it is also used as stop. All the applications would have to be re-written. An interface would have to be created (again programs would have to be altered and or re-written). I am not against it per se it would be a few years to implement I am sure. Plus there is an issue of timing on how things happen. I smell an ugly up rising. Ed I do not think that he is requesting that the interrupt has to trigger a MVS Shut-Down - Only that when the interrupt occurs that the system acknowledge that it has occurred and respond to it somehow. A suggestion in his request was that a console message be issued to alert the operator and (if one exists) the message handling operations package. The Message would go to the master consoles and would be flagged as non-scrollable. That meets he defined request. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Submitting a requirement for z/OS to at least acknowledge SIGNAL SHUTDOWN by printing a message
Robert, That is my understanding also..as long as an automation package or maybe even system rexx could intercept the message and take action that was desired. I don't see why that wouldn't work... Scott ford www.identityforge.com On Jul 22, 2012, at 8:51 PM, Robert A. Rosenberg hal9...@panix.com wrote: At 18:18 -0500 on 07/22/2012, Ed Gould wrote about Re: Submitting a requirement for z/OS to at least acknowled: I think the problem is that in z/OS there is no one way of notification (I know you are asking for one). There are at least 2 (3 if you count z) commands to stop an application, P and ,technically F I know F is usually modify but it is also used as stop. All the applications would have to be re-written. An interface would have to be created (again programs would have to be altered and or re-written). I am not against it per se it would be a few years to implement I am sure. Plus there is an issue of timing on how things happen. I smell an ugly up rising. Ed I do not think that he is requesting that the interrupt has to trigger a MVS Shut-Down - Only that when the interrupt occurs that the system acknowledge that it has occurred and respond to it somehow. A suggestion in his request was that a console message be issued to alert the operator and (if one exists) the message handling operations package. The Message would go to the master consoles and would be flagged as non-scrollable. That meets he defined request. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
