Re: Abend S0C4 in an internal sort
And we have a winner! Well spotted Frank. I made a simple change to the code and set RMODE 24 and the abends disappeared. Many thanks to everyone who responded. Staffan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Abend S0C4 in an internal sort
PS. Sorry Brian, you also spotted it but Frank was first :) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: Archaic allocation in JCL (Was: Physical record size query)
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Gibney, Dave Skickat: den 13 februari 2012 22:31 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg Sent: Monday, February 13, 2012 5:11 AM To: IBM-MAIN@bama.ua.edu Subject: SV: Archaic allocation in JCL (Was: Physical record size query) -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Lizette Koehler Skickat: den 13 februari 2012 12:43 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) I can't understand why we STILL need to specify SPACE= (etc) for an allocation of a dataset. You normally don't do that in other OS (platforms), You always (both principally and in practice) want to allocate as much as is needed during execution If for backward compatibility it can't be done automatically, why not introduce a new keyword like e g SPACE=ANY ? Thomas, IIRC - if you force a DATACLAS on a dataset in SMS, you can specify the Space requirements there. Then the JCL does not require Space. Have you looked at that? However, then that makes your storage admin responsible for ensuring the space is enough. And if needed alter the dataclass if there are space issues. And it would require all such datasets be SMS managed. Lizette Hi Lizette, In practice it's not a viable alternative. Besides the need (if doing it that way) to communicate frequently with the space gang, it's to many variants of datasetnames and to many different needs for space depending on time, date and subgrouping within applications. But, this is precisely what SMS and DATACLAS are for. It does accomplish, for the most part, SPACE=ANY. Not fully using SMS is so 80s' If so, do You really see everyone that creates and submits JCLs to create/change DATACLAS/STORCLAS instead of editing the SPACE= parms ? Or do You envision DATACLAS/STORCLAS's with very generous SPACE allocations (for every allocation) ? Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Changing sysplex hardware
Hello, we are moving data center to another location. The data is already there on DASD, replicated synchronously. We plan to stop the sysplex and IPL from the replicated data , on new processor. We pretty much answered all questions so far, except for the sysplex and CF. On new location we have one new processor, that will in the end replace one of the existing processors. The configuration (LPAR names) are the same, including CF. I would like to verify following scenario: 1. For fall-back purpose: We allocate new CFRM couple data sets and prepare new set of IPL parameters. Old ones will be used if we have to IPL at old location. 2. Activate new CDS 3. Change existing policy - define different HW for the existing CF 4. Start new policy - first question is - will it report an error or will it just have pending changes for CF? 5. Shut down system (sysplex) 6. IPL on new processor Would it be better option to define different name for CF on new processor, and just add a new CF to the active policy, and in all preference lists? I hope I was clear enough, any suggestion will be appreciated. Regards, Natasa -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: Archaic allocation in JCL (Was: Physical record size query)
Paul Gilmartin paulgboul...@aim.com wrote in message news:2205241542597622.wa.paulgboulderaim@bama.ua.edu... On Mon, 13 Feb 2012 16:23:14 +0100, R.S. wrote: The only application I know that manages extent size - that means using some algorithm for extent increase - is MQ Series aka Wbesphere MQ (since version 6 AFAIR). It would be nice to have such facility in DATACLASS. Nice indeed. And someone else suggested DB2 as another good performer. And now I may add to my list another example or two of IBM's having a good idea but implementing it in the wrong layer. This should have been done not in MQ and/or DB2, but in allocation where all applications could take advantage of it. All this could have been done without changing the specification of the VTOC and DSCB nor making incompatible changes to them. Conway's Law. -- gil There is no 'IBM', there is the z/OS lab, the MQ lab and the DB2 lab. If the DB2 lab needs something or has a good idea and the z/OS lab is not willing to implement it, the DB2 lab implements it itself (assuming they at least talk to each other). 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN
IPLTEXT query
Hi All, How to know that a specific SYSRES volume has the IPLTEXT in it ? Apology if my question doesn't makes any sense and it requires more information. Regards, Jakes -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IPLTEXT query
Try doing a print of track 0 of Cylinder 0. Stephen Mednick Computer Supervisory Services Sydney, Australia Asia/Pacific representatives for: Innovation Data Processing, Inc. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jake anderson Sent: Tuesday, 14 February 2012 10:21 PM To: IBM-MAIN@bama.ua.edu Subject: IPLTEXT query Hi All, How to know that a specific SYSRES volume has the IPLTEXT in it ? Apology if my question doesn't makes any sense and it requires more information. Regards, Jakes -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IPLTEXT query
We add the IPLTEXT to the volume prior to using it the first time. Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jake anderson Sent: Tuesday, 14 February 2012 10:21 PM To: IBM-MAIN@bama.ua.edu Subject: IPLTEXT query Hi All, How to know that a specific SYSRES volume has the IPLTEXT in it ? Apology if my question doesn't makes any sense and it requires more information. Regards, Jakes -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IPLTEXT query
Hi All, How to know that a specific SYSRES volume has the IPLTEXT in it ? Apology if my question doesn't makes any sense and it requires more information. Regards, Jakes So what have you found so far in your research? What specifically are you trying to find out? You might have several volumes with IPLTEXT on them. Which one are you looking for - SADUMP or IPL? For a current live environment or one not used any more? What process do you have in place to implement your IPLText? What version of z/OS (the dataset names have changed slightly over time)? I would use an Internet Search engine for IBM IPLTEXT and VOLUME. It should provide several entries to help you. For example this thread is interesting http://www.mail-archive.com/ibm-main@bama.ua.edu/msg22134.html Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
On 02/13/12 20:03, Jim Mulder wrote: snip Just to follow up on this, APAR OA38742 has been opened. This problem was introduced in z/OS 1.13. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN I tried to look at the apar in IBMLINK and received this error; An error has occurred: * An error occurred accessing the database: RPA0 401. Is it a security/integrity apar? -- Mark Jacobs Time Customer Service Tampa, FL Learn from yesterday, live for today, hope for tomorrow. The important thing is to not stop questioning. - Albert Einstein -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Archaic allocation in JCL (Was: Physical record size query)
But, this is precisely what SMS and DATACLAS are for. It does accomplish, for the most part, SPACE=ANY. Not fully using SMS is so 80s' If so, do You really see everyone that creates and submits JCLs to create/change DATACLAS/STORCLAS instead of editing the SPACE= parms ? Or do You envision DATACLAS/STORCLAS's with very generous SPACE allocations (for every allocation) ? Regards, Thomas Berg So the question becomes where to define space? The system cannot think like a human. It usually needs a place to start. So IBM provided some solutions. The LIKE parm in JCL The SMS DataClas functions The JCL SPACE parm I think it was amazing that IBM was able to eliminate the need for DCB=(x) and just let us use the subparms. For SPACE you are looking at old code that needs to be altered in CONVERTER, JES, ALLOCATION, IOS and probably more. It is old code and not likely to change in our lifetimes. I am also sure that if the developers in the 60's and 70's had any clue where computing was going, they might have thought harder on their designs. Remember when this was evolving we had restrictions that needed to be spelled out to the operating system. Therefore, this process (Space Allocation) needed to be definitely set. Remember, this came to us from MFT, MVT, SVS, and then MVS. And developers had to know what they were using and conserve the space usage. Everything was expensive back then. Instead maybe you need to look at a homegrown process that generates your JCL using META Data. Then if you have space problems, you can adapt your META Data or use products like SRS (DTS Software) or BMC Mainview SRM to monitor and dynamically grow or shrink a file as needed. Wait - we are back to your issue. Having to monitor and change something for space issues. That is where products like SRS and SRM are helpful. They monitor your system and if a space issue is about to happen, dynamically change the data allocations on the fly. Remember the old STOPX37? But, you also have issues because now you need to monitor the monitors and adjust them as space issues arise. Seems to me to be an infinite loop. Not one with a solution with today's tools. The issue of space is one of limitation of DASD space. If you have infinite storage, then over allocate everything in a Dataclass and not worry. If you have a constricted dasd environment, then keeping tight allocations will lead to space issues. So what do you want to manage - JCL or SMS code? Most shops review their allocations periodically and adjust their process. Either through SMS Dataclas or JCL. I know most shop would love to have a human thinking universe, however the computer is still fairly rudimentary. No Star Trek environment yet. ;-D If you truly want to see this type of issue resolved, then perhaps a SHARE requirement or Change request to IBM would be more effective? Just my $0.02 worth. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
Just to follow up on this, APAR OA38742 has been opened. This problem was introduced in z/OS 1.13. I tried to look at the apar in IBMLINK and received this error; An error has occurred: * An error occurred accessing the database: RPA0 401. Is it a security/integrity apar? I get the same error. If it is an integrity apar, then *all* ASM apars dealing with abend066 or ilrcpbld errors are integrity apars (as well as information apars). My guess is that the servicelink entry into the apar database is currently broken. I called support directly for the ASM/RSM shenanigans that we currently have (at z/OS 1.12) to see the apar text that SIS denied me and the ptf number. Barbara Nitz -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
I get the same error on OA38542 and OA37992, so I think it's just SIS itself. I opened a problem. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
No problem with me (in Belgium). *OA38742: DIFFERENCE in ASMIORQR / ASMIORQC COUNTS become LARGE ENOUGH to AFFECT FRAME STEAL PROCESSING and ASMIORQR INCREMENTED TOO HIGH* During AUX paging, I/O is scheduled to drive input and/or output I/O to auxiliary page packs. When an I/O error occurs and ASM I/O completion exit gets control in ILRCMP, the abnormal termination entry point ABNMTERM: gets control for the I/O error. When this happens, the ASM I/O is redriven, causing the ASVT ASM 'received' counts to be incremented twice, thus never allowing the 'completed' counts (ASMIORQC) to equal the 'received' counts (AMIORQR). If this continues for too long, the difference between the received-completed counts grows large enough to begin impacting RSM frame steal processing. Apar has just been openend for a few days, Barbara. - Submitted date 2012-02-09 - Last modified date 2012-02-10 Hence no PTF yet; no aparfix either. Jan - On Tue, Feb 14, 2012 at 1:29 PM, Barbara Nitz nitz-...@gmx.net wrote: Just to follow up on this, APAR OA38742 has been opened. This problem was introduced in z/OS 1.13. I tried to look at the apar in IBMLINK and received this error; An error has occurred: * An error occurred accessing the database: RPA0 401. Is it a security/integrity apar? I get the same error. If it is an integrity apar, then *all* ASM apars dealing with abend066 or ilrcpbld errors are integrity apars (as well as information apars). My guess is that the servicelink entry into the apar database is currently broken. I called support directly for the ASM/RSM shenanigans that we currently have (at z/OS 1.12) to see the apar text that SIS denied me and the ptf number. Barbara Nitz -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
5 Byte Device Addresses?
I'm wondering when 5 byte UCBs came into service and where this data comes from. UCBCHAN in a z/OS 1.12 and 13 system's MODGEN still shows as 2 bytes. How do you get 5 hex characters represented out of 2 bytes? D IPLINFO IEE254I 18.36.23 IPLINFO DISPLAY SYSTEM IPLED AT 17.34.39 ON 01/10/2012 RELEASE z/OS 01.12.00LICENSE = z/OS USED LOAD00 IN SYS1.IPLPARM ON 02020 ARCHLVL = 2 MTLSHARE = N IEASYM LIST = 00 IEASYS LIST = (00,01) (OP) IODF DEVICE: ORIGINAL(02020) CURRENT(02020) IPL DEVICE: ORIGINAL(03100) CURRENT(03100) VOLUME(SCARS1) I've looked at the IEE254I message in the doc but it just says... The device number of the volume where the I/O configuration ... The D U command still only shows 4 bytes. Any ideas? Dan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: NASA closes it's last mainframe
All, Very interesting article / blog, but anyone know why NASA pulled the plug on their last mainframe? Cost ? Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 13, 2012, at 1:48 PM, Bob Shannon bshan...@rocketsoftware.com wrote: One of my favorite SHARE sessions was in San Diego 2007 when Jan Green presented Space Shuttle Usage of z/OS. That was a really good session. I shared it with my then boss who had been a NASA flight controller. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Very Lage Page Datasets (was ASM and HiperPAV)
SIS seems to be working again. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Life of a JOB
Thanks, and thanks to Tony who took the time to scan his hardcopy. I am hoping to pass this on to our newer folks with the addition of which control blocks get created at each stage. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Kammer, Charles Sent: Monday, February 13, 2012 4:59 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Life of a JOB This may be a newer version of the 1974 presentation from SHARE 94, winter of 2000, session #2652 ftp://service.boulder.ibm.com/s390/jes2/Share94/JobRelatedExits.pdf Charles S. Kammer ckam...@bexar.org -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of zMan Sent: Monday, February 13, 2012 3:09 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Life of a JOB From 1974? I'd be surprised if it STARTED as softcopy back then. But maybe he's scanned it...I'd love to see it, too! On Mon, Feb 13, 2012 at 3:37 PM, Ward, Mike S mw...@ssfcu.org wrote: Anthony, if it's in softcopy would you please send me a copy? I would like to read it. TIA. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Sambataro, Anthony (NIH/NBS) [E] Sent: Monday, February 13, 2012 10:18 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Life of a JOB I have a copy of the following: The Life of a Job (and the Exits it Touches) From Share 74, March 1990 By Mark Laman of IBM 24 pages -Original Message- From: Veilleux, Jon L [mailto:veilleu...@aetna.com] Sent: Monday, February 13, 2012 10:29 AM To: IBM-MAIN@bama.ua.edu Subject: Life of a JOB I seem to remember an old SHARE presentation called (I believe) The Life of a JOB. I cannot find it in the SHARE proceedings because they only go back to 2005 and this is older than that. Would anyone happen to have a copy of this presentation? TIA, Jon This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.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...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
W dniu 2012-02-14 14:06, Dan D pisze: I'm wondering when 5 byte UCBs came into service and where this data comes from. UCBCHAN in a z/OS 1.12 and 13 system's MODGEN still shows as 2 bytes. How do you get 5 hex characters represented out of 2 bytes? D IPLINFO IEE254I 18.36.23 IPLINFO DISPLAY SYSTEM IPLED AT 17.34.39 ON 01/10/2012 RELEASE z/OS 01.12.00LICENSE = z/OS USED LOAD00 IN SYS1.IPLPARM ON 02020 ARCHLVL = 2 MTLSHARE = N IEASYM LIST = 00 IEASYS LIST = (00,01) (OP) IODF DEVICE: ORIGINAL(02020) CURRENT(02020) IPL DEVICE: ORIGINAL(03100) CURRENT(03100) VOLUME(SCARS1) I've looked at the IEE254I message in the doc but it just says... The device number of the volume where the I/O configuration ... The D U command still only shows 4 bytes. Any ideas? 1. 5-byte device address can be misunderstood. There is no simple support for 5-byte addresses, the fifth byte have to be zero for most devices. Also, in many places you can use only 4-byte (or 0) addresses. 2. Subchannel Set 1 was introduced in z9 (2094) and AFAIR z/OS 1.7. 3. Support for 5-byte adresses is growing up constantly, for example at the time of z9 and z/OS 1.7 there was no possibility to IPL from 1 devices, there was no SS2, the only supported devices in SS1 were aliases. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
On this DISPLAY of IPLINFO, the first position is the channel set, the last four the device address. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of R.S. Sent: Tuesday, February 14, 2012 8:29 AM To: IBM-MAIN@bama.ua.edu Subject: Re: 5 Byte Device Addresses? W dniu 2012-02-14 14:06, Dan D pisze: I'm wondering when 5 byte UCBs came into service and where this data comes from. UCBCHAN in a z/OS 1.12 and 13 system's MODGEN still shows as 2 bytes. How do you get 5 hex characters represented out of 2 bytes? D IPLINFO IEE254I 18.36.23 IPLINFO DISPLAY SYSTEM IPLED AT 17.34.39 ON 01/10/2012 RELEASE z/OS 01.12.00LICENSE = z/OS USED LOAD00 IN SYS1.IPLPARM ON 02020 ARCHLVL = 2 MTLSHARE = N IEASYM LIST = 00 IEASYS LIST = (00,01) (OP) IODF DEVICE: ORIGINAL(02020) CURRENT(02020) IPL DEVICE: ORIGINAL(03100) CURRENT(03100) VOLUME(SCARS1) I've looked at the IEE254I message in the doc but it just says... The device number of the volume where the I/O configuration ... The D U command still only shows 4 bytes. Any ideas? 1. 5-byte device address can be misunderstood. There is no simple support for 5-byte addresses, the fifth byte have to be zero for most devices. Also, in many places you can use only 4-byte (or 0) addresses. 2. Subchannel Set 1 was introduced in z9 (2094) and AFAIR z/OS 1.7. 3. Support for 5-byte adresses is growing up constantly, for example at the time of z9 and z/OS 1.7 there was no possibility to IPL from 1 devices, there was no SS2, the only supported devices in SS1 were aliases. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: NASA closes it's last mainframe
On 14 Feb 2012 05:14:23 -0800, in bit.listserv.ibm-main you wrote: All, Very interesting article / blog, but anyone know why NASA pulled the plug on their last mainframe? Cost ? My guess is that the applications they wanted to run had better software and hardware support on other platforms. Support for scientific and compute intensive application probably has not kept up on the mainframe. Clark Morris Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 13, 2012, at 1:48 PM, Bob Shannon bshan...@rocketsoftware.com wrote: One of my favorite SHARE sessions was in San Diego 2007 when Jan Green presented Space Shuttle Usage of z/OS. That was a really good session. I shared it with my then boss who had been a NASA flight controller. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: NASA closes it's last mainframe
No, They are using Russian platforms for space flights (soon on Virgin)... ;-) No need for software or hardware. all supplied by the Russian space industry. (I am jocking, of course). ITschak On Tue, Feb 14, 2012 at 3:13 PM, Scott Ford scott_j_f...@yahoo.com wrote: All, Very interesting article / blog, but anyone know why NASA pulled the plug on their last mainframe? Cost ? Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 13, 2012, at 1:48 PM, Bob Shannon bshan...@rocketsoftware.com wrote: One of my favorite SHARE sessions was in San Diego 2007 when Jan Green presented Space Shuttle Usage of z/OS. That was a really good session. I shared it with my then boss who had been a NASA flight controller. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Abend S0C4 in an internal sort
In 1020628937438662.wa.stylenpfoneconsulting@bama.ua.edu, on 02/13/2012 at 11:31 AM, Staffan Tylen sty...@pf-one-consulting.com said: So, who is the first to spot the obvious flaw that I can't see? Does the sort expect a non-standard plist? Should the 4rh word be A(=F'-1')+X'8000'? -- 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Workload Manager Performance
Cheryl Watson's Quick Start policy is a good place to begin for the WLM policy. RMF Mon III (SYSPLEX SUMMARY) and RMF Mon I (Post Processor) SYSRPTS(WLMGL(SCLASS,SCPER)) will show you how things are running. HTH, snip Is there any utilities that can be used to monitor WLM? Also, is there any utilities that can help you setup your WLM environment? Just trying to determine if our WLM is setup correctly for our shop. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: Archaic allocation in JCL (Was: Physical record size query)
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Lizette Koehler Skickat: den 14 februari 2012 13:27 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) But, this is precisely what SMS and DATACLAS are for. It does accomplish, for the most part, SPACE=ANY. Not fully using SMS is so 80s' If so, do You really see everyone that creates and submits JCLs to create/change DATACLAS/STORCLAS instead of editing the SPACE= parms ? Or do You envision DATACLAS/STORCLAS's with very generous SPACE allocations (for every allocation) ? Regards, Thomas Berg So the question becomes where to define space? The system cannot think like a human. It usually needs a place to start. So IBM provided some solutions. Please! Requirement of space do not need any thinking. It answers itself during the execution. The LIKE parm in JCL If You have and remember the appropriate dataset. And this is not much better than using SPACE=. The SMS DataClas functions Se my post above. The JCL SPACE parm Which caused my choice of subject: Archaic... I think it was amazing that IBM was able to eliminate the need for DCB=(x) and just let us use the subparms. For SPACE you are looking at old code that needs to be altered in CONVERTER, JES, ALLOCATION, IOS and probably more. It is old code and not likely to change in our lifetimes. AFAICS, what needs to be changed is just the interpretation of the SPACE parm and the actual allocation on disk at the time of execution. - There have been changes in the JCL language the latest Years: LIKE, DCB subparms outside of the DCB parm, etc. This could obviously be done. - There can't be that many places that does the allocation of the space on disk. Note that there is no change of cataloging as such, just the process of adding/extending the extents as the dataset is expanding. There is no need to change the old code more than allowing a branch to the new code to handle the case of the new variant of the SPACE parm. snip Wait - we are back to your issue. Having to monitor and change something for space issues. That is where products like SRS and SRM are helpful. They monitor your system and if a space issue is about to happen, dynamically change the data allocations on the fly. Remember the old STOPX37? But, you also have issues because now you need to monitor the monitors and adjust them as space issues arise. Here we are back to how we look at the space allocation process. You seems to see it as a complicated process - or at least an intellectually demanding logic. For me it's something I can do in my sleep. (It's just a loop of changing the SPACE parms until it works = no B37 etc.) How could this be other that a VSMOP ? snip If you truly want to see this type of issue resolved, then perhaps a SHARE requirement or Change request to IBM would be more effective? Well, with more effective You seem to assume that I'm trying to get something realized. But this was/begun as an opinion from me to the ongoing discussions in this list regarding enhancements of MVS. For a realization of something like this and as working in a Swedish company (which AFAIK is not a SHARE member) I have to rely on other participants on this list that are SHARE members. (A request by me to IBM needs accompanying money...) Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Changing sysplex hardware
It is not clear if you are moving the entire SYSPLEX, or merely one or more of the members. It you are moving the entire SYSPLEX, perhaps a SYSPLEX wide restart is appropriate. However, even if you are moving one or more members of the SYSPLEX, why not use the standard SYSPLEX facilities to assist in the move? (IIRC, a parallel sysplex can communicate over about 20 km(??) without special accommodations e.g. GDPS). Your original SYSPELX CDS's will be intact, so no action should be necessary if you need to revert to the original location, just IPL and go. I would create new CDS's/policies for the new location. HTH, snip From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Natasa Savinc Sent: Tuesday, February 14, 2012 4:11 AM To: IBM-MAIN@bama.ua.edu Subject: Changing sysplex hardware Hello, we are moving data center to another location. The data is already there on DASD, replicated synchronously. We plan to stop the sysplex and IPL from the replicated data , on new processor. We pretty much answered all questions so far, except for the sysplex and CF. On new location we have one new processor, that will in the end replace one of the existing processors. The configuration (LPAR names) are the same, including CF. I would like to verify following scenario: 1. For fall-back purpose: We allocate new CFRM couple data sets and prepare new set of IPL parameters. Old ones will be used if we have to IPL at old location. 2. Activate new CDS 3. Change existing policy - define different HW for the existing CF 4. Start new policy - first question is - will it report an error or will it just have pending changes for CF? 5. Shut down system (sysplex) 6. IPL on new processor Would it be better option to define different name for CF on new processor, and just add a new CF to the active policy, and in all preference lists? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: NASA closes it's last mainframe
It's hack, That was funny, I liked that Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 14, 2012, at 8:56 AM, Itschak Mugzach imugz...@gmail.com wrote: No, They are using Russian platforms for space flights (soon on Virgin)... ;-) No need for software or hardware. all supplied by the Russian space industry. (I am jocking, of course). ITschak On Tue, Feb 14, 2012 at 3:13 PM, Scott Ford scott_j_f...@yahoo.com wrote: All, Very interesting article / blog, but anyone know why NASA pulled the plug on their last mainframe? Cost ? Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 13, 2012, at 1:48 PM, Bob Shannon bshan...@rocketsoftware.com wrote: One of my favorite SHARE sessions was in San Diego 2007 when Jan Green presented Space Shuttle Usage of z/OS. That was a really good session. I shared it with my then boss who had been a NASA flight controller. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
z/OS R13 Migration Refresh Information Available!
Hello IBM-MAINers, I've had several questions about when the latest updates to the z/OS R13 Migration books would be available. I'm happy to say that they are now available near the bottom of this page on this website: http://www-03.ibm.com/systems/z/os/zos/installation/index.html . Look for the -20 level of the books, which indicates that you've got the latest level for z/OS R13. Note that there are three forms of the book available at this website: 1) the regular book update, this book covers both the R11-R13 and the R12-R13 migration paths. 2) the customized R11-R13 book, this book covers only the R11-R13 path. This book is very similar to the regular book, except for one migration action from a new function introduced in R12 that is not applicable to the R11-R13 path. 3) the customized R12-R13 book, this book covers only the R12-R13 path, and is smaller in size since the R11 migration actions have been omitted. Thanks, Marna WALLE z/OS Installation IBM Poughkeepsie -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: NASA closes it's last mainframe
Meant to say Itschak that's funny, liked it Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 14, 2012, at 8:56 AM, Itschak Mugzach imugz...@gmail.com wrote: No, They are using Russian platforms for space flights (soon on Virgin)... ;-) No need for software or hardware. all supplied by the Russian space industry. (I am jocking, of course). ITschak On Tue, Feb 14, 2012 at 3:13 PM, Scott Ford scott_j_f...@yahoo.com wrote: All, Very interesting article / blog, but anyone know why NASA pulled the plug on their last mainframe? Cost ? Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 13, 2012, at 1:48 PM, Bob Shannon bshan...@rocketsoftware.com wrote: One of my favorite SHARE sessions was in San Diego 2007 when Jan Green presented Space Shuttle Usage of z/OS. That was a really good session. I shared it with my then boss who had been a NASA flight controller. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SmartFTP and MVS files
For some reason the magical combination of characters necessary to get SmartFTP to move an MVS file is escaping me. I have tried all combinations of double quotes, single quotes, periods after the first qalifier, etc to no avail. The filename still shows up in the CWD with a '/' in front of the file name. This is version 4 of SmartFTP. Can anybody shed some light on this? Thanks, Neal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Archaic allocation in JCL (Was: Physical record size query)
On Tue, 14 Feb 2012 07:26:38 -0500, Lizette Koehler wrote: I think it was amazing that IBM was able to eliminate the need for DCB=(x) and just let us use the subparms. My conjecture is that the UNIX file systems provided the impetus for this. The designers wanted to allow RECFM, LRECL, and BLKSIZE with PATH=, but prohibit other subparameters. There was no mechanism to make one parameter mutex with a subparameter of a different parameter, and it was easier to allow the bare attributes than to devise the needed mutex. Or does the chronology and other evidence refute this? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: Archaic allocation in JCL (Was: Physical record size query)
On Tue, 14 Feb 2012 11:28:58 +0100, Vernooij, CP - SPLXM wrote: Paul Gilmartin wrote in message And now I may add to my list another example or two of IBM's having a good idea but implementing it in the wrong layer. This should have been done not in MQ and/or DB2, but in allocation where all applications could take advantage of it. All this could have been done without changing the specification of the VTOC and DSCB nor making incompatible changes to them. Conway's Law. There is no 'IBM', there is the z/OS lab, the MQ lab and the DB2 lab. If the DB2 lab needs something or has a good idea and the z/OS lab is not willing to implement it, the DB2 lab implements it itself (assuming they at least talk to each other). That's a close paraphrase of my surmise of Conway's Law. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Abend S0C4 in an internal sort
Shmuel (Seymour J.) Metz at IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 02/13/2012 07:25:11 PM: Does the sort expect a non-standard plist? Should the 4rh word be A(=F'-1')+X'8000'? The end of the extended parameter list is indicated by a F'-1' (X'') word. For details, see: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ICE1CA60/6.7.1.1?SHELF=DT=20110608113434 Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration = DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Any way to get the XLC compiler to list all #define symbols?
Does anyone know of a way to get the XLC compiler to list all of the #define symbols that are in effect? XREF and ATTR list all ordinary symbols. There are several ways of course of determining the define state of any particular #define symbol. But does anyone know of an option or a trick to get a list of all of them? Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SmartFTP and MVS files
The way to reference a MVS file in most unix commands is: //'mvs.file.name' Maybe SmartFTP does the same. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Neal Eckhardt Sent: Tuesday, February 14, 2012 11:10 AM To: IBM-MAIN@bama.ua.edu Subject: SmartFTP and MVS files For some reason the magical combination of characters necessary to get SmartFTP to move an MVS file is escaping me. I have tried all combinations of double quotes, single quotes, periods after the first qalifier, etc to no avail. The filename still shows up in the CWD with a '/' in front of the file name. This is version 4 of SmartFTP. Can anybody shed some light on this? Thanks, Neal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: System Dumps and SMS allocation fails
Well the problem has been solved, thanks to all for their thoughts. I removed the space and DCB attributes, except for the DSNTYPE=LARGE from the dataclass and all is well. Not quite sure why, but whatever works. Ken Leidner kleid...@earthlink.net -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Abend S0C4 in an internal sort
At 22:25 -0500 on 02/13/2012, Shmuel Metz (Seymour J.) wrote about Re: Abend S0C4 in an internal sort: Does the sort expect a non-standard plist? Should the 4rh word be A(=F'-1')+X'8000'? That +X'8000' is not needed (and can cause problems) since F'-1' has set the high bit already - F'-1 = X''. I think that it has been determined that if you want RMODE ANY, the exit addresses need to have the +X'8000' added (or go with RMODE 24). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Abend S0C4 in an internal sort
since F'-1' has set the high bit already ... but A(=F'-1') does not -- it is the very ordinary address of a constant F'-1' in the literal pool. Not that it matters ... Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Robert A. Rosenberg Sent: Tuesday, February 14, 2012 10:37 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Abend S0C4 in an internal sort At 22:25 -0500 on 02/13/2012, Shmuel Metz (Seymour J.) wrote about Re: Abend S0C4 in an internal sort: Does the sort expect a non-standard plist? Should the 4rh word be A(=F'-1')+X'8000'? That +X'8000' is not needed (and can cause problems) since F'-1' has set the high bit already - F'-1 = X''. I think that it has been determined that if you want RMODE ANY, the exit addresses need to have the -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: NASA closes it's last mainframe
Yeah, but the inverse femtobarns of data needs processing too! In a message dated 2/14/2012 7:50:18 A.M. Central Standard Time, cfmpub...@ns.sympatico.ca writes: Support for scientific and compute intensive application probably has not kept up on the mainframe. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: Archaic allocation in JCL (Was: Physical record size query)
On 2/14/2012 9:42 AM, Thomas Berg wrote: AFAICS, what needs to be changed is just the interpretation of the SPACE parm and the actual allocation on disk at the time of execution. - There have been changes in the JCL language the latest Years: LIKE, DCB subparms outside of the DCB parm, etc. This could obviously be done. - There can't be that many places that does the allocation of the space on disk. Note that there is no change of cataloging as such, just the process of adding/extending the extents as the dataset is expanding. There is no need to change the old code more than allowing a branch to the new code to handle the case of the new variant of the SPACE parm. You may think of your request as being reasonable, but a new SPACE parameter could be added in less time than this thread has been going. There is no one place where old code can be branched away from, rather space/extent processing is endemic in all DASD related code. More critically, most I/O related control blocks have physical limits, and would require major redesign to handle even static expansion, not to mention dynamic. By comparison, supporting FBA devices in zOS would have been trivial, but IBM could not justify that, either. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: Archaic allocation in JCL (Was: Physical record size query)
Thomas, I've done this with DFSMS for a large, multi-country application where the developers simply coded UNIT=SMALL, MEDIUM, LARGE and HUGE in the JCL. The ACS routines took this UNIT value, along with some other logic and assigned a standard space allocation using the appropriate DATACLAS. The size for each DATACLAS was different for the DEV, UNIT and PROD environments, which allowed them to use the same JCL for these different environments. We did protect successful allocation with UNITCNT=5 and some ACC. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg Sent: Monday, February 13, 2012 5:11 AM To: IBM-MAIN@bama.ua.edu Subject: [IBM-MAIN] SV: Archaic allocation in JCL (Was: Physical record size query) -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Lizette Koehler Skickat: den 13 februari 2012 12:43 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) I can't understand why we STILL need to specify SPACE= (etc) for an allocation of a dataset. You normally don't do that in other OS (platforms), You always (both principally and in practice) want to allocate as much as is needed during execution If for backward compatibility it can't be done automatically, why not introduce a new keyword like e g SPACE=ANY ? Thomas, IIRC - if you force a DATACLAS on a dataset in SMS, you can specify the Space requirements there. Then the JCL does not require Space. Have you looked at that? However, then that makes your storage admin responsible for ensuring the space is enough. And if needed alter the dataclass if there are space issues. And it would require all such datasets be SMS managed. Lizette Hi Lizette, In practice it's not a viable alternative. Besides the need (if doing it that way) to communicate frequently with the space gang, it's to many variants of datasetnames and to many different needs for space depending on time, date and subgrouping within applications. Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Changing sysplex hardware
Since you are moving the entire datacenter and all dasd is already replicated, then. Old location: 1. Shut down your existing systems. Old location prefered. 2. Break dasd replications. New location. 3. IPL one system. 4. Start Sysplex using your new datasets. 5. IPL the other systems. Backout: New location 6. Shut down your systems at new locations. Old Location. 7. IPL one system. 8. Start Sysplex using your old datasets. 9 IPL the other systems When up: 10. Restart replication from scratch for next try. The secondaries will have been updated (access date at a minimum), so restarting a suspended replication would result in bad volumes. On Tue, Feb 14, 2012 at 8:43 AM, Staller, Allan allan.stal...@kbmg.com wrote: It is not clear if you are moving the entire SYSPLEX, or merely one or more of the members. It you are moving the entire SYSPLEX, perhaps a SYSPLEX wide restart is appropriate. However, even if you are moving one or more members of the SYSPLEX, why not use the standard SYSPLEX facilities to assist in the move? (IIRC, a parallel sysplex can communicate over about 20 km(??) without special accommodations e.g. GDPS). Your original SYSPELX CDS's will be intact, so no action should be necessary if you need to revert to the original location, just IPL and go. I would create new CDS's/policies for the new location. HTH, snip From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Natasa Savinc Sent: Tuesday, February 14, 2012 4:11 AM To: IBM-MAIN@bama.ua.edu Subject: Changing sysplex hardware Hello, we are moving data center to another location. The data is already there on DASD, replicated synchronously. We plan to stop the sysplex and IPL from the replicated data , on new processor. We pretty much answered all questions so far, except for the sysplex and CF. On new location we have one new processor, that will in the end replace one of the existing processors. The configuration (LPAR names) are the same, including CF. I would like to verify following scenario: 1. For fall-back purpose: We allocate new CFRM couple data sets and prepare new set of IPL parameters. Old ones will be used if we have to IPL at old location. 2. Activate new CDS 3. Change existing policy - define different HW for the existing CF 4. Start new policy - first question is - will it report an error or will it just have pending changes for CF? 5. Shut down system (sysplex) 6. IPL on new processor Would it be better option to define different name for CF on new processor, and just add a new CF to the active policy, and in all preference lists? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/OS R13 Migration Refresh Information Available!
Hey Marna, Back to the future? *This is a major revision to GA22-7499-19 as updated April 2012. * (sic) ;-) jan On Tue, Feb 14, 2012 at 3:54 PM, Marna WALLE mwa...@us.ibm.com wrote: Hello IBM-MAINers, I've had several questions about when the latest updates to the z/OS R13 Migration books would be available. I'm happy to say that they are now available near the bottom of this page on this website: http://www-03.ibm.com/systems/z/os/zos/installation/index.html . Look for the -20 level of the books, which indicates that you've got the latest level for z/OS R13. Note that there are three forms of the book available at this website: 1) the regular book update, this book covers both the R11-R13 and the R12-R13 migration paths. 2) the customized R11-R13 book, this book covers only the R11-R13 path. This book is very similar to the regular book, except for one migration action from a new function introduced in R12 that is not applicable to the R11-R13 path. 3) the customized R12-R13 book, this book covers only the R12-R13 path, and is smaller in size since the R11 migration actions have been omitted. Thanks, Marna WALLE z/OS Installation IBM Poughkeepsie -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Changing sysplex hardware
Mike, Wouldn't number 10 be a massive amount of unnecessary work and replication? I was under the impression that if you had replication going between the two arrays and you suspended the replication, that you could bring up the replication targets in a read/write mode on the new servers. If you had to back out, after shutting the new servers down, you could unsuspend the replication and data that had changed on the source volumes would be replicated to the targets, and data on the targets that had changed would also have the source data pushed to overlay the changed targets. Is this not how replication works? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Schwab Sent: Tuesday, February 14, 2012 2:59 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Changing sysplex hardware Since you are moving the entire datacenter and all dasd is already replicated, then. Old location: 1. Shut down your existing systems. Old location prefered. 2. Break dasd replications. New location. 3. IPL one system. 4. Start Sysplex using your new datasets. 5. IPL the other systems. Backout: New location 6. Shut down your systems at new locations. Old Location. 7. IPL one system. 8. Start Sysplex using your old datasets. 9 IPL the other systems When up: 10. Restart replication from scratch for next try. The secondaries will have been updated (access date at a minimum), so restarting a suspended replication would result in bad volumes. On Tue, Feb 14, 2012 at 8:43 AM, Staller, Allan allan.stal...@kbmg.com wrote: It is not clear if you are moving the entire SYSPLEX, or merely one or more of the members. It you are moving the entire SYSPLEX, perhaps a SYSPLEX wide restart is appropriate. However, even if you are moving one or more members of the SYSPLEX, why not use the standard SYSPLEX facilities to assist in the move? (IIRC, a parallel sysplex can communicate over about 20 km(??) without special accommodations e.g. GDPS). Your original SYSPELX CDS's will be intact, so no action should be necessary if you need to revert to the original location, just IPL and go. I would create new CDS's/policies for the new location. HTH, snip From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Natasa Savinc Sent: Tuesday, February 14, 2012 4:11 AM To: IBM-MAIN@bama.ua.edu Subject: Changing sysplex hardware Hello, we are moving data center to another location. The data is already there on DASD, replicated synchronously. We plan to stop the sysplex and IPL from the replicated data , on new processor. We pretty much answered all questions so far, except for the sysplex and CF. On new location we have one new processor, that will in the end replace one of the existing processors. The configuration (LPAR names) are the same, including CF. I would like to verify following scenario: 1. For fall-back purpose: We allocate new CFRM couple data sets and prepare new set of IPL parameters. Old ones will be used if we have to IPL at old location. 2. Activate new CDS 3. Change existing policy - define different HW for the existing CF 4. Start new policy - first question is - will it report an error or will it just have pending changes for CF? 5. Shut down system (sysplex) 6. IPL on new processor Would it be better option to define different name for CF on new processor, and just add a new CF to the active policy, and in all preference lists? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.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...@bama.ua.edu with the message: INFO IBM-MAIN The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Looking for an old macro library
Somewhere along the line we deleted an old macro library for a product called SSNAME3 from Search Software America called .H. It is used when assembling the libraries. We have the other libraries, but not that one. I imagine what happened is that the library got archived off and was not accessed in 7 years and fell off the end of the world. And of course, we have a user who needs to reassemble a table and needs this library. We are current on maintenance with the vendor, but we are so back level on versions and they say they don't have the 1.7 version of this macro library anymore. Anyone by chance have it they can send it? I don't need the .CNTL or .LOAD, just the .H You can contact me offline. Thanks, Dennis -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Simple iinventory control products?
Ed, That's who I was talking about, too - people who support and work with their products. Regards, Greg -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ed Gould Sent: Tuesday, February 14, 2012 12:23 AM Greg: I should have been more specific but I was taking about people who had to support and work with their products. I remember specifically at SHARE several conversations, McKinney came up and the best they got was yea somebody bought it and didnt go through the software selection commee and they got grandfathered in otherwise we wouldn't even consider them. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Changing sysplex hardware
Resync after the secondary volume is updated? If the mirroring software supports that, it would save a lot of retransmitting. I am fairly sure the ESS F20 and 800 PPRC did not have that, and the user did not say what he is using to mirror. But you only need that after a backout after running at the new site. On Tue, Feb 14, 2012 at 3:54 PM, Pommier, Rex R. rex.pomm...@cnasurety.com wrote: Mike, Wouldn't number 10 be a massive amount of unnecessary work and replication? I was under the impression that if you had replication going between the two arrays and you suspended the replication, that you could bring up the replication targets in a read/write mode on the new servers. If you had to back out, after shutting the new servers down, you could unsuspend the replication and data that had changed on the source volumes would be replicated to the targets, and data on the targets that had changed would also have the source data pushed to overlay the changed targets. Is this not how replication works? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Schwab Sent: Tuesday, February 14, 2012 2:59 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Changing sysplex hardware Since you are moving the entire datacenter and all dasd is already replicated, then. Old location: 1. Shut down your existing systems. Old location prefered. 2. Break dasd replications. New location. 3. IPL one system. 4. Start Sysplex using your new datasets. 5. IPL the other systems. Backout: New location 6. Shut down your systems at new locations. Old Location. 7. IPL one system. 8. Start Sysplex using your old datasets. 9 IPL the other systems When up: 10. Restart replication from scratch for next try. The secondaries will have been updated (access date at a minimum), so restarting a suspended replication would result in bad volumes. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IBM researchers make 12-atom magnetic memory bit
I have one card - punched with the eternal single finger salute! Fun times ... On Tue, Jan 17, 2012 at 2:02 PM, Rick Fochtman rfocht...@ync.net wrote: Anyone remember the 96-column cards? I'd like to find a box of them. Rick --**-- On 1/16/2012 10:13 PM, Mohd Rizwan wrote: Quite interesting On Sun, Jan 15, 2012 at 8:49 PM, Scott Fordscott_j_f...@yahoo.com wrote: Linda, This development is simply amazingas a dinosaur of the original 80 column card age ...things have really changed, big time Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Jan 15, 2012, at 1:42 AM, Linda MooneyLinda.lstsrv@COMCAST.**NETlinda.lst...@comcast.net wrote: Hi zMan, Ah, well, whatz a couple of typpos among firends? :) Linda - Original Message - From: zManzedgarhoo...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Saturday, January 14, 2012 9:13:24 PM Subject: Re: IBM researchers make 12-atom magnetic memory bit On Sat, Jan 14, 2012 at 11:55 PM, Linda MooneyLinda.lstsrv@comcast.** net linda.lst...@comcast.net wrote: Hi John and Ed, Yowsers! That's really tiny! Just in my career - The first machine I was paid to work with was a 4341 with 8MB and 8 channels. My IPhone has 32MB. The possibilities of 2.5 Petabytes is, well, an awful lot. I can't help but wonder what some of the early computing pioneers would think of this. I suspect your iPhone has 32GB, not MB... And let's not start swapping You had 8MB? We had 5 bytes...and we LOVED it! stories, eh? Related, however: this could make a reality something I read a while ago suggestion that memory would soon be cheap enough that we could have HD video of our surroundings recording constantly. This could/would change things a fair bit, both good and bad. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN --**--** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN --**--** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Changing sysplex hardware
There are two sides to the sysplex coin: one lives on DASD, the other lives in the CF. As long as DASD is fully replicated, the newly IPLed sysplex member(s) should look exactly like the old. CF is another matter. In the CFRM policy, each CF is identified by a unique combination of properties: 1. NAME 2. TYPE (model) 3. SEQUENCE (serial number) 4. PARTITION (number) NAME is used throughout the policy to specify structure location. TYPE, SEQUENCE, and PARTITION are used at XCF initialization to identify the hardware to be used for CF structures associated with NAME. If all four properties are different in the new location, the easiest migration path is to create--today--a CFRM policy that includes the new CF in addition to the old CF(s). Include the new NAME in all structure PREFLISTs. XCF in the old location will not be flummoxed that the new CF is unreachable. Likewise in the new location XCF will survive without access to the old CF(s). In this way you can IPL into the mirrored DASD complex with little disruption. Since you have the same CFRM policy throughout, fallback should be as simple as IPLing in the old location. Caveat: be absolutely sure that you're happy with your new home before allowing production updates to occur. Consider that replicating updates back to the old location is essentially a lost cause. Check everything out as thoroughly as possible while users are locked out. Once you let them out on the range, you'll never get them back in the barn. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@bama.ua.edu Date: 02/14/2012 02:09 PM Subject:Re: Changing sysplex hardware Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Resync after the secondary volume is updated? If the mirroring software supports that, it would save a lot of retransmitting. I am fairly sure the ESS F20 and 800 PPRC did not have that, and the user did not say what he is using to mirror. But you only need that after a backout after running at the new site. On Tue, Feb 14, 2012 at 3:54 PM, Pommier, Rex R. rex.pomm...@cnasurety.com wrote: Mike, Wouldn't number 10 be a massive amount of unnecessary work and replication? I was under the impression that if you had replication going between the two arrays and you suspended the replication, that you could bring up the replication targets in a read/write mode on the new servers. If you had to back out, after shutting the new servers down, you could unsuspend the replication and data that had changed on the source volumes would be replicated to the targets, and data on the targets that had changed would also have the source data pushed to overlay the changed targets. Is this not how replication works? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Schwab Sent: Tuesday, February 14, 2012 2:59 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Changing sysplex hardware Since you are moving the entire datacenter and all dasd is already replicated, then. Old location: 1. Shut down your existing systems. Old location prefered. 2. Break dasd replications. New location. 3. IPL one system. 4. Start Sysplex using your new datasets. 5. IPL the other systems. Backout: New location 6. Shut down your systems at new locations. Old Location. 7. IPL one system. 8. Start Sysplex using your old datasets. 9 IPL the other systems When up: 10. Restart replication from scratch for next try. The secondaries will have been updated (access date at a minimum), so restarting a suspended replication would result in bad volumes. -- Mike A Schwab, Springfield IL USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IPLTEXT query
If you're at all unsure, by far the easiest procedure is simply to (re)write the appropriate IPL text on the volume in question. Even if evidence of IPL text is found by means suggested by others, how do you know it's the right flavor? IPL text gets modified periodically by PTF, especially SAD text. When you rewrite new text, ICKDSF will warn you that text already exists. Just write over it. Spend a little extra Valentine fun with your S.O. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Lizette Koehler stars...@mindspring.com To: IBM-MAIN@bama.ua.edu Date: 02/14/2012 03:50 AM Subject:Re: IPLTEXT query Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Hi All, How to know that a specific SYSRES volume has the IPLTEXT in it ? Apology if my question doesn't makes any sense and it requires more information. Regards, Jakes So what have you found so far in your research? What specifically are you trying to find out? You might have several volumes with IPLTEXT on them. Which one are you looking for - SADUMP or IPL? For a current live environment or one not used any more? What process do you have in place to implement your IPLText? What version of z/OS (the dataset names have changed slightly over time)? I would use an Internet Search engine for IBM IPLTEXT and VOLUME. It should provide several entries to help you. For example this thread is interesting http://www.mail-archive.com/ibm-main@bama.ua.edu/msg22134.html Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IPLTEXT query
It's all part of the BUILD process. IPLTEXT on SYSRES, SADUMP on MCAT, ICKSAR on Paging volumes. JCL in SAMPLIB? In a message dated 2/14/2012 5:38:06 P.M. Central Standard Time, jo.skip.robin...@sce.com writes: When you rewrite new text, ICKDSF will warn you that text already exists. Just write over it. Spend a little extra Valentine fun with your S.O. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SHOWZOS 720 and z/OS 1.12
Has anyone else seen the following when trying to check the LE options? This is V720 on z/OS 1.12. LE run-time options CEEPRM (CEEDOPT) CEEOCB Version not valid: 0015 LE run-time options CEEPRM (CEECOPT) CEEOCB Version not valid: 0015 etc -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SHOWZOS 720 and z/OS 1.12
Yes. CEE Parmlib member CEEPRM suffix=00 LE run-time options CEEPRM (CEEDOPT) CEEOCB Version not valid: 0015 LE run-time options CEEPRM (CEECOPT) CEEOCB Version not valid: 0015 LE run-time options CEEPRM (CEEQDOPT) CEEOCB Version not valid: 0015 LE run-time options (CEEDOPT) CEEOCB Version not valid: 0015 I don't regularly run SHOWZOS so I've just run one to see. Alan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Anthony Fletcher Sent: Tuesday, February 14, 2012 18:09 To: IBM-MAIN@bama.ua.edu Subject: SHOWZOS 720 and z/OS 1.12 Has anyone else seen the following when trying to check the LE options? This is V720 on z/OS 1.12. LE run-time options CEEPRM (CEEDOPT) CEEOCB Version not valid: 0015 LE run-time options CEEPRM (CEECOPT) CEEOCB Version not valid: 0015 etc -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Any way to get the XLC compiler to list all #define symbols?
On 15/02/2012 2:11 AM, Charles Mills wrote: Does anyone know of a way to get the XLC compiler to list all of the #define symbols that are in effect? XREF and ATTR list all ordinary symbols. There are several ways of course of determining the define state of any particular #define symbol. But does anyone know of an option or a trick to get a list of all of them? Charles, Unfortunately I don't know of any tricks as the compiler substitutes #define constants when you compile. IIRC you are coding in C++. If that's the case then #define was deprecated long ago in favour of static const. static const shows up in XREF listings and even better shows up in debuggers. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Any way to get the XLC compiler to list all #define symbols?
for me, options PPONLY and SHOWM worked:
//COMPILE EXEC PGM=CCNDRVR,
//PARM=('/CXX OPTFILE(DD:CCOPT) PPONLY SHOWM')
output is written to DD SYSUT10
see 4.107 of XL C/C++ Users Guide.
Cheers
Michael
Von:Charles Mills charl...@mcn.org
An: IBM-MAIN@bama.ua.edu
Datum: 2012-02-14 19:12
Betreff:Any way to get the XLC compiler to list all #define
symbols?
Gesendet von: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
Does anyone know of a way to get the XLC compiler to list all of the
#define
symbols that are in effect? XREF and ATTR list all ordinary symbols. There
are several ways of course of determining the define state of any
particular #define symbol. But does anyone know of an option or a trick
to
get a list of all of them?
Thanks,
Charles
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
