Re: SPFEDIT does a RESERVE!?!
>Date:Wed, 9 Apr 2008 15:27:36 -0500 >From:"McKown, John" <[EMAIL PROTECTED]> >Subject: Re: SPFEDIT does a RESERVE!?! With only two members in the Sysplex GRS ring is viable as the performance should not be too bad with only two members in the ring. I would set RESMIL=0. You really should look at the RNLs though, as the default operation for a RESERVE, without putting something in the RNLs, is that GRS will do *both* a hardware RESERVE and *also* send the request around the ring. If you want a hardware reserve you need the entry in the exclusion list to avoid the global enq traffic. If you want a global enq then you need an entry in the conversion RNL to avoid the reserve. The Sysplex Performance Redbook (SG24-4356) has a chapter on Ring versus Star, and the GRS planning book talks about the RNLs. Tom Russell "Stay calm. Be brave. Wait for the signs." -- Jasper FriendlyBear "... and remember to leave good news alone." -- Gracie HeavyHand -- 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: SPFEDIT does a RESERVE!?!
On Wed, 9 Apr 2008 14:58:22 -0500, Mark Zelden <[EMAIL PROTECTED]> wrote: >On Wed, 9 Apr 2008 18:36:08 +, Ted MacNEIL <[EMAIL PROTECTED]> wrote: > >>>Why not simply convert all reserves? One reason is that reserve is fast >and cheap. An enqueue involves a negotiation with all interested parties >over a commutations Link. Can be v e r y s l o w. >> >>I've been converting them for years. >>With GRS*, fast coupling links, and today's DASD, the difference is not >noticable. >>- > >John has no CFs. Not even sure if he has FICON CTCs. > The last I read in GRS Planning and Setting Up a Sysplex, the recommendation is convert all RESERVEs when in GRS Star (requires CF), but selective conversion when in Ring. Number of systems is not relevant. Advice worth heeding, due to the aforementioned response time elongation in conversions. Even a two-node sysplex responds noticeably better in Star than Ring, something we confirmed recently in our TestPlex. There is a price to pay - more CPU, another LPAR (CF), and storage. Even using XCF to transport the GRS signals, physical infrastructure, or the relative lack thereof, can add to RT elongation. Setting up transport classes and dedicating TC's to additional paths can help. FICON can help. Ultimately, you're still bound by the performance characteristics of a Ring. FWIW, we are currently Ring in production, using two FICON channels and a CF to transport XCF signals (single ICP link), including GRS, with no dedicated paths for specific transport classes, and we convert these RESERVEs: IGDCDSXS, SPFEDIT, SPZAPLIB, SYSIEWLP, SYSIGGV2, SYSZRACF plus HSM: ARCBACV, ARCMIGV, ARCENQG, ARCENQG, ARCENQG and a half-dozen ISV entries, per their documentation. Once we convert to Star, we will likely add SYSVTOC and SYSZVVDS, working up to QNAME(*). Regards, Art Gutowski Ford Motor Company IT Infrastructure zSeries Platform Planning, Build & Operations [EMAIL PROTECTED] -- 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: CF pricing [was: SPFEDIT does a RESERVE!?!]
On Wed, 9 Apr 2008 15:27:36 -0500, McKown, John wrote: >> -Original Message- >> From: IBM Mainframe Discussion List >> [mailto:[EMAIL PROTECTED] On Behalf Of David Andrews >> Sent: Wednesday, April 09, 2008 3:03 PM >> >> Sigh. That CF is 1/4 of a z10 chip, already delivered to you and >> sitting idle. It could have been positioned and marketed as IBM's >> competitive advantage, but instead it was priced out of reach and sits >> there stopped 24/7. What a waste. > >I agree with you in principle. However, from IBM's standpoint, that >unused CP is actually a "hot spare" and could be brought into play in >the rare case of a CP failure. You still have a spare processor after an ICF is configured. -- Tom Marchant -- 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: CF pricing [was: SPFEDIT does a RESERVE!?!]
"McKown, John" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>.. . > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:[EMAIL PROTECTED] On Behalf Of David Andrews > > Sent: Wednesday, April 09, 2008 3:03 PM > > To: IBM-MAIN@BAMA.UA.EDU > > Subject: CF pricing [was: SPFEDIT does a RESERVE!?!] > > > > > > On Wed, 2008-04-09 at 14:02 -0500, McKown, John wrote: > > > No coupling facility, so basic sysplex. XCF signalling via > > a ESCON CTC. > > > That's all I have. The CF was nixed due to cost. > > > > Sigh. That CF is 1/4 of a z10 chip, already delivered to you and > > sitting idle. It could have been positioned and marketed as IBM's > > competitive advantage, but instead it was priced out of reach and sits > > there stopped 24/7. What a waste. > > > > -- > > David Andrews > > I agree with you in principle. However, from IBM's standpoint, that > unused CP is actually a "hot spare" and could be brought into play in > the rare case of a CP failure. We actually had this happen on our z800. > This saves IBM a service call. I simply don't know why all CPs (zIIP, > zAAP, IFL, CFL , and general CP) don't > have the same hardware cost. Why charge more for a CP? Because it can > "do more"? Everybody get a rake off from having more CPs than you need > in software costs, as far as I can see. So why more cost for the same > physical hardware which is just running different microcode? I know, > marketing - which means meaningless to my techie mind. Marketing is simple: if you make a lot of money with their hardware, they want a (their) share of it. So the price is not determined by the cost of manufacturing the tool, but by the market, i.e. what profit you make with it, i.e. by what you might be willing to pay for it. Why do you think TV's and PC's cost what they cost and the prices stay the same over the years? Because the consumers consider this price reasonable and is willing to pay it. If you ask double, you sells will drop by much more, if you ask half your sells won't double. That is how the optimal price for things is often determined. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- 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: CF pricing [was: SPFEDIT does a RESERVE!?!]
>CFL It's not called a CFL, either. It's called an ICF (Internal Coupling Facility) - Too busy driving to stop for gas! -- 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: SPFEDIT does a RESERVE!?! A<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
What is all the cr*p after !?!. I use a BlackBerry, and this doesn't show up with mine. - Too busy driving to stop for gas! -- 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: CF pricing [was: SPFEDIT does a RESERVE!?!]
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of David Andrews > Sent: Wednesday, April 09, 2008 3:03 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: CF pricing [was: SPFEDIT does a RESERVE!?!] > > > On Wed, 2008-04-09 at 14:02 -0500, McKown, John wrote: > > No coupling facility, so basic sysplex. XCF signalling via > a ESCON CTC. > > That's all I have. The CF was nixed due to cost. > > Sigh. That CF is 1/4 of a z10 chip, already delivered to you and > sitting idle. It could have been positioned and marketed as IBM's > competitive advantage, but instead it was priced out of reach and sits > there stopped 24/7. What a waste. > > -- > David Andrews I agree with you in principle. However, from IBM's standpoint, that unused CP is actually a "hot spare" and could be brought into play in the rare case of a CP failure. We actually had this happen on our z800. This saves IBM a service call. I simply don't know why all CPs (zIIP, zAAP, IFL, CFL , and general CP) don't have the same hardware cost. Why charge more for a CP? Because it can "do more"? Everybody get a rake off from having more CPs than you need in software costs, as far as I can see. So why more cost for the same physical hardware which is just running different microcode? I know, marketing - which means meaningless to my techie mind. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: SPFEDIT does a RESERVE!?! A<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Scott Rowe > Sent: Wednesday, April 09, 2008 3:15 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: SPFEDIT does a RESERVE!?! > A<63986815-1207766168-cardhu_decombobulator_blackberry.rim.net > [EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > > > John, did you even consider running an ICF on your CPs? I > don't know if you have any excess capacity, but it is an > option. They don't advise using shared CPs for ICFs in a > true data sharing environment, but if all you are using it > for is GRS* it can work, and might allow you to convert all reserves. > > YMMV. No excess capacity. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: SPFEDIT does a RESERVE!?! A<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
John, did you even consider running an ICF on your CPs? I don't know if you have any excess capacity, but it is an option. They don't advise using shared CPs for ICFs in a true data sharing environment, but if all you are using it for is GRS* it can work, and might allow you to convert all reserves. YMMV. >>> "McKown, John" <[EMAIL PROTECTED]> 4/9/2008 3:02 PM >>> No coupling facility, so basic sysplex. XCF signalling via a ESCON CTC. That's all I have. The CF was nixed due to cost. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology Note that my email domain has changed from jo-annstores.com to joann.com. Please update your address book and other records to reflect this change. CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- 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
CF pricing [was: SPFEDIT does a RESERVE!?!]
On Wed, 2008-04-09 at 14:02 -0500, McKown, John wrote: > No coupling facility, so basic sysplex. XCF signalling via a ESCON CTC. > That's all I have. The CF was nixed due to cost. Sigh. That CF is 1/4 of a z10 chip, already delivered to you and sitting idle. It could have been positioned and marketed as IBM's competitive advantage, but instead it was priced out of reach and sits there stopped 24/7. What a waste. -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- 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: SPFEDIT does a RESERVE!?!
On Wed, 9 Apr 2008 18:36:08 +, Ted MacNEIL <[EMAIL PROTECTED]> wrote: >>Why not simply convert all reserves? One reason is that reserve is fast and cheap. An enqueue involves a negotiation with all interested parties over a commutations Link. Can be v e r y s l o w. > >I've been converting them for years. >With GRS*, fast coupling links, and today's DASD, the difference is not noticable. >- John has no CFs. Not even sure if he has FICON CTCs. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.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: SPFEDIT does a RESERVE!?!
>No coupling facility, so basic sysplex. XCF signalling via a ESCON CTC. >That's all I have. The CF was nixed due to cost. With two systems (which, iirc, you have), simple XCF signalling should be enough. - Too busy driving to stop for gas! -- 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: SPFEDIT does a RESERVE!?!
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL > Sent: Wednesday, April 09, 2008 1:36 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: SPFEDIT does a RESERVE!?! > > > >Why not simply convert all reserves? One reason is that > reserve is fast and cheap. An enqueue involves a negotiation > with all interested parties over a commutations Link. Can be > v e r y s l o w. > > I've been converting them for years. > With GRS*, fast coupling links, and today's DASD, the > difference is not noticable. > - No coupling facility, so basic sysplex. XCF signalling via a ESCON CTC. That's all I have. The CF was nixed due to cost. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: SPFEDIT does a RESERVE!?!
>Why not simply convert all reserves? One reason is that reserve is fast and >cheap. An enqueue involves a negotiation with all interested parties over a >commutations Link. Can be v e r y s l o w. I've been converting them for years. With GRS*, fast coupling links, and today's DASD, the difference is not noticable. - Too busy driving to stop for gas! -- 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: SPFEDIT does a RESERVE!?!
On Wed, 9 Apr 2008 10:09:04 -0400, Rob Scott wrote: > >If you haven't seen it already, ISPF enqueues are mentioned explicitly in the >"z/OS MVS Planning : GRS" manual - there are cases where exclusion RNL is >warranted and it also explains how SPFEDIT lives with SYSDSN. > And, more important, earlier I found in one of the ISPF manuals an explanation of how ISPF thrives without exclusive ENQs on SYSDSN. This is a technique I earnestly wish would be embraced by other z/OS components, particularly the C Run Time Library. -- gil -- 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: SPFEDIT does a RESERVE!?!
Welcome to the wonderful world of shared DASD. You ain't seen nutin' yet :-) Such reserves and enqueues abound. That's the only way you can keep multiple updaters from corrupting data. It also changes things. For example, in a shared DASD environment, you might find that Data Accelerator might actually degrade performance to an unacceptable level. From your description, every open is serialized across the sysplex and includes a enqueue/reserve that has a good potential for waiting on the other LPAR. Why not simply convert all reserves? One reason is that reserve is fast and cheap. An enqueue involves a negotiation with all interested parties over a commutations Link. Can be v e r y s l o w. By the way, the term to use is 'deadly embrace'. Just wait till you see the long chains: A waiting on B waiting on C waiting on D waiting on A. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Wednesday, April 09, 2008 8:59 AM To: IBM-MAIN@BAMA.UA.EDU Subject: SPFEDIT does a RESERVE!?! This came as a shock to me. We just went to a basic sysplex, splitting a single image into two images. We just had a lockup occur between the two images. This was caused because SPFEDIT does a RESERVE on the volume during a save operation. OK, mea culpa, for not reading every word of all the manuals where it is mentioned. The problem came up due to a package called Data Accelerator, which does on-the-fly compression of VSAM and non-VSAM files. What appears to have happened is that a TSO user does a SAVE on one system. Coincidentally just a bit after this (I think) Data Accelerator on the other system attempts a RESERVE on its control file, which happens to be on the same volume. This "hangs" Data Accelerator on the second system. But, part of the SAVE operation on the first system invokes Data Accelerator to see if the file is compressed, requiring access to the control file which the second system has "hung up" on. Now both systems are hung up in Data Accelerator. This eventually hangs up every OPEN and CLOSE on both systems until I figure out what is going on (about 5 minutes once I'm informed of a problem). The resolution: Put SPFEDIT in the conversion RNL. Also, put BMCBCSS in the reserve conversion RNL as well. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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: SPFEDIT does a RESERVE!?!
John If you haven't seen it already, ISPF enqueues are mentioned explicitly in the "z/OS MVS Planning : GRS" manual - there are cases where exclusion RNL is warranted and it also explains how SPFEDIT lives with SYSDSN. Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: 09 April 2008 14:59 To: IBM-MAIN@BAMA.UA.EDU Subject: SPFEDIT does a RESERVE!?! This came as a shock to me. We just went to a basic sysplex, splitting a single image into two images. We just had a lockup occur between the two images. This was caused because SPFEDIT does a RESERVE on the volume during a save operation. OK, mea culpa, for not reading every word of all the manuals where it is mentioned. The problem came up due to a package called Data Accelerator, which does on-the-fly compression of VSAM and non-VSAM files. What appears to have happened is that a TSO user does a SAVE on one system. Coincidentally just a bit after this (I think) Data Accelerator on the other system attempts a RESERVE on its control file, which happens to be on the same volume. This "hangs" Data Accelerator on the second system. But, part of the SAVE operation on the first system invokes Data Accelerator to see if the file is compressed, requiring access to the control file which the second system has "hung up" on. Now both systems are hung up in Data Accelerator. This eventually hangs up every OPEN and CLOSE on both systems until I figure out what is going on (about 5 minutes once I'm informed of a problem). The resolution: Put SPFEDIT in the conversion RNL. Also, put BMCBCSS in the reserve conversion RNL as well. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
SPFEDIT does a RESERVE!?!
This came as a shock to me. We just went to a basic sysplex, splitting a single image into two images. We just had a lockup occur between the two images. This was caused because SPFEDIT does a RESERVE on the volume during a save operation. OK, mea culpa, for not reading every word of all the manuals where it is mentioned. The problem came up due to a package called Data Accelerator, which does on-the-fly compression of VSAM and non-VSAM files. What appears to have happened is that a TSO user does a SAVE on one system. Coincidentally just a bit after this (I think) Data Accelerator on the other system attempts a RESERVE on its control file, which happens to be on the same volume. This "hangs" Data Accelerator on the second system. But, part of the SAVE operation on the first system invokes Data Accelerator to see if the file is compressed, requiring access to the control file which the second system has "hung up" on. Now both systems are hung up in Data Accelerator. This eventually hangs up every OPEN and CLOSE on both systems until I figure out what is going on (about 5 minutes once I'm informed of a problem). The resolution: Put SPFEDIT in the conversion RNL. Also, put BMCBCSS in the reserve conversion RNL as well. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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