Re: Best way for a task to give up the CPU and let other tasks run?
On 2019-10-22 12:09 PM, Mike Hochee wrote: Define application program? COBOL batch or CICS transaction program? Most legacy applications on z/OS don't implement concurrency. Agreed, they don't implement concurrency, however they are often very heavily reliant upon on it, as it is built into the database management and message queuing systems they access (whether the programmer is aware of it or not). As a result, workloads generally move right along. Yep. And considering how difficult it is to do concurrency correctly that's a good thing. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Monday, October 21, 2019 11:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Best way for a task to give up the CPU and let other tasks run? Caution! This message was sent from outside your organization. On 2019-10-22 1:55 AM, Tony Harminc wrote: On Sun, 20 Oct 2019 at 02:32, David Crayford wrote: The only code I've seen that implements yield are synchronization routines. Consider a spin-lock which is spinning on a CS instruction. Why would any application program on z/OS implement and use a spin lock? Define application program? COBOL batch or CICS transaction program? Most legacy applications on z/OS don't implement concurrency. Porting modern code is another matter. You may find a lot of the new ported code like Node.js (V8), libuv etc implement their own locks. Why do the authors of such think they can do a better implementation than the operating system? Maybe using SETLOCK (which requires supervisor state, key 0) is an obstacle? If you think you need a spin lock on z/OS, you should probably be using transactional execution. Yes, I agree. But it's quite tricky to grok and you need to crack open the assembler! There's an example of a lock-free queue using transactional execution in Zowe https://github.com/zowe/zowe-common-c/blob/719251839033059fb3b507f26f6fbb58be57f188/c/collections.c#L1123 Tony H. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Best way for a task to give up the CPU and let other tasks run?
> Define application program? COBOL batch or CICS transaction program? > Most legacy applications on z/OS don't implement concurrency. Agreed, they don't implement concurrency, however they are often very heavily reliant upon on it, as it is built into the database management and message queuing systems they access (whether the programmer is aware of it or not). As a result, workloads generally move right along. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Monday, October 21, 2019 11:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Best way for a task to give up the CPU and let other tasks run? Caution! This message was sent from outside your organization. On 2019-10-22 1:55 AM, Tony Harminc wrote: > On Sun, 20 Oct 2019 at 02:32, David Crayford wrote: > >> The only code I've seen that implements yield are synchronization >> routines. Consider a spin-lock which is spinning on a CS instruction. > Why would any application program on z/OS implement and use a spin > lock? Define application program? COBOL batch or CICS transaction program? Most legacy applications on z/OS don't implement concurrency. Porting modern code is another matter. You may find a lot of the new ported code like Node.js (V8), libuv etc implement their own locks. > Why do the authors of such think they can do a better implementation > than the operating system? Maybe using SETLOCK (which requires supervisor state, key 0) is an obstacle? > > If you think you need a spin lock on z/OS, you should probably be > using transactional execution. Yes, I agree. But it's quite tricky to grok and you need to crack open the assembler! There's an example of a lock-free queue using transactional execution in Zowe https://github.com/zowe/zowe-common-c/blob/719251839033059fb3b507f26f6fbb58be57f188/c/collections.c#L1123 > > Tony H. > > -- > 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: Best way for a task to give up the CPU and let other tasks run?
On 2019-10-22 1:55 AM, Tony Harminc wrote: On Sun, 20 Oct 2019 at 02:32, David Crayford wrote: The only code I've seen that implements yield are synchronization routines. Consider a spin-lock which is spinning on a CS instruction. Why would any application program on z/OS implement and use a spin lock? Define application program? COBOL batch or CICS transaction program? Most legacy applications on z/OS don't implement concurrency. Porting modern code is another matter. You may find a lot of the new ported code like Node.js (V8), libuv etc implement their own locks. Why do the authors of such think they can do a better implementation than the operating system? Maybe using SETLOCK (which requires supervisor state, key 0) is an obstacle? If you think you need a spin lock on z/OS, you should probably be using transactional execution. Yes, I agree. But it's quite tricky to grok and you need to crack open the assembler! There's an example of a lock-free queue using transactional execution in Zowe https://github.com/zowe/zowe-common-c/blob/719251839033059fb3b507f26f6fbb58be57f188/c/collections.c#L1123 Tony H. -- 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: Best way for a task to give up the CPU and let other tasks run?
On Mon, 21 Oct 2019 19:01:15 +, Jesse 1 Robinson wrote: >(Now with some actual content.) The standard justification for spin loop is >that the area of code in question is executed *very* frequently and is *very* >short. > I'd say, rather, the typical *wait* is *very* short. >... In other words, not worth the overhead of an actual WAIT nor the delay in >having to get redispatched afterwards. Spin loop is not an ideal strategy >but--as long as all goes well--worth the improved performance overall. The >biggest problem with spin loop is on a single CP machine when the loop does >not terminate properly. If a second CP is available, it can jump in and >interrupt the loop. With no second CP in the picture, the loop may go on and >on. > Deadlock? The likelihood goes down with the number of CPUs. But that's what dooms the strategy of STIMER and retry (akin to a slow spin) to resolve DSN ENQ. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Best way for a task to give up the CPU and let other tasks run?
(Now with some actual content.) The standard justification for spin loop is that the area of code in question is executed *very* frequently and is *very* short. In other words, not worth the overhead of an actual WAIT nor the delay in having to get redispatched afterwards. Spin loop is not an ideal strategy but--as long as all goes well--worth the improved performance overall. The biggest problem with spin loop is on a single CP machine when the loop does not terminate properly. If a second CP is available, it can jump in and interrupt the loop. With no second CP in the picture, the loop may go on and on. That being said, I can't imagine an application program using this mechanism. OTOH, the line between 'problem program' and 'middleware' (akin to OS) can be pretty fuzzy. OP, however, said he wanted to yield CPU to other tasks. Spin loop is designed not to yield to anyone. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Harminc Sent: Monday, October 21, 2019 10:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Best way for a task to give up the CPU and let other tasks run? On Sun, 20 Oct 2019 at 02:32, David Crayford wrote: > The only code I've seen that implements yield are synchronization > routines. Consider a spin-lock which is spinning on a CS instruction. Why would any application program on z/OS implement and use a spin lock? Why do the authors of such think they can do a better implementation than the operating system? If you think you need a spin lock on z/OS, you should probably be using transactional execution. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Best way for a task to give up the CPU and let other tasks run?
. . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Harminc Sent: Monday, October 21, 2019 10:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Best way for a task to give up the CPU and let other tasks run? On Sun, 20 Oct 2019 at 02:32, David Crayford wrote: > The only code I've seen that implements yield are synchronization > routines. Consider a spin-lock which is spinning on a CS instruction. Why would any application program on z/OS implement and use a spin lock? Why do the authors of such think they can do a better implementation than the operating system? If you think you need a spin lock on z/OS, you should probably be using transactional execution. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA Spool Security Setup
If you are a licensed user, this can be answered be the vendor (ca is now a Broadcom company). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Best way for a task to give up the CPU and let other tasks run?
On Sun, 20 Oct 2019 at 02:32, David Crayford wrote: > The only code I've seen that implements yield are synchronization > routines. Consider a spin-lock which is spinning on a CS instruction. Why would any application program on z/OS implement and use a spin lock? Why do the authors of such think they can do a better implementation than the operating system? If you think you need a spin lock on z/OS, you should probably be using transactional execution. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resource Link Down?
Responding to my own post. It's back up now -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: Monday, October 21, 2019 12:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Resource Link Down? https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww-01.ibm.com%2Fservers%2Fresourcelink%2Fsvc00100.nsf%2Fpages%2FzosInternetLibrarydata=02%7C01%7Callan.staller%40HCL.COM%7C534b38c7fc8f41dbe45c08d7564a21d5%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637072748736787187sdata=Dp34stGfJf78kDsBiJMyGFubIJPoAxMkeBoBwbZnodA%3Dreserved=0 https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww-01.ibm.com%2Fservers%2Fresourcelink%2Fsvc00100.nsf%2Fpages%2FzosInternetLibrary%3FOpenDocumentdata=02%7C01%7Callan.staller%40HCL.COM%7C534b38c7fc8f41dbe45c08d7564a21d5%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637072748736787187sdata=BysnrBL%2BswRmyL6AEPJDYaPC%2BD1FOy%2F7bAOZNulZ01w%3Dreserved=0 Or, even more important, IS resourcelink down? https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww-01.ibm.com%2Fservers%2Fresourcelink%2Fsvc03100.nsf%3FOpenDatabasedata=02%7C01%7Callan.staller%40HCL.COM%7C534b38c7fc8f41dbe45c08d7564a21d5%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637072748736797183sdata=kfgO%2FOLcJaJqX3gtgJ7ZaDxDFSQivzP0LLlQLEfSp48%3Dreserved=0 All above links receive GATEWAY TIME OUT The "new tools" are neither as reliable, serviceable or available as those they are replacing. ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- 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
Resource Link Down?
https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosInternetLibrary https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosInternetLibrary?OpenDocument Or, even more important, IS resourcelink down? https://www-01.ibm.com/servers/resourcelink/svc03100.nsf?OpenDatabase All above links receive GATEWAY TIME OUT The "new tools" are neither as reliable, serviceable or available as those they are replacing. ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Standalone DFDSS
The Visara is a CCA-3074. 3074 is FICON point-to-point connected. Visara terminals are connected by TCPIP through a switch on a private network, and defined as "hot" consoles. I don't think the SSL option was used since it is a simple private network. The HMC 3270 option was attempted and also got no response. We are preparing to build a new DR system environment. > Sent: Monday, October 21, 2019 at 7:02 AM > From: "Mazer Ken G" <01e8b07bfbbe-dmarc-requ...@listserv.ua.edu> > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Standalone DFDSS > > Don, > > Is your Visara connected via OSA-ICC? Does the console in question receive > the OSA-ICC three line display? > You didn't indicate the reason for running Standalone DFDSS, did you get a > new processor or are you setting up a new DR environment. > > The reason I ask these questions is that we just replaced z13's with z14's > and the OSA Express6s cards are a little different as they now have TLS 1.0 > enabled. > It could be that you need to update your certs on the Visara for the sessions > to connect. > > Ken Mazer > This Cranky Systems Programmer says “Share your knowledge, others may find it > useful” > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Donald J > Sent: Saturday, October 19, 2019 9:26 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Standalone DFDSS > > Thanks Jim & Brian > We have Visara which seems to not be working. > Ticket is open on it. > > > Sent: Saturday, October 19, 2019 at 1:08 AM > > From: "Brian Westerman" > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Standalone DFDSS > > > > Jim is correct, all it takes is for one of the consoles that is attached to > > the ICC, or which you have limited your DFDSS SA build to to press enter. > > I have found that almost any key that generates "something" seems to work > > though, the function keys, pageup etc. The ones that just move the cursor > > around (i.e. home) don't generate what it's looking for. > > > > In short, enter works fine. > > > > Brian > > > > -- > > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Standalone DFDSS
Don, Is your Visara connected via OSA-ICC? Does the console in question receive the OSA-ICC three line display? You didn't indicate the reason for running Standalone DFDSS, did you get a new processor or are you setting up a new DR environment. The reason I ask these questions is that we just replaced z13's with z14's and the OSA Express6s cards are a little different as they now have TLS 1.0 enabled. It could be that you need to update your certs on the Visara for the sessions to connect. Ken Mazer This Cranky Systems Programmer says “Share your knowledge, others may find it useful” -Original Message- From: IBM Mainframe Discussion List On Behalf Of Donald J Sent: Saturday, October 19, 2019 9:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Standalone DFDSS Thanks Jim & Brian We have Visara which seems to not be working. Ticket is open on it. > Sent: Saturday, October 19, 2019 at 1:08 AM > From: "Brian Westerman" > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Standalone DFDSS > > Jim is correct, all it takes is for one of the consoles that is attached to > the ICC, or which you have limited your DFDSS SA build to to press enter. I > have found that almost any key that generates "something" seems to work > though, the function keys, pageup etc. The ones that just move the cursor > around (i.e. home) don't generate what it's looking for. > > In short, enter works fine. > > Brian > > -- > 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: Best way for a task to give up the CPU and let other tasks run?
Back in the days of IPS/ICS dispatching control, wasn't there something that was referred to as the 'wheeler-dealer mechanism' & does it still exist in some form in the WLM code? >From memory: 1. New task gets created and is assigned a time-slice of 1msec, at a priority of 32 (out of 64 - i.e 'half'), then placed on the dispatch queue 2. Task eventually shuffles to the top of the queue and starts running. 3. If the task voluntarily relinquishes control (due to some sort of SVC call, etc) before the time slice expires, then the time slice duration gets doubled and the priority is reduced by 50%. 4. Alternatively, if the time slice expires and the OS unilaterally wrests control from the task, then the time slice duration gets halved and the priority is bumped by 50% 5. Task is once more placed on the dispatch queue 6. etc... I may have the actions of (3) and (4) round the wrong way. I wouldn't be at all surprised to be told I'm completely wrong. As I say, this is all from a memory and I seem to have so few neurons left these days. Sean On Sun, 20 Oct 2019 at 14:02, Charles Mills wrote: > I just looked up "External Interruption" in the Principles. There are at > least 9 possible causes. > > IIRC on the System 360 there was an eight-pin Molex connector available > and a customer-provided box of some sort could trigger an external > interrupt by pulling the appropriate pin to ground. See page 19 of > http://www.bitsavers.org/pdf/ibm/360/systemSummary/GA22-6810-12_360sysSumJan74.pdf > . > > IIRC MICR check sorters used this feature to generate their high-priority > interrupts to the processor. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Tom Brennan > Sent: Saturday, October 19, 2019 7:24 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Best way for a task to give up the CPU and let other tasks > run? > > Interesting, thanks! So it generates an external interrupt. I always > thought that one was only for the external interrupt "key", but this > page indicates CPU timer and some kind of CP-to-CP communication too: > > > https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zconcepts/zconc_interrupts.htm > > Ok... now back to my weekend work, like changing the oil in my truck. > > -- > 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: [EXT] Re: zOS 2.4 migration guide
@Kurt - thank you for the qualification - "...but z/OS software will continue to be serviced using PTFs and therefore using SMP/E". I hadn't read or heard that until now. Its good to hear that that is the case. Sean On Sat, 19 Oct 2019 at 00:49, Mark Zelden wrote: > z/OSMF can create an extract of the migration information (now called > "upgrade" instead > of "migration") from the z/OSMF workflow (either z/OS 2.2 to z/OS 2.4 or > z/OS 2.3 > to z/OS 2.4 - whichever one you import from GitHub or both). It's in HTML > format > and quite readable with links to the different sections. > > While this may not be well known (it wasn't to me), there is also a link > on GitHub along > with the workflows to pre-exported migration information, which is in > essence the migration > manual. It's super easy to miss, so read the "readme" carefully. > > Changing the subject to z/OSMF itself... > > Although you may not require z/OSMF to get the upgrade information, I > still strongly > suggest you bite the bullet and get z/OSMF up and running - as long as you > are at > z/OS 2.3. Like it or not, you're going to need it somewhere in your > installation > in the near future.It is a helava lot easier in z/OS 2.3 with the > PARMLIB member > customization taking the place of things you had to do previously do via > scripts > and unix customization. > > However, by far the biggest pain has not gotten any easier - all the RACF > setup. > The sample jobs are nice and are "close" but the don't take everything > into account. > You need to understand your RACF environment fairly well.For example, > if you don't > have enhanced generic naming in effect in RACF, some things have to be > changed slightly. > > And there are a lot of jobs to customize / run for the different plugins > (I combined mine > all into a single job for the RACF people to run). I work with dozens of > sysprogs and > almost none of them understand anything about RACF admin nor their local > environments, > and the RACF admins hardly understand RACF admin these days for my > clients, let alone > anything about z/OS or z/OSMF, so you can see the challenge. Lucky for > me, I understand > both. > > I never bit the bullet myself until this year under z/OS 2.3 and it was > fairly painless > to install in 7 sysplexes after the first one I did in a sandbox sysplex > when I had all > the RACF jobs built along with other required jobs (CIM zFS creation / > customization, > z/OSMF zFS creation). Attending some of the z/OSMF user sessions at SHARE > years > ago made me really dread doing this prior to z/OS 2.3 across many different > sysplxes, but with z/OS 2.3 copying some jobs to run and a parmlib member > to another > sysplex wasn't difficult. Other than waiting for RACF admins to run the > RACF jobs for me, > I would have had z/OSMF running in a day or two on all but the first > sysplex. > > Regards, > > Mark > -- > Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS > ITIL v3 Foundation Certified > mailto:m...@mzelden.com > Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html > Systems Programming expert at http://search390.techtarget.com/ateExperts/ > -- > 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
