Re: Where is the EPA offset of a program in the Binder API data?
On 2018-12-02 2:49 PM, Jesse 1 Robinson wrote: The original program had been assembled with END EP-name. That name was not defined with external reference otherwise. With no source to reassemble, we could not get it to link with just the load module alone. Hmm, may have been fixable by a delinker which could reconstruct the object deck, and then you could have edited the END card, perhaps? If you had a delinker handy, of course... Cheers, Greg P. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where is the EPA offset of a program in the Binder API data?
Kinda long post. You might just wanna move along. A load module PDS(E) directory contains various info for the modules it describes. One datum is the EPA for each member. Alias members have their own directory entries, which may have the same EPA as the main member or a different EPA. An EPA must be identifiable and locatable at binder time. It may or may not correspond to an alias name, but either way it's recorded in the directory and governs how the module will begin execution. War story. We once tried to provide emergency recovery for a sister shop whose upgrade had tanked horribly. They brought copies of their critical programs on tape. Forget why, but one of them needed to be relinked for our environment. No bueno. The original program had been assembled with END EP-name. That name was not defined with external reference otherwise. With no source to reassemble, we could not get it to link with just the load module alone. Problem may have been fixed in the intervening decades, but it was a show stopper at the time. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Friday, November 30, 2018 2:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Where is the EPA offset of a program in the Binder API data? On Thu, 29 Nov 2018 17:01:34 +, Farley, Peter x23353 wrote: >The PDS/E directory entry for a program contains, among other information, the >EPA offset within the program. > >The EPA offset is also contained in the SMDE/PMAR information returned by >DESERV. > >After much RTFM however, I cannot seem to find anywhere in the Binder API data >areas an indication of which section/label is the entry point for the program. > >In particular, I would have expected that an LD entry in the ESD table would >contain such an indicator, but I do not see one anywhere. > >Am I just not seeing the information in the API structures or is it just not >there? I don't know the answer to your question. Consider that a CSECT can contain many ENTRY statements. A load module can contain many CSECTs, coming from many compile units. The ENTRY specified when binding the load module can be a CSECT or an ENTRY specified at assembly time. A load module can have many aliases, each referencing a different entry point. A load module can be bound again and saved with a new name with a different entry point. Given the above, I would be surprised if the entry point can be obtained from any other place than the directory entry. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "first previous"?
> -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Paul Gilmartin > Sent: Saturday, December 01, 2018 12:13 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: "first previous"? > > From Program Management UG and Ref: > > A SYMPATH specification applies to all SYMLINK specifications that > precede it, > back to the first previous SYMPATH. > > The word "previous" seems superfluous here. I wonder whether it means > "very first SYMPATH" or "nearest previous SYMPATH? I always took it to mean the latter. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IND$FILE -- where did the name come from?
On Sat, 1 Dec 2018 19:12:06 -0500, Don Leahy wrote: >So what? You can also download it using IND$FILE. That was the last time >I used IND$FILE. > >On Sat, Dec 1, 2018 at 6:52 PM Paul Gilmartin wrote: > >> Linux? >> MacOS? >> Solaris? >> ... ? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IND$FILE -- where did the name come from?
So what? You can also download it using IND$FILE. That was the last time I used IND$FILE. I prefer WSA because it is very easy to automate using Rexx. On Sat, Dec 1, 2018 at 6:52 PM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Sat, 1 Dec 2018 18:08:26 -0500, Don Leahy wrote: > > >Why all the love for IND$FILE? ISPF's workstation agent (WSA) is a far > >superior solution to the problem of sending files between your work > station > >and the mainframe. Easy to automate (see the ISPF FILEXFER service) and > is > >included with ISPF at no additional cost. > > > Linux? > MacOS? > Solaris? > ... ? > > 1. FTP (requires workstation FTP server). > o Download using FTP. ISPF invokes the host FTP client to connect with the > FTP server > on your workstation and transfer the WSA installation program. > ... > Well, gee. If I already have FTP to my workstation, why do I need to > install > something else to transfer files? > > -- 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: IND$FILE -- where did the name come from?
On Sat, 1 Dec 2018 18:08:26 -0500, Don Leahy wrote: >Why all the love for IND$FILE? ISPF's workstation agent (WSA) is a far >superior solution to the problem of sending files between your work station >and the mainframe. Easy to automate (see the ISPF FILEXFER service) and is >included with ISPF at no additional cost. > Linux? MacOS? Solaris? ... ? 1. FTP (requires workstation FTP server). o Download using FTP. ISPF invokes the host FTP client to connect with the FTP server on your workstation and transfer the WSA installation program. ... Well, gee. If I already have FTP to my workstation, why do I need to install something else to transfer files? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IND$FILE -- where did the name come from?
Why all the love for IND$FILE? ISPF's workstation agent (WSA) is a far superior solution to the problem of sending files between your work station and the mainframe. Easy to automate (see the ISPF FILEXFER service) and is included with ISPF at no additional cost. On Sat, Dec 1, 2018 at 3:37 PM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Sat, 1 Dec 2018 20:46:19 +, Robert Prins wrote: > > >On 2018-11-30 12:33, John Eells wrote: > >> > >> IND$FILE, as part of z/OS, remains supported. As far as I know, > support for it > >> has never lapsed (certainly not since its inclusion into OS/390). > > > >If it's supported, then would you be willing to make a small change to > it, to > >use SDB, rather than whatever hardcoded blocksize it's using now. FWIW, I > zapped > >it, and I believe there there is a list of locations to zap for various > (older) > >versions around. > > > One for each version, or several for each? If the latter, I hope it's > an EQU where a one-line change suffices. > > Sounds like an RFE. > > Or has IBM a blanket policy of replacing hardcoded blocksize with SDB? > > IIRC, IBM changed IEBGENER to rely on SDB, then needed to backtrack > because customers depended on the prior behavior. > > And IBM's changing Rexx EXECIO to rely on SDB broke some of my EXECs > because SDB chose an invalid blocksize in some cases where the Rexx > runtime had chosen a valid one. SR suggested an existing PTF, intended > for JES, that solved my problem. But then cautioned, "That PTF causes > Rexx to behave contrary to specification, and the adverse behavior might > return if a customer reported a problem. You should always specify > BLKSIZE." > > -- 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: LXRES best practices copy of the link
https://share.confex.com/share/124/webprogram/Handout/Session17096/SHARE_Seattle_2015_Storage.pdf > On Dec 1, 2018, at 1:13 PM, scott Ford wrote: > > How can I get a copy of your presentation Peter? It would be appreciated by > this ‘mere’ padawn.. > > Regards, > Scott > > On Sat, Dec 1, 2018 at 9:12 AM Peter Relson wrote: > >>> the regular LX is easier as I only need I register to PC >> >> That strikes me as the wrong attitude. This is authorized code. You should >> also be considering what is best for the system (and the rest of the users >> within the system), not only what is easiest. >> >>> If my started task goes down and I restart it the virtual address in >> private of the PC routine would be different isn’t that an issue >> >> It's not an issue, it's a fact. When you restart, you are still connecting >> an entry table to an LX, whether it is an LX that is newly reserved or is >> an LX that is being re-connected-to. You still need to build the entry >> table, so should be doing so as part of the restart process, using the >> addresses you find within your restarted space. >> >> 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 >> > -- > Scott Ford > IDMWORKS > z/OS Development > > -- > 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: LXRES best practices
So On restart I need to do everything but LXRES the linkage number is still valid meaning I need to do the following three ETDEF,ETCRE and ETCON and the ETCON uses the saved linkage number correct ? On Dec 1, 2018, at 9:10 AM, Peter Relson wrote: >> the regular LX is easier as I only need I register to PC > > That strikes me as the wrong attitude. This is authorized code. You should > also be considering what is best for the system (and the rest of the users > within the system), not only what is easiest. > >> If my started task goes down and I restart it the virtual address in > private of the PC routine would be different isn’t that an issue > > It's not an issue, it's a fact. When you restart, you are still connecting > an entry table to an LX, whether it is an LX that is newly reserved or is > an LX that is being re-connected-to. You still need to build the entry > table, so should be doing so as part of the restart process, using the > addresses you find within your restarted space. > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "first previous"?
On Sat, 1 Dec 2018 16:00:43 -0500, zMan wrote: >I am thinking that a non-native speaker writing this was perhaps. > (Yodaspeak?) Ref: https://en.wikipedia.org/wiki/Markedness#Marked_and_unmarked_word_pairs ??? "first" is unmarked; "last" marked? >On Sat, Dec 1, 2018 at 3:13 PM Paul Gilmartin wrote: > >> From Program Management UG and Ref: >> >> A SYMPATH specification applies to all SYMLINK specifications that >> precede it, >> back to the first previous SYMPATH. >> >> The word "previous" seems superfluous here. I wonder whether it means >> "very first SYMPATH" or "nearest previous SYMPATH?" -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "first previous"?
I am thinking that a non-native speaker writing this was perhaps. On Sat, Dec 1, 2018 at 3:13 PM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > From Program Management UG and Ref: > > A SYMPATH specification applies to all SYMLINK specifications that > precede it, > back to the first previous SYMPATH. > > The word "previous" seems superfluous here. I wonder whether it means > "very first SYMPATH" or "nearest previous SYMPATH? > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- zMan -- "I've got a mainframe and I'm not afraid to use it" -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IND$FILE -- where did the name come from?
On Sat, 1 Dec 2018 20:46:19 +, Robert Prins wrote: >On 2018-11-30 12:33, John Eells wrote: >> >> IND$FILE, as part of z/OS, remains supported. As far as I know, support for >> it >> has never lapsed (certainly not since its inclusion into OS/390). > >If it's supported, then would you be willing to make a small change to it, to >use SDB, rather than whatever hardcoded blocksize it's using now. FWIW, I >zapped >it, and I believe there there is a list of locations to zap for various (older) >versions around. > One for each version, or several for each? If the latter, I hope it's an EQU where a one-line change suffices. Sounds like an RFE. Or has IBM a blanket policy of replacing hardcoded blocksize with SDB? IIRC, IBM changed IEBGENER to rely on SDB, then needed to backtrack because customers depended on the prior behavior. And IBM's changing Rexx EXECIO to rely on SDB broke some of my EXECs because SDB chose an invalid blocksize in some cases where the Rexx runtime had chosen a valid one. SR suggested an existing PTF, intended for JES, that solved my problem. But then cautioned, "That PTF causes Rexx to behave contrary to specification, and the adverse behavior might return if a customer reported a problem. You should always specify BLKSIZE." -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
"first previous"?
From Program Management UG and Ref: A SYMPATH specification applies to all SYMLINK specifications that precede it, back to the first previous SYMPATH. The word "previous" seems superfluous here. I wonder whether it means "very first SYMPATH" or "nearest previous SYMPATH? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
open spot
Sorry for the solicitation, but we have a spot open for a senior MVS sysprog here in beautiful East Tennessee (Knoxville/Foothills area), if anyone knows someone. Just drop me a note for more information. Thanks. rob First Tennessee Bank Mainframe Technical Support FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IND$FILE -- where did the name come from?
On 2018-11-30 12:33, John Eells wrote: Seymour J Metz wrote: I believe that IND$FILE is included in your z/OS license. I also believe that it is long out of support and less efficient than, e.g., SFTP (yes, FTP is considered insecure these days.) IND$FILE, as part of z/OS, remains supported. As far as I know, support for it has never lapsed (certainly not since its inclusion into OS/390). If it's supported, then would you be willing to make a small change to it, to use SDB, rather than whatever hardcoded blocksize it's using now. FWIW, I zapped it, and I believe there there is a list of locations to zap for various (older) versions around. Robert -- Robert AH Prins robert(a)prino(d)org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IND$FILE -- where did the name come from?
On 2018-11-29 18:39, Seymour J Metz wrote: > OCO was a gradual infestation. DF/DS, DF/EF (15 % discount on plasma), > MVS/SE, MVS/SP and, as I recall, DFP, preceded it, and the was still > microfiche for, e.g., TSO/E, long after OCO had started. OCO was a lot more gradual than the speed IBM drove. I wonder if IBM realized that. Once upon a time we had 7171's for dial up 3270 sessions. And TSO users would get stuck. Their session would be left so they couldn't log back on and they couldn't reconnect. The operators couldn't cancel the left over session, though the system did say "cancel command accepted". A dump of the hung TSO session showed the initiator task RB waiting on the cancel ECB for the TSO session. This RB wasn't running (even if the cancel ECB was posted) because it wasn't the topmost RB on the initiator tasks TCB RB chain. The topmost RB was an IRB from VTAM waiting for some VTAM event so I opened a problem with IBM VTAM. VTAM looked at several dumps of this case but VTAM wanted traces of a failing case -- Yes, trace all 7171's on a production system for something which happened possibly several times a week. And the problem wasn't know about until until someone tried to logon which could be any amount of time after the problem hit. No. They also couldn't understand why the user wasn't cancelable. Locally we eventually figured out that varying the LU for the TSO session inactive (possibly requiring force) would cause the waiting VTAM request complete follwed by the initator canceling the user (if a cancel command had been issued). This wasn't really a good solution as it took operator intervention and/or system programming staff intervention and also our local policy was to avoid "force" unless it was to avoid an IPL. The only useful information from VTAM was that the hang was a result of an incomplete reconnect where the old TSO address space had committed to connect to a specific inbound session which had likely dropped. After months of nothing useful from VTAM, I looked deeper. I didn't need to "fix", just stop the user from being locked out. The VTAM module was OCO. Well, not so great. However, downstairs we had old microfiche. How old? Tww versions back. Ah, a bit of looking at the fiche and disassembly of the current module and things become clear. I can see that this isn't the first time VTAM has had a hang in this module. There are multiple VTAM calls with later added STIMER timeouts around them. But no timeout on the one I'm stuck on (of course). A quick zap to the module to add a STIMER around the VTAM call with the STIMER exit just issuing ABEND "fixed" the problem. The non-reconnected address space terminates and the user can re-logon without any operator intervention. Just a disasm wouldn't have helped as much as having the old fiche which told what the module was doing. So OCO had an effect more on new sites, and on IBM as they got less help from the field. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LXRES best practices
How can I get a copy of your presentation Peter? It would be appreciated by this ‘mere’ padawn.. Regards, Scott On Sat, Dec 1, 2018 at 9:12 AM Peter Relson wrote: > >the regular LX is easier as I only need I register to PC > > That strikes me as the wrong attitude. This is authorized code. You should > also be considering what is best for the system (and the rest of the users > within the system), not only what is easiest. > > >If my started task goes down and I restart it the virtual address in > private of the PC routine would be different isn’t that an issue > > It's not an issue, it's a fact. When you restart, you are still connecting > an entry table to an LX, whether it is an LX that is newly reserved or is > an LX that is being re-connected-to. You still need to build the entry > table, so should be doing so as part of the restart process, using the > addresses you find within your restarted space. > > 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 > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESTAE retry vs percolate SDWACLUP bit
In application code - probably no problem as whatever resources used will be tracked by the system and freed. In system code mucho problems possible, since one would not free resources if one expects to retry - and these resources may not be associated by the system with the failed unit of work. On Fri, 30 Nov 2018 10:47:00 -0600 Paul Schuster wrote: :>Hello: :> :>The manual MVS Programming: Assembler Services :>Guide Chapter 8. Providing recovery explains that an ESTAE that is called with the SDWACLUP bit on can only percolate (SETRP RC=0). It further explains that if you do attempt a retry (SETRP RC=4) , the retry will be ignored. :> :>I was testing with an ESTAE that gets control with the SDWACLUP bit on, and the routine does attempt a retry (SETRP RC=4) but it indeed was ignored, with no other apparent adverse impact. :> :>So my question is this: aside from completeness/code purity, is there anything to worry about if an ESTAE attempts a retry even though the SDWACLUP bit is on? I can envision that the recovery routine itself may have different logic based on whether the SDWACLUP bit is on or off. :> :>I did change my specific ESTAE to exit SETRP RC=0 when the SDWACLUP bit is on. :> :>Thank you for any insight you can provide. :> :>Paul :> :>-- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LXRES best practices
>the regular LX is easier as I only need I register to PC That strikes me as the wrong attitude. This is authorized code. You should also be considering what is best for the system (and the rest of the users within the system), not only what is easiest. >If my started task goes down and I restart it the virtual address in private of the PC routine would be different isn’t that an issue It's not an issue, it's a fact. When you restart, you are still connecting an entry table to an LX, whether it is an LX that is newly reserved or is an LX that is being re-connected-to. You still need to build the entry table, so should be doing so as part of the restart process, using the addresses you find within your restarted space. 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: ESTAE retry vs percolate SDWACLUP bit
As long as your code does whatever it needs to do, based on understanding that retry will or will not happen, it is fine always to tell RTM to retry. Peter Relson z/OS Core Technology Design0 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where is the EPA offset of a program in the Binder API data?
On 2018-12-01 4:01 AM, Farley, Peter x23353 wrote: But the question still remains -- Where (if anywhere) is an EPA indicator in the returned Binder API data? I guess I should have spoken more plainly. I'd say it's not there because it is not needed. If you are including the module for subsequent saving, you can preserve the entry point by using ATTRIB=YES on the INCLUDE. And you can specify entry points when you add new aliases. But you can't AFAIK extract what the current entry point is set to. It is not needed because it does not affect the internal structure of the module. You do know the entry point will be in the first class - the one at offset zero when the module is loaded - so it is reasonably easy to determine the entry point symbol (or at least a symbol at the same offset), but I agree it is not quite as simple as being told "the answer" directly. Cheers, Greg P. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where is the EPA offset of a program in the Binder API data?
Thank you Peter! I missed that even though I called myself doing a very careful RTFM. Makes sense now that I think about it. DESERV returns the PMAR data following the SMDE entry and likely gets the same data from the same place (though I realize it is not necessarily getting the data via the GUPI interface). Thanks again for the on-target answer. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Morrison Sent: Saturday, December 1, 2018 2:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where is the EPA offset of a program in the Binder API data? Peter, You can read the PMAR using the binder API. I had a similar problem trying to find out where information that is in the PDS(E) directory is for a program object in a unix file. It turns out that the information is embedded in the program object, but, of course, the internal format for a program object has not been decoded (yet?) If you look at the binder API description, you will see that you can rear the information by using the GETD Call, using a class name of B_PMAR - the returned data must be described by a buffer that uses the TYPE=PMAR option. Note that the actual PMAR data in the buffer must be mapped using the IEWPMAR macro. Be aware of the program object level - according to the documentation the PMAR is a different length for some. Peter Morrison -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
