Re: PDSEs in LNKLST at IPL can't be deleted
Mark, Follow this thread backwards to learn about the DFSMS 'global connect' prohibiting the deletion of a PDSE LNKLST'd at IPL. Also pay attention to the warnings mentioned by many, know the environment you're doing this, etc. Paul -- 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: PDSEs in LNKLST at IPL can't be deleted
I have the same problem with z/os 1.6 SYS1.SIEALNKE which is a new link list that IBM is pusing modules to. I can rename it, but not delete it. I wonder what would happen if I renamed the PDSE and then allocated it under it's original name. I dynamically removed it from LLA and XCFAS. Anybody try this? -- 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: PDSEs in LNKLST at IPL can't be deleted
I dynamically removed it from LLA and XCFAS. Anybody try this? Anybody consider that we are trying to keep the system up as long as possible? Without corruption? Why are we trying to outsmart protection. If it doesn't work that way, why fart with it? I'd rather have the system up an working, than limping because is screwed around. There are very few IPL's required! Live with them! - -teD O-KAY! BLUE! JAYS! Let's PLAY! BALL! -- 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: PDSEs in LNKLST at IPL can't be deleted
I agree with Ed Jaffe's reply: Using CVTLINK is just fine. The system treats that as use the LNKLST that this address space is using whether that be the IPL-time LNKLST or some other.. LOAD with ADDR= is relatively absurd, imo, unless you provide a directory entry (in which case you do not have to provide a DCB because you have already used the DCB to locate the directory). You have to know the length of the module in order to obtain the storage into which to put the module. And for that you need the directory entry. That is probably a reason that DCB is needed when you don't provide a directory entry. At least if you provide a DCB you have a chance of knowing where the module is coming from and, if it's yours, have a chance of knowing how big it is. Peter Relson z/OS Core Technology Design -- 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: PDSEs in LNKLST at IPL can't be deleted
Isn't there still some code in the system that uses the original DEB? No No (IBM-owned) system code uses CVTLINK or its DCB/DEB directly. When the system sees CVTLINK it translates CVTLINK into ASSBDLCB - DLCBDCB@ . Code stll running with the IPL-time LNKLST will of course access the original DEB when using the DLCBDCB@ path. . After a LNKLST UPDATE JOB(*) to a new LNKLST there won't be any such code (aside from the unpredictably dangerous window conditions). There could still be vendor or customer code that traverses the DCB/DEB path from CVTLINK. It is for this reason that we commit never to free the DCB/DEB of the IPL-time LNKLST. Peter Relson z/OS Core Technology Design -- 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: PDSEs in LNKLST at IPL can't be deleted
Peter Relson of z/OS Core Technology Design wrote: No (IBM-owned) system code uses CVTLINK or its DCB/DEB directly. When the system sees CVTLINK it translates CVTLINK into ASSBDLCB - DLCBDCB@ . Code stll running with the IPL-time LNKLST will of course access the original DEB when using the DLCBDCB@ path. . After a LNKLST UPDATE JOB(*) to a new LNKLST there won't be any such code (aside from the unpredictably dangerous window conditions). There could still be vendor or customer code that traverses the DCB/DEB path from CVTLINK. It is for this reason that we commit never to free the DCB/DEB of the IPL-time LNKLST. I may misunderstand what you are saying... What is the correct way to load a LNKLST module into a storage location of one's own choosing using ADDR= on the LOAD macro? LOAD with ADDR= requires a non-zero DCB=, so I have been using the CVTLINK DCB, but I'm presumably missing updates. I want the same behavious I would get with a LOAD without DCB=, which I understand would the LNKLST current when my job started. (Why, in passing, does ADDR= require DCB= on LOAD?) Tony H. -- 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: PDSEs in LNKLST at IPL can't be deleted
Tony Harminc wrote: I may misunderstand what you are saying... What is the correct way to load a LNKLST module into a storage location of one's own choosing using ADDR= on the LOAD macro? LOAD with ADDR= requires a non-zero DCB=, so I have been using the CVTLINK DCB, but I'm presumably missing updates. As long as you're not _traversing_ the CVTLINK DCB/DEB chain in your code, you're fine! If you're _referring_ to the CVTLINK DCB on contents supervisor services, you're doing exactly the right thing. -- 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: PDSEs in LNKLST at IPL can't be deleted
In [EMAIL PROTECTED], on 04/23/2006 at 08:48 PM, Binyamin Dissen [EMAIL PROTECTED] said: If the appropriate SETPROG is issued, each address space gets the new linklist. Isn't there still some code in the system that uses the original DEB? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PDSEs in LNKLST at IPL can't be deleted
It is indeed DFSMS's global connect that prevents a PDSE in the IPL-time LNKLST from being deleted. It is this area and related areas that we intend to change in z/OS V1R8. Peter Relson z/OS Core Technology Design -- 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
Fw: PDSEs in LNKLST at IPL can't be deleted
- Original Message From: Cox, Dave [EMAIL PROTECTED] Works quite well here where we get JES2 down ( we forget about Z EOD here - I was shocked that they did not do it here, but have gotten used to it ), and follow steps 1 through 4 manually. It doesn't take me any time at all to carefully go through those steps. Interesting idea of automating beyond JES2-down state. Dave, there's nothing wrong in following steps 1 to 4 manually. However, steps 3 and 4 must be executed without ANY delay, otherwise the whole sysplex will hang. Specifically, system reset must be executed only after the LPAR goes in wait state 0A2. Once the LPAR is reset, then the DOWN reply follows. If you delay the reply for whatever reason, the other LPARs in the sysplex will hang. This is the reason why I'd rather automated both steps, leaving SFM to do this. What I still miss, is if SFM can automate the reply to IXC102A, or an automation package must step in. Walter Marguccio -- 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: PDSEs in LNKLST at IPL can't be deleted
On 4/19/2006 2:44 PM, Paul Dineen wrote: I'm wondering if others have had difficulty with PDSE's which are included in LNKLST at IPL time, specifically deletion of them? There have been times where a LNKLST'd PDS needs expansion: the dataset can be 'dequeued' via SETPROG LNKLST,UNALLOCATE, stopping LLA and (in this shop) MIM. Then a dataset can be reallocated larger under a new DSN, populated, delete the old and rename the new as old. When done, restart LNKLST allocation, LLA, MIM. Fairly mundane stuff. I'd like to take this in a slightly different direction. First, I don't understand why you don't simply use dynamic linklist to establish a new entry in the linklist under a different name, and forget about the old data set, until you do IPL. But more than that, I'm curious about your comment about stopping MIM and this being mundane stuff. I would have expected that by stopping MIM you would lose multi-system serialization, and at that point you would need to ensure that no jobs or users were active on the system. And at that point you might as well IPL. Are you working in a single-system environment as opposed to multi-system? Or am I not understanding something else about your environment? Or is this another scenario I should warn my colleagues about that can cause corruption of the RACF database, so we can ask our customers who use MIM about it on the rare occasion where they report database corruption? Walt Farrell, CISSP z/OS Security Design, IBM -- 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: PDSEs in LNKLST at IPL can't be deleted
I get very frustrated when I continue to read posts about deleting libraries from the LNKLST. Anything that intends to delete a library from the LNKLST should be prepared for unpredictable errors and immediate re-IPL. This should be done as a last resort only. The LNKLST UNALLOCATE command is NOT intended to allow you to do that. It is intended to let you deal with uncataloged data sets of the same name as one in the LNKLST. If you tell the system to remove its ENQs and then do something like deleting a data set that is still being used you are subverting your own system and all bets are off. It is true that you cannot delete PDSEs that are in the IPL-time LNKLST. And you might have trouble with PDSEs that are in a LNKLST created after IPL. We hope to address both of those situations (alleviate, perhaps even remedy) in z/OS V1 R8. You must not delete a data set (PDS or PDSE) from a LNKLST that someone is using under any circumstance (and re-allocating to be larger size includes initially deleting). That means that if for some reason you feel you need to delete the data set, your first responsibility is to make sure that no job or address space has that data set in the LNKLST that it is using. As was posted, you would start by creating a new LNKLST set, without the bad data set, and LNKLST ACTIVATE it. New jobs and address spaces will automatically use that one. But you still have the problem of old jobs. The only way that you can do that is via the LNKLST UPDATE statement of PROGxx (or SETPROG LNKLST UPDATE). And that statement is to be issued at your risk. If you use it, you must be prepared to re-IPL. SETPROG LNKLST UPDATE JOB(*), for example, will get everyone off of old LNKLSTs, and may cause unpredictable problems for those address spaces. Once you have done that, and once you have gotten LLA no longer to be managing the particular data set (perhaps by stopping LLA and restarting it; perhaps by removing that data set from LLA management -- an LLA refresh will not do it), then the system will not have the data set ENQ'd and (aside from the PDSE in the IPL-time LNKLST case) you would be able to delete the data set. The approach of allocating a new larger data set and creating a LNKLST set with that data set instead of the old data set and then activating that LNKLST set is perfectly safe and will, at least, let new jobs use whatever is in the larger data set. Peter Relson z/OS Core Technology Design -- 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: PDSEs in LNKLST at IPL can't be deleted
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Zelden On Wed, 19 Apr 2006 14:12:04 -0500, Mark Zelden wrote: Not an issue for PDSE. It always counts as one extent, and if it takes an extent during update the module is accessable ~~ accessible Wish this new version of the listserv also included spell check in the web interface. :-) Feel free to use my line: All mispellings herein are intentional. :-) -jc- -- 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: PDSEs in LNKLST at IPL can't be deleted
Jim, Thanks for the reminder about program objects requiring PDSEs, something not when considering the possiblity of converting PDSE's to PDS. Paul 3) Converting IBM PDSEs back to PDS (with each version - annually here). You cannot do this. IBM PDSEs may contain members which use program object functions that are not available in a PDS. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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: PDSEs in LNKLST at IPL can't be deleted
Walt, Regarding the concern of stopping MIM, the LPAR where MIM is stopped is a SYSPROG only environment and MIM is not stopped in test or prod LPARs. Anyone taking the risk of stopping MIM understands the risk, is working alone in the LPAR and the stoppage is for a very short period. Don't worry about RACF, not applicable here (yes, I do have concerns about the security database in use). Thanks, Paul I would have expected that by stopping MIM you would lose multi-system serialization, and at that point you would need to ensure that no jobs or users were active on the system. And at that point you might as well IPL. Are you working in a single-system environment as opposed to multi-system? Or am I not understanding something else about your environment? Or is this another scenario I should warn my colleagues about that can cause corruption of the RACF database, so we can ask our customers who use MIM about it on the rare occasion where they report database corruption? Walt Farrell, CISSP z/OS Security Design, IBM -- 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: PDSEs in LNKLST at IPL can't be deleted
Thanks to all who've offered their thoughts. To Peter Relson, let me apologize if I've added to your frustration level in any way, shape or form. This is/was not my intent, I'm just trying to understand why a new and improved DSORG prohibits actions allowed with an older DSORG. I'm hoping your frustration might be reduced with the knowledge that any LNKLST UNALLOCATEs (PDSE or PDS) are done in an LPAR used only by the SYSPROG performing the task. Please also understand the frustration of a customer who (long after working hours) can't delete a dataset which has no displayable enqueues once removed from XCFAS/LLA and needs IBM help to be routed to APAR info documenting a PDSE 'permanent restriction'. Thanks for the info that z/OS 1.8 may change things. Some have offered the possibility of building and activating a new LNKLST without the problem PDSE and Peter mentioned using SETPROG LNKLST UPDATE JOB(*) with its associated risk. I built a test scenario. Unless I missed something during the test, the 'global connect' (by DFSMS?) still prohibits the delete. A summary of the test, not mentioning relief of enqueues needed: 1. Cloned a 'bad' LNKLST'd PDSE, named as *.NEW. 2. Defined a new LNKLST called LNKLST1, copied from current. 3. Added *.NEW PDSE to LNKLST1 4. Deleted old 'bad' PDSE from LNKLST1 5. Activated LNKLST1 (probably not needed due to next step) 6. SETPROG LNKLST UPDATE JOB(*) 7. Did a D PROG,LNKLST,JOBNAME=* All tasks (*MASTER* included) now are using LNKLST1. No tasks are using LNKLST00, the IPL time LNKLST. 8. Tried to delete the 'bad' PDSE and received: IEC614I SCRATCH FAILED - RC 008, DIAGNOSTIC INFORMATION IS (043D57D3) 9. Testing further, was able to rename 'bad' PDSE as *.TEST. 10. Tried to delete *.TEST and still received: IEC614I SCRATCH FAILED - RC 008, DIAGNOSTIC INFORMATION IS (043D57D3) Still don't see a way to delete the original 'bad' PDSE short of IPLing without it in LNKLST. I need to put this issue aside as a DR exercise (not a test in this shop, but true prod switchover...there's no test like production) is upcoming this weekend. Responses may not occur for a while. Paul -- 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
PDSEs in LNKLST at IPL can't be deleted
Hello, I'm wondering if others have had difficulty with PDSE's which are included in LNKLST at IPL time, specifically deletion of them? There have been times where a LNKLST'd PDS needs expansion: the dataset can be 'dequeued' via SETPROG LNKLST,UNALLOCATE, stopping LLA and (in this shop) MIM. Then a dataset can be reallocated larger under a new DSN, populated, delete the old and rename the new as old. When done, restart LNKLST allocation, LLA, MIM. Fairly mundane stuff. Until yesterday I didn't realize a PDSE LNKLST'd at IPL could not be deleted, not even if removed from active LNKLST. IBM pointed me to APARs OW40072/OW57609/OW57671 which describe the inability to delete as a 'permanent restriction'. These APARs are noted in PDSE usage Redbook, but haven't found any applicable info in MVS Init and Tuning. When a LNKLST'd PDSE delete attempt, error recieved is: IEC614I SCRATCH FAILED - RC 008, DIAGNOSTIC INFORMATION IS (043D57D3) Chasing the '57D3' in DFP diagnosis shows: Unable to delete the data set because it's currently connected on this system. It appears DFSMS does a 'global connect' for LNKLST'd PDSEs, but there is no 'global disconnect' resource. Peter Relson of IBM eluded to the issue on this list (June 2005), A reason I did not mention PDSEs is that you cannot delete a PDSE that was in the IPL-time LNKLST regardless of whether it is no longer in any active LNKLST set.. The response when inquired yesterday via IBM ETR was: The way to delete a PDSE that is in linklst is: 1) first remove it from linklst of every system in your sysplex, 2) IPL every system in your sysplex (that had it in linklst), then 3) Delete it. Unfortunately, it can't be done dynamically. IMHO, through the years IBM has done a great job in improving 'IPL avoidance', servicability, and one would think you'd be able to do more (not less) with PDSEs than PDSs. The scope of the problem has increased here recently as IBM is shipping more LNKLST'd PDSEs in ServerPac, libs which JES2, TCPIP, etc. depend upon. Currently, I have 10 PDSE's in the 1.7 LNKLST. Thoughts to mitigate, but not all prevent the problem include: 1) Overallocation of PDSEs. 2) Allowing secondary allocation (and the LNKLST can of worms that opens). 3) Converting IBM PDSEs back to PDS (with each version - annually here). 4) Removing PDSE's from IPL LNKLST, then adding dynamically. The APARs mentioned indicate theses PDSEs would be deletable. What if something required early in IPL (SYS1.LINKLIB) becomes PDSE??? I'd be interested if others have ideas on the subject, if others have requested changes from IBM, or if any of the IBM'ers on the list can divulge future enhancements in PDSE. Thanks, Paul -- 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: PDSEs in LNKLST at IPL can't be deleted
On Wed, 19 Apr 2006 13:44:28 -0500, Paul Dineen [EMAIL PROTECTED] wrote: Hello, I'm wondering if others have had difficulty with PDSE's which are included in LNKLST at IPL time, specifically deletion of them? No, but I can see where it could cause some confusion since the restriction isn't (well?) documented. Thoughts to mitigate, but not all prevent the problem include: 1) Overallocation of PDSEs. Secondary for user PDSEs in the LNKLST may not be a bad idea as opposed to overallocation. See #2 2) Allowing secondary allocation (and the LNKLST can of worms that opens). Not an issue for PDSE. It always counts as one extent, and if it takes an extent during update the module is accessable (an LLA refresh/update may be needed). Regards, Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] Systems Programming expert at http://expertanswercenter.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: PDSEs in LNKLST at IPL can't be deleted
In a recent note, Mark Zelden said: Date: Wed, 19 Apr 2006 14:12:04 -0500 2) Allowing secondary allocation (and the LNKLST can of worms that opens). Not an issue for PDSE. It always counts as one extent, and if it takes an extent during update the module is accessable (an LLA refresh/update may be needed). What's in the DEB for a PDSE? Or does it matter? -- gil -- StorageTek INFORMATION made POWERFUL -- 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: PDSEs in LNKLST at IPL can't be deleted
On Wed, 19 Apr 2006 14:12:04 -0500, Mark Zelden [EMAIL PROTECTED] wrote: Not an issue for PDSE. It always counts as one extent, and if it takes an extent during update the module is accessable ~~ accessible Wish this new version of the listserv also included spell check in the web interface. :-) -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] Systems Programming expert at http://expertanswercenter.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: PDSEs in LNKLST at IPL can't be deleted
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 04/19/2006 02:44:28 PM: Thoughts to mitigate, but not all prevent the problem include: 1) Overallocation of PDSEs. 2) Allowing secondary allocation (and the LNKLST can of worms that opens). 3) Converting IBM PDSEs back to PDS (with each version - annually here). You cannot do this. IBM PDSEs may contain members which use program object functions that are not available in a PDS. 4) Removing PDSE's from IPL LNKLST, then adding dynamically. The APARs mentioned indicate theses PDSEs would be deletable. What if something required early in IPL (SYS1.LINKLIB) becomes PDSE??? SYS1.LINKLIB will not become a PDSE. When linklib module wants or needs to be a program object, to goes into PDSE SYS1.SIEALNKE. But we expect SYS1.SIEALNKE to be in the IPL time LNKLST. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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: PDSEs in LNKLST at IPL can't be deleted
Hi Paul, define a new PDSE and copy the old into the new the activate a new LNKLST via T PROG=xx. PROG-Member (sample) LNKLST DEFINE NAME(LNKLSTCBC) COPYFROM(CURRENT) LNKLST DELETE NAME(LNKLSTCBC) DSNAME(SYS3.CBC140E.SCCNCMP.LINKLIB) LNKLST ADDNAME(LNKLSTCBC) DSNAME(SYS3.CBC140F.SCCNCMP.LINKLIB) LNKLST ACTIVATE NAME(LNKLSTCBC) As it's part of the LNKLST nobody should care about the DSNAME. Any new STC/LOGON/JOB will see the new LNKLST. In case of problem we can also switch back to the old PDSE. Roland -- 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
