Re: JESSPOOL
===>ISFACR In a message dated 3/13/2020 5:11:56 AM Central Standard Time, rsc...@rocketsoftware.com writes: I would just like to stress how sensible it would be to start that process now if your site is still on SDSF internal security. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JESSPOOL
I would also check if the user(s) have OWNER=xx. PREFIX=xx, and/or SYSTEM=x set. This can be entered from the SDSF command line. Matthew On Fri, 13 Mar 2020 11:45:52 +, Bill Johnson wrote: >Thanks Bob. > > >Sent from Yahoo Mail for iPhone > > >On Friday, March 13, 2020, 7:09 AM, Robert S. Hansel (RSH) > wrote: > >Hi Bill, > >In general, users automatically get full ALTER access to their own output, so >I doubt JESSPOOL is the issue. If they are attempting to delete output from >within SDSF, they also need access to SDSF panels and operator commands. These >are controlled by RACF profiles in the SDSF, GSDSF, and OPERCMDS classes, or >if they are not protected by RACF, then by SDSF's ISFPARMS. > >You can use SDSF's SECTRACE to help debug the problem. Have a user execute SET >SECTRACE ON or WTP at the SDSF command line (ON sends the results to ULOG; WTP >to SYSLOG). Have the user attempt to delete output. Then, assuming they >specified ON, have the user execute the ULOG command to see the RACF calls and >their results. This assumes the user has authority to use ULOG - SDSF class >resource ISFCMD.ODSP.ULOG.jesname or the ISFPARMS equivalent. > >Regards, Bob > >Robert S. Hansel >Lead RACF Specialist >RSH Consulting, Inc. >617-969-8211 >www.linkedin.com/in/roberthansel >www.twitter.com/RSH_RACF >www.rshconsulting.com >--- >Upcoming RSH RACF Training - WebEx >- RACF Audit & Compliance Roadmap - OCT 19-23, 2020 >- RACF Level I Administration - APR 27 - MAY 1, 2020 >- RACF Level II Administration - APR 6-10, 2020 >- RACF Level III Admin, Audit, & Compliance - NOV 2-6, 2020 >- RACF - Securing z/OS UNIX - SEPT 28 - OCT 2, 2020 >--- > >-Original Message- >Date: Thu, 12 Mar 2020 20:09:24 + >From: Bill Johnson >Subject: JESSPOOL > >I’m not a RACF expert and need help giving a user the ability to delete their >own SDSF output. Not really sure why they don’t have it. Not my setup. Is it >an easy 1 command fix or more complex? >Thanks > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JESSPOOL
Thanks Bob. Sent from Yahoo Mail for iPhone On Friday, March 13, 2020, 7:09 AM, Robert S. Hansel (RSH) wrote: Hi Bill, In general, users automatically get full ALTER access to their own output, so I doubt JESSPOOL is the issue. If they are attempting to delete output from within SDSF, they also need access to SDSF panels and operator commands. These are controlled by RACF profiles in the SDSF, GSDSF, and OPERCMDS classes, or if they are not protected by RACF, then by SDSF's ISFPARMS. You can use SDSF's SECTRACE to help debug the problem. Have a user execute SET SECTRACE ON or WTP at the SDSF command line (ON sends the results to ULOG; WTP to SYSLOG). Have the user attempt to delete output. Then, assuming they specified ON, have the user execute the ULOG command to see the RACF calls and their results. This assumes the user has authority to use ULOG - SDSF class resource ISFCMD.ODSP.ULOG.jesname or the ISFPARMS equivalent. Regards, Bob Robert S. Hansel Lead RACF Specialist RSH Consulting, Inc. 617-969-8211 www.linkedin.com/in/roberthansel www.twitter.com/RSH_RACF www.rshconsulting.com --- Upcoming RSH RACF Training - WebEx - RACF Audit & Compliance Roadmap - OCT 19-23, 2020 - RACF Level I Administration - APR 27 - MAY 1, 2020 - RACF Level II Administration - APR 6-10, 2020 - RACF Level III Admin, Audit, & Compliance - NOV 2-6, 2020 - RACF - Securing z/OS UNIX - SEPT 28 - OCT 2, 2020 --- -Original Message- Date: Thu, 12 Mar 2020 20:09:24 + From: Bill Johnson Subject: JESSPOOL I’m not a RACF expert and need help giving a user the ability to delete their own SDSF output. Not really sure why they don’t have it. Not my setup. Is it an easy 1 command fix or more complex? Thanks -- 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: JESSPOOL
Hi Bill, In general, users automatically get full ALTER access to their own output, so I doubt JESSPOOL is the issue. If they are attempting to delete output from within SDSF, they also need access to SDSF panels and operator commands. These are controlled by RACF profiles in the SDSF, GSDSF, and OPERCMDS classes, or if they are not protected by RACF, then by SDSF's ISFPARMS. You can use SDSF's SECTRACE to help debug the problem. Have a user execute SET SECTRACE ON or WTP at the SDSF command line (ON sends the results to ULOG; WTP to SYSLOG). Have the user attempt to delete output. Then, assuming they specified ON, have the user execute the ULOG command to see the RACF calls and their results. This assumes the user has authority to use ULOG - SDSF class resource ISFCMD.ODSP.ULOG.jesname or the ISFPARMS equivalent. Regards, Bob Robert S. Hansel Lead RACF Specialist RSH Consulting, Inc. 617-969-8211 www.linkedin.com/in/roberthansel www.twitter.com/RSH_RACF www.rshconsulting.com --- Upcoming RSH RACF Training - WebEx - RACF Audit & Compliance Roadmap - OCT 19-23, 2020 - RACF Level I Administration - APR 27 - MAY 1, 2020 - RACF Level II Administration - APR 6-10, 2020 - RACF Level III Admin, Audit, & Compliance - NOV 2-6, 2020 - RACF - Securing z/OS UNIX - SEPT 28 - OCT 2, 2020 --- -Original Message- Date:Thu, 12 Mar 2020 20:09:24 + From:Bill Johnson Subject: JESSPOOL I’m not a RACF expert and need help giving a user the ability to delete their own SDSF output. Not really sure why they don’t have it. Not my setup. Is it an easy 1 command fix or more complex? Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JESSPOOL
All, The SDSF team have been strongly advising that customers convert from ISFPARMS and ISFUSER to SAF security for many, many years. I would just like to stress how sensible it would be to start that process now if your site is still on SDSF internal security. Rob Scott Rocket Software -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: Thursday, March 12, 2020 11:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JESSPOOL EXTERNAL EMAIL Not all shops use SAF to control SDSF. If so, this advice is fine. If still using native ISFPARMS, the approach will need to be different, including some tweaking of the SDSF user exit if used. I'm surprised that any action at all is necessary for a user's own jobs... . . 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 Charles Mills Sent: Thursday, March 12, 2020 2:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: JESSPOOL CAUTION EXTERNAL EMAIL A *very* crude approach is to look at any RACF violation message on the console and translate that into a PERMIT command: PERMIT resource CL(class) ID(id) ACC(acc). There is typically a resource, a class and the access in the messages. You may have to apply some "intelligence" -- for example, if your shop may prefer to give permissions by GROUP rather than by individual userid. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RUCSA
Yes, RUCSA goes in units of 1 MB. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Martin Packer Sent: Thursday, March 12, 2020 6:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RUCSA That rather implies segment-level protection, rather than page. Cheers, Martin Martin Packer zChampion, Systems Investigator & Performance Troubleshooter, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2 Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Date: 12/03/2020 16:59 Subject:[EXTERNAL] Re: RUCSA Sent by:IBM Mainframe Discussion List RUCSA has to be allocated on a 1M boundary, so take that into consideration when looking at your virtual storage map. A RUCSA allocation below the line, if you don't also reduce CSA will result in the below the line private being reduced by 1M. Extended private isn't usually much of a concern. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://urldefense.proofpoint.com/v2/url?u=https-3A__api.protonmail.ch_pks_lookup-3Fop-3Dget-26search-3Dmarkjacobs-40protonmail.com=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=lNiQeZuiD4Q6umXm_yMCJWEXWafS72oqVI88BoMIYB8=3Ic9ZT6StCzl4I0XY0hY1sJAM4AoTn_emnlZJULRPI0= ‐‐‐ Original Message ‐‐‐ On Thursday, March 12, 2020 12:11 PM, Jousma, David <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > Thanks for clarifying Jim! > > Dave Jousma > > AVP | Manager, Systems Engineering > > Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 > > 616.653.8429 | fax: 616.653.2717 > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of Jim Mulder d10j...@us.ibm.com > Sent: Thursday, March 12, 2020 11:38:36 AM > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: RUCSA > > CAUTION EXTERNAL EMAIL > > DO NOT open attachments or click on links from unknown senders or unexpected emails > > For releases earlier than z/OS 2.4, RUCSA is provided by APAR OA56180. > > R790 PSY UA98722 UP19/03/28 P F903 > R7A0 PSY UA98723 UP19/03/28 P F903 > R7B0 PSY UA98724 UP19/03/28 P F903 > > publibz.boulder.ibm.com/zoslib/pdf/OA56180.pdf > > Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. > Poughkeepsie NY > > "IBM Mainframe Discussion List" IBM-MAIN@LISTSERV.UA.EDU wrote on > 03/12/2020 11:07:04 AM: > > > From: "Jousma, David" 01a0403c5dc1-dmarc-requ...@listserv.ua.edu > > To: IBM-MAIN@LISTSERV.UA.EDU > > Date: 03/12/2020 11:34 AM > > Subject: Re: RUCSA > > Sent by: "IBM Mainframe Discussion List" IBM-MAIN@LISTSERV.UA.EDU > > > The problem with RUCSA "feature" not being available in prior > > version (maybe it is, I just don’t see it), is that there is no path > > to convert into that prior to rolling V2.4. I guess all the > > prep work could be done (SAF rules, etc) ahead of time, but that > > would surely be a "must check out". The other problem with RUCSA > > is that if your offending/affected app requires below-the-line CSA, > > the minimum amount of RUCSA is 1MB, even if you only needed a few K > > for whatever you are doing. That will affect below-the-line > > private for sure. > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > CAUTION EXTERNAL EMAIL > > DO NOT open attachments or click on links from unknown senders or unexpected emails > This e-mail transmission contains information that is confidential and may be privileged. > It is intended only for the addressee(s) named above. If you receive this e-mail in error, > please do not read, copy or disseminate it in any manner. If you are not the intended > recipient, any disclosure, copying, distribution or use of the contents of this information > is prohibited. Please reply to the message immediately by informing the sender that the > message was misdirected. After replying, please erase it from your computer system. Your > assistance in correcting this error is appreciated. > > >
Re: RUCSA
We have it running on V2.2. Remember: it only remediates the userkey (E)CSA problem, nog the userkey dataspace problem. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Thursday, March 12, 2020 4:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RUCSA Yea. The idea is to remediate. We had one home grown automation tool that we retired (finally), and one vendor (FiServ) banking application that they have remediated, so we are clear to roll V2.4 to prod. The problem with RUCSA "feature" not being available in prior version (maybe it is, I just don’t see it), is that there is no path to convert into that *prior* to rolling V2.4.I guess all the prep work could be done (SAF rules, etc) ahead of time, but that would surely be a "must check out". The other problem with RUCSA is that if your offending/affected app requires below-the-line CSA, the minimum amount of RUCSA is 1MB, even if you only needed a few K for whatever you are doing. That will affect below-the-line private for sure. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Schwab Sent: Thursday, March 12, 2020 10:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RUCSA **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Well, any product that requires ALLOWUSERKEYCSA(YES) won't run on z/OS 2.4 until you do install it. On Thu, Mar 12, 2020 at 7:54 AM Dana Mitchell wrote: > > Is anyone using RUCSA yet? We currently have a very old ISV product that > requires running with ALLOWUSERKEYCSA(YES) on z/OS 2.2. As we prepare for > new hardware to support upgrade to z/OS 2.4, I'm faced with the possibility > of needing to run 2.4 with RUCSA if we cannot get an upgrade for this old > ISV product in time. > > I see RUCSA as orderable on ShopZ, just wondering, can it be ordered and > installed seperately or does it need to be ordered at the same time as the > z/OS 2.4 order? > > Thanks > Dana > > On Wed, 6 Nov 2019 19:38:33 +, Jousma, David wrote: > > >Folks, > > > >Remind me, is RUCSA support a chargeable feature? I find nothing in the > >manual, the only clue I find is it is a separate line-item in ShopZ, so > >thinking it may be chargeable, and enabled via IFAPRDxx? Just looking for > >a bit of confirmation > > > >_ > > > >Dave Jousma > >AVP | Manager, Systems Engineering > >[cid:image003.png@01D4F915.C9E34050] > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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
Re: RUCSA
Yes, it runs on V2.2. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Thursday, March 12, 2020 2:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RUCSA From the z/OS V2.4 announcement. Reading between the lines, I don’t think you can install this on lower version of z/OS, but maybe a quick support ticket would be in order. Also it is chargeable feature. Removal of user key common storage User key common storage is memory that can be updated by any unauthorized program. z/OS V2.4 no longer supports unrestricted user key common storage, thereby improving application isolation and security. PTFs for APARs OA53355 and OA56180 are available at lower releases to assist in migration and identification of programs accessing user key common storage. Removal of support of YES setting for VSM ALLOWUSERKEYCSA DIAGxx parmlib parameter: z/OS V2.3 will be the last release of z/OS to support the YES setting for the VSM ALLOWUSERKEYCSA DIAGxx parmlib parameter. If you run any software that requires the setting of this parameter to YES, the software will need to be changed to no longer require the setting of this parameter to YES or the optional priced RUCSA feature will be required. All IBM provided software should not require this setting. If you have any other non-IBM provided software that requires this setting, contact the owner of the software regarding this usage. Removal of support for obtaining user key CSA/ECSA storage: z/OS V2.4 does not support the usage of the GETMAIN, CPOOL, and STORAGE OBTAIN interfaces to obtain user key (8-15) CSA/ECSA storage. If you have any software that obtains user key CSA/ECSA storage, the software will need to be changed to no longer require this capability or the optional priced RUCSA feature will be required. Removal of support for obtaining user key CSA/ECSA storage: z/OS V2.4 does not support the usage of the GETMAIN, CPOOL, and STORAGE OBTAIN interfaces to obtain user key (8-15) CSA/ECSA storage. If you have any software that obtains user key CSA/ECSA storage, the software will need to be changed to no longer require this capability or the optional priced RUCSA feature will be required. Removal of support for changing Common ESQA (Subpool 247-248) storage to user key: z/OS V2.4 does not support the usage of the CHANGKEY interface to change Common ESQA (Subpool 247-248) storage to user key (8-15). If you have any software that changes Common ESQA (Subpool 247-248) storage to user key, the software will need to be changed to no longer require this capability. Removal of support of YES setting for ALLOWUSERKEYCADS DIAGxx parmlib parameter: z/OS V2.4 does not support the YES setting for the ALLOWUSERKEYCADS DIAGxx parmlib parameter. On prior releases, when ALLOWUSERKEYCADS(YES) is in effect, usage of the DSPSERV CREATE interface to create a SCOPE=COMMON data space in user key (8 -15) is supported. If you run any software that requires the setting of this parameter to YES, the software will need to be changed to no longer require the setting of this parameter to YES. All IBM provided software should not require this setting. If you have any other non-IBM provided software that requires this setting, contact the owner of the software regarding this usage. Removal of support for creating SCOPE=COMMON data spaces in user key: z/OS V2.4 does not support the usage of the DSPSERV CREATE interface to create a SCOPE=COMMON data space in user key (8 -15). If you have any software that creates a SCOPE=COMMON data space in user key, the software will need to be changed to no longer require this capability. Restricted Use Common Service Area (RUCSA) feature A new optional priced feature, RUCSA, is offered to enable clients to define a restricted use CSA (RUCSA) and manage it through SAF security protection. While avoiding user key common storage entirely is recommended, this feature enables clients who cannot update their applications that allocate user key CSA to gain enhanced protection without the need for application changes. Additionally, new health checks and instrumentation are added to track usage of this area. PTFs for APARs OA53355 and OA56180 are available at lower releases to assist in migration and identification of programs accessing user key common. _ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Richards, Robert B. Sent: Thursday, March 12, 2020 9:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RUCSA **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Does it come
Re: RUCSA
Yes, we do on V2.2, for the same reason: preparation for V2.4, for 2 applications that require userkey CSA. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dana Mitchell Sent: Thursday, March 12, 2020 1:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RUCSA Is anyone using RUCSA yet? We currently have a very old ISV product that requires running with ALLOWUSERKEYCSA(YES) on z/OS 2.2. As we prepare for new hardware to support upgrade to z/OS 2.4, I'm faced with the possibility of needing to run 2.4 with RUCSA if we cannot get an upgrade for this old ISV product in time. I see RUCSA as orderable on ShopZ, just wondering, can it be ordered and installed seperately or does it need to be ordered at the same time as the z/OS 2.4 order? Thanks Dana On Wed, 6 Nov 2019 19:38:33 +, Jousma, David wrote: >Folks, > >Remind me, is RUCSA support a chargeable feature? I find nothing in the >manual, the only clue I find is it is a separate line-item in ShopZ, so >thinking it may be chargeable, and enabled via IFAPRDxx? Just looking for a >bit of confirmation > >___ >__ >Dave Jousma >AVP | Manager, Systems Engineering >[cid:image003.png@01D4F915.C9E34050] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
