Re: UNIT=SEP still alive (?)
OK, what does (did) SEP= do? The only thing the JCL reference says is that you can't use it as a JCL symbol in certain types of jobs. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Thursday, August 29, 2013 3:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: UNIT=SEP still alive (?) I just found the following in some IBM same JCL (job, actually): //SYSUT1 DD UNIT=(SYSDA,SEP=(SORTLIB,SYSLMOD,SYSLIN)), // SPACE=(1000,(60,20)) Last change date is half of the 2013 (creation date is probably 2005 or so). As far as I know SEP is syntax checked and ignored for many moons, at least since first OS/390, but I vaguely remember somebody told me it was obsoleted with advent of MVS. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając 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 Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OS/390 1.3 Support Element hangs system
I never used an MP2000, we ran an MP3000 for a few years. On the bigger boxes the SE was (presumably still is) used for error reporting and other communication back to IBM as well as IPLing, reconfiguring hardware and so on. On the MP3000, it was also used (if configured so) for doing emulated I/O. The MP3000 could have up to 288 GB internal disk that looked like CKD disk to OS/390, but was in fact funneled through the OS/2 machine that also functioned as the SE. TCP/IP communication could also be emulated and funneled through the SE. On our MP3000 we didn't like the idea of either of these being dependent on an OS/2 computer so we ran external ESCON disk and had a pair of BUS-TECH pizza boxes handling terminal I/O. Is the MP2000 you are running the full size cabinet with the yellow racing stripe on the front cover? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Caserta, Greg Sent: Monday, August 26, 2013 1:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OS/390 1.3 Support Element hangs system No, nothing fancy here. What is the SE's purpose after the OS is up and running. I always thought I could unplug it unless I needed to IPL. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex R. Sent: Monday, August 26, 2013 11:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OS/390 1.3 Support Element hangs system Are you doing any emulated I/O through the OS/2 SE? I recall back when we had an MP3000 we could have done disk or terminal I/O thru the SE. Could that be causing your problem? I know that on the full size mainframes, the SE basically goes into monitor mode once all LPARs are up and running, but I believe the SE has/had additional function on the multiprise boxes. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Caserta, Greg Sent: Monday, August 26, 2013 8:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OS/390 1.3 Support Element hangs system Yes OS/390 1.3 Machine - Multiprise 2000 ( 2003-116 ) No error messages anywhere. Consoles and entire system hang as if it was quiesced. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Monday, August 26, 2013 9:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OS/390 1.3 Support Element hangs system Caserta, Greg wrote: Running OS/390 1 .3 OS/390? (End of support 2001/03/31) or do you mean z/OS 1.3 (End of support 2005/03/31)? On what machine model is that running? - Every couple months the system hangs. Once I power off/on the Support Element PC (OS/2), it breaks loose. Perhaps hardware problems? When your OS/390 is getting on, do you see any I/O errors, wait state, dumps, messages? Or could you be kind to describe 'hang'? Are the workload or sessions or console standing still or running slow? This seemed to start about 2 yrs ago when I replaced the Ramac disk with the Shark. Also replaced 3480 tape drives with 3590. I'm not sure if 3590 and Sharks are 100% supported by OS/390, but did you have a talk with your local IBM engineer? Any ideas. Sorry that I cannot come up with any solutions or suggestions. But why now asking after 2 years? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This email and any attachments may contain confidential and proprietary information and must be treated as such. In addition, export or re-export of the information contained in or attached to this email may be prohibited under export control laws. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any
Re: OS/390 1.3 Support Element hangs system
OK, I believe that box was a closer relative to the 9672 than it was to its follow-on machine, the baby MP3000. That being said, if you aren't doing any emulated I/O, IIRC, the SE should be able to be rebooted without any adverse effect on the machine itself, obviously all bets are off if the MP2000 suffers an error while the SE is unavailable... That guy has a single SE, correct? I can't remember if there's the ability to schedule the SE to reboot itself in the middle of the night. If there is, would there be a time you could schedule it and make sure that it doesn't impact the running system? Could you then just schedule the SE to reboot weekly? Given the lack of information the box is providing, it appears as though there is either a hardware error causing this or an OS/2 error (that a scheduled reboot might clean up before it bites you). Good luck. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Caserta, Greg Sent: Monday, August 26, 2013 3:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OS/390 1.3 Support Element hangs system Yes yellow stripe. No emulation being done. Sent from my iPhone On Aug 26, 2013, at 3:26 PM, Pommier, Rex R. rex.pomm...@cnasurety.com wrote: I never used an MP2000, we ran an MP3000 for a few years. On the bigger boxes the SE was (presumably still is) used for error reporting and other communication back to IBM as well as IPLing, reconfiguring hardware and so on. On the MP3000, it was also used (if configured so) for doing emulated I/O. The MP3000 could have up to 288 GB internal disk that looked like CKD disk to OS/390, but was in fact funneled through the OS/2 machine that also functioned as the SE. TCP/IP communication could also be emulated and funneled through the SE. On our MP3000 we didn't like the idea of either of these being dependent on an OS/2 computer so we ran external ESCON disk and had a pair of BUS-TECH pizza boxes handling terminal I/O. Is the MP2000 you are running the full size cabinet with the yellow racing stripe on the front cover? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Caserta, Greg Sent: Monday, August 26, 2013 1:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OS/390 1.3 Support Element hangs system No, nothing fancy here. What is the SE's purpose after the OS is up and running. I always thought I could unplug it unless I needed to IPL. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex R. Sent: Monday, August 26, 2013 11:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OS/390 1.3 Support Element hangs system Are you doing any emulated I/O through the OS/2 SE? I recall back when we had an MP3000 we could have done disk or terminal I/O thru the SE. Could that be causing your problem? I know that on the full size mainframes, the SE basically goes into monitor mode once all LPARs are up and running, but I believe the SE has/had additional function on the multiprise boxes. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Caserta, Greg Sent: Monday, August 26, 2013 8:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OS/390 1.3 Support Element hangs system Yes OS/390 1.3 Machine - Multiprise 2000 ( 2003-116 ) No error messages anywhere. Consoles and entire system hang as if it was quiesced. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Monday, August 26, 2013 9:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OS/390 1.3 Support Element hangs system Caserta, Greg wrote: Running OS/390 1 .3 OS/390? (End of support 2001/03/31) or do you mean z/OS 1.3 (End of support 2005/03/31)? On what machine model is that running? - Every couple months the system hangs. Once I power off/on the Support Element PC (OS/2), it breaks loose. Perhaps hardware problems? When your OS/390 is getting on, do you see any I/O errors, wait state, dumps, messages? Or could you be kind to describe 'hang'? Are the workload or sessions or console standing still or running slow? This seemed to start about 2 yrs ago when I replaced the Ramac disk with the Shark. Also replaced 3480 tape drives with 3590. I'm not sure if 3590 and Sharks are 100% supported by OS/390, but did you have a talk with your local IBM engineer? Any ideas. Sorry that I cannot come up with any solutions or suggestions. But why now asking after 2 years? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This email and any
Re: BLKSIZE=3120
I can't speak to all (most?) of the current architecture boxes, but to attempt to answer Jantje's question, yes the boxes I'm familiar with will definitely store less data on small block sizes. I am not speaking of the boxes that do thin provisioning because I haven't used this feature, but on IBM DS6800, EMC Symm (VMAX and DX4 w/o thin provisioning), and older HP/Hitachi XP arrays, when the physical disk was carved up into logical volumes for the emulated 3390 on top of them, storage was reserved for the physical capacity of the emulated drives. Thus if I carved up physical disk into 3390-9 volumes, the array would reserve 8.3 GB of physical space per 3390-9 volume. Rex From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Eric Bielefeld [eric-ibmm...@wi.rr.com] Sent: Tuesday, July 23, 2013 12:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 I believe that the net result of coding smaller blocksizes does result in being able to store less data. If you had 1,000 volumes all defined as 3390-9s, and each volume had 100 datasets that filled the volume blocked at 512 bytes, you would store a fraction of the data if you blocked each of those datasets at 1/2 track blocking. That is a function of the z/OS archictecture. I don't know exactly how the data is stored on the tracks, but I believe that the result of smaller blocksizes means that you will store a lot less data. Ron Hawkins probably is the best definitive source on this subject. Eric Bielefeld Retired z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: Jantje. jan.moeyers...@gfi.be Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, July 23, 2013 5:32 AM Subject: Re: BLKSIZE=3120 Taking the risk of starting another flame war here... Are there still any shops that have actual SLED? In today's world of emulated DASD, would it really still hold true that using smaller block sizes is actually wasting space? After all, these bytes are in the end physically written to FBA devices with 512 byte sectors, no? In the old days, there were inter-record gaps that took up space, but is this still the case? And even if the emulation is so good that it simulates those, what is happening with the actual capacity of the physical disks. Is that being eaten by simulated IRG? Thanks for shedding some light on this, whoever knows the internals of these current DASD boxes, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zBC12 article on one of my PC sites!
Here's the link to the announcement letter. http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=cainfotype=anappname=iSourcesupplier=897letternum=ENUS113-121 Planned availability September 20. On another note, can someone point me to the announcement for end-of-availability for purchasing upgrades to a z10BC? I must be brain-dead because I haven't been able to find it, and in this GINMF (Google is not my friend). Thanks. Rex From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of John McKown [john.archie.mck...@gmail.com] Sent: Tuesday, July 23, 2013 10:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: zBC12 article on one of my PC sites! http://arstechnica.com/information-technology/2013/07/ibm-unveils-new-mainframe-for-the-rest-of-us/ Not a lot in it, but some $ figures. quote The zBC12 includes a number of performance enhancements over IBM’s previous “midrange” offering, the z114. It uses a faster, 4.2GHz 64-bit z/Architecture processor (an improvement over the z114’s 3.8GHz CPUs), and has twice the maximum memory of the z114 at 498GB. And as far as mainframes go, the zBC12 is priced to move, starting at $75,000—or for lease starting at $1,965 a month. That’s roughly half the cost of buying the equivalent computing power in commodity x86 hardware. /quote -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zBC12 article on one of my PC sites!
Thanks, John and Sergio; I have no idea why I couldn't find it - other than brain-deadness - but this is exactly the information I was looking for. Rex From: Ed Castro [ed.cas...@hds.com] Sent: Tuesday, July 23, 2013 3:20 PM To: Pommier, Rex R. Subject: RE: zBC12 article on one of my PC sites! Hi Rex, From announcement letter: ZG11-0116, dated July 12, 2011 I'm trying to find the related US announcement letter.. Effective June 30, 2012, IBM® is withdrawing from marketing: • All models of the IBM System z10® Enterprise Class (z10TM EC) and all upgrades to the z10 EC from the IBM eServerTM zSeries® 990 (z990), IBM System z9® EC (z9TM EC), or IBM System z10 BC (z10 BC) • All models of the IBM System z10 Business Class (z10 BC) and all upgrades to the z10 BC from the IBM eServer zSeries 890 (z890) or IBM System z9 BC (z9 BC) • Model conversions and hardware MES features applied to an existing z10 EC or z10 BC server Field installed features and conversions that are delivered solely through a modification to the machine's Licensed Internal Code (LIC) will continue to be available until June 30, 2013. After June 30, 2013, features and conversions that are delivered solely through a modification to the LIC will be withdrawn. Best Regards. Sergio E. Castro Hitachi Data Systems Global Support Center 15231 Avenue of Science Suite 100 San Diego, CA 92128 USA Phone: 858 537-3075 Office 760 213-9255 Cell/Mobile Email: sergio.cas...@hds.com ed.cas...@hds.com -Original Message- From: Pommier, Rex R. [mailto:rex.pomm...@cnasurety.com] Sent: Tuesday, July 23, 2013 1:12 PM To: Ed Castro Subject: RE: zBC12 article on one of my PC sites! Ed, Thanks, but I read that one and it doesn't contain what I'm looking for. That was the announcement for buying an upgrade from a Z10 to a Z114. I apologize, I wasn't clear. What I am looking for is the announcement that says I cannot buy additional capacity for a Z10BC. Rex From: Ed Castro [ed.cas...@hds.com] Sent: Tuesday, July 23, 2013 2:59 PM To: Pommier, Rex R. Subject: RE: zBC12 article on one of my PC sites! Read the details in: Hardware withdrawal: IBM zEnterprise 196, IBM zEnterprise 114, IBM zEnterprise BladeCenter Extension Model 002, and selected IBM zEnterprise EC12 features IBM United States Withdrawal Announcement 913-145 http://www.ibm.com/common/ssi/cgi-bin/ssialias?infotype=ANsubtype=CAappname=gpateamsupplier=897letternum=ENUS913-145pdf=yes Best Regards. Sergio E. Castro Hitachi Data Systems Global Support Center 15231 Avenue of Science Suite 100 San Diego, CA 92128 USA Phone: 858 537-3075 Office 760 213-9255 Cell/Mobile Email: sergio.cas...@hds.com ed.cas...@hds.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex R. Sent: Tuesday, July 23, 2013 12:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: zBC12 article on one of my PC sites! Here's the link to the announcement letter. http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=cainfotype=anappname=iSourcesupplier=897letternum=ENUS113-121 Planned availability September 20. On another note, can someone point me to the announcement for end-of-availability for purchasing upgrades to a z10BC? I must be brain-dead because I haven't been able to find it, and in this GINMF (Google is not my friend). Thanks. Rex From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of John McKown [john.archie.mck...@gmail.com] Sent: Tuesday, July 23, 2013 10:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: zBC12 article on one of my PC sites! http://arstechnica.com/information-technology/2013/07/ibm-unveils-new-mainframe-for-the-rest-of-us/ Not a lot in it, but some $ figures. quote The zBC12 includes a number of performance enhancements over IBM’s previous “midrange” offering, the z114. It uses a faster, 4.2GHz 64-bit z/Architecture processor (an improvement over the z114’s 3.8GHz CPUs), and has twice the maximum memory of the z114 at 498GB. And as far as mainframes go, the zBC12 is priced to move, starting at $75,000—or for lease starting at $1,965 a month. That’s roughly half the cost of buying the equivalent computing power in commodity x86 hardware. /quote -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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
Re: Central Storage reallocation on z9 - requirement to be contiguous? - Never mind, didn't read enough... or reply with enough information,
OK, now I'm confused. Which question are you answering 'yes' to? You asked 2 opposite questions. In the subject line, you asked if the storage needs to be contiguous. In the body of the e-mail you ask if you could remove storage from C and give it to A without messing with B in the middle. At partition activation the storage is assigned contiguously. That makes sense as it is the easiest algorithm. But it doesn't answer the question of whether it needs to be contiguous on a reconfiguration. I'm guessing it has to be contiguous, but at this point that's all it is, a guess. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Ambros Sent: Thursday, July 11, 2013 9:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Central Storage reallocation on z9 - requirement to be contiguous? - Never mind, didn't read enough... or reply with enough information, Sorry, the answer is YES if one has not defined reserved storage. At partition activation the storage is assigned in contiguous segments. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: Vernooij, CP - SPLXM kees.verno...@klm.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 07/11/2013 10:18 Subject:Re: Central Storage reallocation on z9 - requirement to be contiguous? - Never mind, didn't read enough. Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU To take away the confusion you might have caused with some of us (and prevent us from having to rtfm in order to sleep well tonight): the answer is NO? Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Ambros Sent: Thursday, July 11, 2013 16:13 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Central Storage reallocation on z9 - requirement to be contiguous? - Never mind, didn't read enough. PR/SM Planning Guide spells it out. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: Tom Ambros thomas_amb...@keybank.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 07/11/2013 09:20 Subject:Central Storage reallocation on z9 - requirement to be contiguous? Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU z9 with three partitions, activated in order A, B, C. No reserved storage defined. We need to remove some storage from C and assign it to A. Without any operations on B, can we deactivate C, reduce initial storage, reactivate it and then deactivate A later that night, increase initial storage and reactivate it successfully? I do not see any mention of a requirement for contiguous storage in the z9 Tech Guide, it says only that the storage can come from any unused storage or storage released from another partition. Thanks... Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose such information for any purpose other than to provide the services for which you are receiving the information. 127 Public Square, Cleveland, OH 44114 If you prefer not to receive future e-mail offers for products or services from Key send an e-mail to mailto:dnereque...@key.com with 'No Promotional E-mails' in the SUBJECT line. -- 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 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
Re: What programmer's fear (not IBM specific)
And here I thought you were referring to a z/OS release about 20 years into the future, you know, the next one after z/OS 2.09. :-) Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Friday, July 05, 2013 5:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What programmer's fear (not IBM specific) My bad. Errant zero. On 05/07/2013, at 6:39 PM, Mike Schwab mike.a.sch...@gmail.com wrote: z/OS 2.10? In 2023? I haven't even seen the announcement for z/OS 2.02. On Fri, Jul 5, 2013 at 2:06 AM, David Crayford dcrayf...@gmail.com wrote: On 5/07/2013 2:56 PM, Martin Packer wrote: If that's true in Another World I wonder what it'd take to make it true in THIS one. For a start somebody to port OOREXX to z/OS. That's not going to happen until somebody first ports a recent version of GNU autotools. That's not going to happen until at least z/OS 2.10 when the new GNU extended streams API is available. We may be waiting a while... The EBCDIC stuff in OOREXX is mostly complete. I did that years ago. I bailed when it became clear that fixing the build system was an intractable problem. Cheers, Martin Martin Packer, -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Quote on http://slashdot.org
Maybe they should weight servers by their weight. :-) Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Tuesday, June 25, 2013 8:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Quote on http://slashdot.org They should weight servers by the number of simultaneous sessions connected to it. On Tue, Jun 25, 2013 at 8:29 AM, John Gilmore jwgli...@gmail.com wrote: 'Number of systems installed' is a problematic figure of merit. It weights a mainframe and my workstation equally. Jean Sammet was, among many other things, one of the designers of and an advocate for Ada. You can find her papers on Ada using Google Scholar.l John Gilmore, Ashland, MA 01721 - USA -- 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 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. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XRC Volume Resync on a Return Home
Ed brings up an interesting question. So with your response, you're saying that with PPRC, you cannot 'reverse' the mirror. Breaking and re-establishing the mirror pairs will require a full data re-push back to the now secondary site. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Thursday, June 06, 2013 5:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XRC Volume Resync on a Return Home With PPRC, you would break the pairs and re-establish in the opposite direction. When are all replicated and almost up to date, shut down the primary, wait for updates to propate, and start at the secondary. XRC may be a bit different. On Thu, Jun 6, 2013 at 4:26 PM, VanBebber, Edmond@CIO edmond.vanbeb...@state.ca.gov wrote: Thanks for the reply. I don't think that is the case when you say 'you cannot just return operations back to the original application region'. Banks do this all the time. They run production in site A for a few months then switch and run in site B for a few months. I'm not really asking if this can be done, I'm asking if you reverse replication with XRC, can you do an incremental resync without GDPS and configured for a region switch. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Thursday, June 06, 2013 2:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XRC Volume Resync on a Return Home If you are truly 'running production in a recovery site', then you cannot just 'return operations back to the original application region'. I hate to sound pedantic, but running production anywhere other than its home location. means that the latest live, current production data now lives at the recovery site. 'Home data' is now obsolete. You would have to restore that data from the recovery site at home, overlaying the old data. If that's not what you mean, please clarify. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Ed VanBebber edmond.vanbeb...@state.ca.gov To: IBM-MAIN@LISTSERV.UA.EDU, Date: 06/06/2013 11:34 AM Subject:XRC Volume Resync on a Return Home Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU After running production in a recovery site for some time, if you want to return operations back to the original application region, does XRC do a full volume resync or an incremental resync? I've read that XRC can do an incremental resync when returning home if you are configured with region switch and running GDPS, which we are not. Does anyone know if this is a proprietary thing? -- 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 -- 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 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. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS Space override
That's just where I was going in my thinking. It looks like something is defined as a 3380. 3380 track is 83% of capacity of 3390, and his initial allocation of 654 tracks is suspiciously close to 83% of his other 2 allocations of 780 tracks. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Darth Keller Sent: Tuesday, May 28, 2013 12:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMS Space override Quick dirty - In ISMF, check your CDS BASE DISPLAY . Mine: Default Device Geometry : Bytes/track . . . . . : 56664 Tracks/cylinder . . . : 15 1st thing I'd check is to ensure you've got you geometry defined correctly. This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Charter (Was: Predict WLC invoice amount ...)
Gee, thanks, Ed. You mentioned the link below and I get a 404 error. You told IBM it was there so they scrubbed it too! grin Seriously, I got a 404 not found error using the link. I found it here: http://www-07.ibm.com/servers/eserver/includes/download/mainframe_charter_faq.pdf Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Thursday, May 23, 2013 9:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Mainframe Charter (Was: Predict WLC invoice amount ...) On 5/22/2013 11:38 PM, Timothy Sipples wrote: By the way, when IBM announced the Mainframe Charter 10 years ago, it promised to deliver on a few important principles. One of the most important was to improve the value of zSeries (now zEnterprise). Very importantly, IBM did not specify exactly what form those ongoing improvements would take, at least in part because IBM couldn't predict everything. I'm pretty sure IBM didn't predict the DB2 Analytics Accelerator in 2003, for example -- at least not in detail. IBM hasn't issued many charters -- maybe two? -- and I think many observers missed how seriously IBM took (and takes) the Mainframe Charter. I really liked the Mainframe Charter. It was a great way to kick-off the mainframe's 40th anniversary celebrations! I was disappointed when IBM started systematically scrubbing away every trace of the Mainframe Charter from its web sites. (Fortunately, they left this FAQ that explains what it was all about: http://www.ibm.com/servers/eserver/includes/download/mainframe_charter_faq.pdf). I hope they plan to do another all new one next year to help celebrate the mainframe's 50th anniversary! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe Charter (Was: Predict WLC invoice amount ...)
Just a bit of clarification. I got the 404 error using the link Ed had provided. When I changed the www. to www-07. I was able to get the PDF. The firewall question Liz asked was the first thing that popped into my mind as well (along with blocked sites, etc) so I sent ED's e-mail to my home address which has nothing blocked, and I got the 404 there as well. That was when I searched IBM-land and got the hit using the www-07 link. Great list - I've definitely gotten more help from it than I have been able to return. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, May 23, 2013 10:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe Charter (Was: Predict WLC invoice amount ...) Do you have a firewall issue? I was able to use this link to get to the document. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex R. Sent: Thursday, May 23, 2013 8:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe Charter (Was: Predict WLC invoice amount ...) Gee, thanks, Ed. You mentioned the link below and I get a 404 error. You told IBM it was there so they scrubbed it too! grin Seriously, I got a 404 not found error using the link. I found it here: http://www-07.ibm.com/servers/eserver/includes/download/mainframe_charter_fa q.pdf Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Thursday, May 23, 2013 9:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Mainframe Charter (Was: Predict WLC invoice amount ...) On 5/22/2013 11:38 PM, Timothy Sipples wrote: By the way, when IBM announced the Mainframe Charter 10 years ago, it promised to deliver on a few important principles. One of the most important was to improve the value of zSeries (now zEnterprise). Very importantly, IBM did not specify exactly what form those ongoing improvements would take, at least in part because IBM couldn't predict everything. I'm pretty sure IBM didn't predict the DB2 Analytics Accelerator in 2003, for example -- at least not in detail. IBM hasn't issued many charters -- maybe two? -- and I think many observers missed how seriously IBM took (and takes) the Mainframe Charter. I really liked the Mainframe Charter. It was a great way to kick-off the mainframe's 40th anniversary celebrations! I was disappointed when IBM started systematically scrubbing away every trace of the Mainframe Charter from its web sites. (Fortunately, they left this FAQ that explains what it was all about: http://www.ibm.com/servers/eserver/includes/download/mainframe_charter_faq.p df). I hope they plan to do another all new one next year to help celebrate the mainframe's 50th anniversary! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
OK, I had never heard of this either, so I bit... 1 //RRPBR14 JOB ,TECHSUPT-RRP,MSGCLASS=X,CLASS=A,REGION=8M 2 //STEP1 EXEC PGM=IEFBR14 3 //D DD DSN=MVS.RRP.JUNK,DISP=(,CATLG), // UNIT=3390,SPACE=(CYL,(2,+1)),VOL=SER=WSC001, // DCB=(LRECL=80,RECFM=FB,BLKSIZE=80) STMT NO. MESSAGE 3 IEFC626I INCORRECT USE OF PLUS IN THE SPACE FIELD I did find the error message interesting, as it kind of implies that there is a CORRECT way to use a plus sign in a SPACE parm, but a quick glance thru the (1.10 level) doc mentions no use of a plus sign. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of J R Sent: Thursday, May 23, 2013 3:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets I think it was a pie in the sky suggestion. = = Date: Thu, 23 May 2013 20:07:25 + From: eamacn...@yahoo.ca Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets To: IBM-MAIN@LISTSERV.UA.EDU That way if you specified SPACE=(CYL,(10,+5)) and got the primary and 10 extents, the file size would be 285 cylinders and a primary with 15 extents would be 610 cylinders as opposed to 60 and 75 cylinders respectively. I don't remember that in any JCL doc I've ever seen. Where is this documented? Or, am I misreading this post and it only applies to DB2's allocations? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Blaicher, Christopher Y. cblaic...@syncsort.com Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Thu, 23 May 2013 12:21:07 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets That is a concept that DB2 uses. It can start at 1 cylinder and increase the secondary by 1 on each extend. If you changed the SPACE parameter to accept: SPACE=(unit,(n,+m,... Where unit = TRK/CYL/etc and n=Primary allocation and +m is the initial secondary amount and increment That way if you specified SPACE=(CYL,(10,+5)) and got the primary and 10 extents, the file size would be 285 cylinders and a primary with 15 extents would be 610 cylinders as opposed to 60 and 75 cylinders respectively. Amount per allocation - 10 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 Total allocation10 15 25 40 60 85 115 150 190 235 285 340 400 465 535 610 This might be attractive for an EA enabled data set where even a SPACE=(CYL,(10,+10)) gets you to about 75,030 cylinders in 123 extents. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Thursday, May 23, 2013 10:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets On Thu, 23 May 2013 16:44:55 +0200, Thomas Berg wrote: The system should allocate/reallocate according to what is needed in the actual/immediate need for the dataset without dumping the problem to the user! (Of course limited by appropriate resource constraints.) For situations like that, I like to use an allocation like CYL,(1,100). Allocate a small primary and a much larger secondary. Maybe also allowing multiple volumes. Perhaps another useful construct would be an allocation where each secondary extent was bigger than the previous. SMS would have a hard time with such a data set though. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or
Re: B37 för FTINCL in ISPF for userid.ISPnnnnn.SPFTEMPn.WORK datasets
Nope. Nothing in the JCL reference manual mentions anything like this either. 1 //RRPBR14 JOB ,TECHSUPT-RRP,MSGCLASS=X,CLASS=A,REGION=8M 2 //STEP1 EXEC PGM=IEFBR14 3 //D DD DSN=MVS.RRP.JUNK,DISP=(,CATLG), // UNIT=3390,SPACE=(CYL,(2,1+1)),VOL=SER=WSC001, // DCB=(LRECL=80,RECFM=FB,BLKSIZE=80) STMT NO. MESSAGE 3 IEFC626I INCORRECT USE OF PLUS IN THE SPACE FIELD -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Thursday, May 23, 2013 4:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: B37 för FTINCL in ISPF for userid.ISPn.SPFTEMPn.WORK datasets On Thu, May 23, 2013 at 3:54 PM, Pommier, Rex R. rex.pomm...@cnasurety.com wrote: OK, I had never heard of this either, so I bit... 1 //RRPBR14 JOB ,TECHSUPT-RRP,MSGCLASS=X,CLASS=A,REGION=8M 2 //STEP1 EXEC PGM=IEFBR14 3 //D DD DSN=MVS.RRP.JUNK,DISP=(,CATLG), // UNIT=3390,SPACE=(CYL,(2,+1)),VOL=SER=WSC001, // DCB=(LRECL=80,RECFM=FB,BLKSIZE=80) STMT NO. MESSAGE 3 IEFC626I INCORRECT USE OF PLUS IN THE SPACE FIELD I did find the error message interesting, as it kind of implies that there is a CORRECT way to use a plus sign in a SPACE parm, but a quick glance thru the (1.10 level) doc mentions no use of a plus sign. Rex SPACE=(CYL,(2,1+1)) Primary extent is 2, First secondary extent is 1, Additional secondary extents increase by 1? -- 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 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. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Check whether job still running
W dniu 2013-05-02 15:35, Pommier, Rex R. pisze: Radoslaw, One additional reason would be expediency - which relates to the territorialism Ted mentioned. One of the shops I work at has a scheduler, with a separate scheduling team that owns the scheduler and all the schedules that go into it. Any changes to the schedule need to go through this group. In my mind, it makes sense to bypass the scheduler for quick one-off jobs that require a database to be down for example. Well, such territorialism mean mistakes in management. The teams should cooperate, not fight. I would never allow such situation. BTDT - I'm a manager of mainframe division. A solution which should satisfy both parties would be to create two (maybe more) scheduling instances, one for regular users. Another mean would be scheduler security facilities. -- Radoslaw Skorupka Lodz, Poland Agreed. Unfortunately not all managers are level-headed and not all work toward a common goal. Way too many have their little fiefdom and want to protect it at all costs. Not right, but reality. Rex 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. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Check whether job still running
Exactly, Ted. I have NEVER been at a shop where an operator has noticed jobs sitting in the input queue and decided to help by unilaterally opening another initiator to service jobs of the affected class...Notice the huge pile of sarcasm!!! :-) Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ted MacNEIL Sent: Wednesday, May 01, 2013 2:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Check whether job still running But, depending on that can be risky: Not all jobs are interpreted as quickly nor is order guaranteed (same as with duplicate jobnames) What happens if another initiator is opened with the same clads$l? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Frank Swarbrick frank.swarbr...@yahoo.com Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Wed, 1 May 2013 10:45:00 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Check whether job still running If one explicitly wants to force a set of jobs to run sequentially can't they just be submitted to a class that has only a single initiator? That seems to me to be a much better solution than depending on job names. From: Joel C. Ewing jcew...@acm.org To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, May 1, 2013 10:07 AM Subject: Re: Check whether job still running Granted, production job schedulers are not a good fit if this is a one time job sequence from an application programmer or from some other user who would rightly lack update access to or full understanding of production control. If it is a frequently used job sequence and the user only needs to control when it is initiated and perhaps supply data to the jobs, then there are reasonable ways to put the jobs under a job scheduler and production control and give the application person a way to supply data and initiate the job sequence. If this level of job control is a persistent need by application programmers or other users for one-time job sequences, I would create canned JCL examples and/or PROCs and documentation showing how to submit next job JCL from a user-supplied data set or PDS member from within another job, with examples of how to use IF-THEN-ELSE JCL to conditionally fire the next job and send a message to the user if that were skipped. As long as you steer clear from trying to use in-stream JCL data to supply the next job JCL (which quickly becomes confusing as to which JCL goes with which job) and instead get the JCL from a data set, this is not a complicated process to document, and would seem to be a far simpler, more efficient, and safer solution than relying on data set enqueues or tying to ascertain the status of one job from another. This potentially means that a follow-up job may end up further down in the input queue than if submitted at the same time as the first job, but I suspect other users of the system would consider that more fair if they were competing for the same initiators. JC Ewing On 05/01/2013 09:43 AM, Farley, Peter x23353 wrote: Not just your shop, John. Access to actually create or modify a job schedule here is restricted to operations personnel. IMHO, a real production scheduler is usually way overkill for a programmer wanting to set up a few ad-hoc job sequences, not to mention that (in my experience) companies don't usually bother to teach programmers how to use production schedulers anyway. The comment earlier in this discussion (or the other similar thread) about changing the DUPEJOB setting for JES2 to allow duplicate-named jobs to execute simultaneously would be entirely counter-productive here, since submitting your series of 10 compile and link jobs (all with the same job name) would entirely flood the few initiators permitted for this purpose, locking out all the other hundreds of programmers from that scarce resource. One duplicate at a time measures out a very scarce resource in the fairest manner, or at least in *a* fair manner. Still, it would be nice to have the JES3 job networking capability. Not likely to go JES3 here though. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Wednesday, May 01, 2013 10:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Check whether job still running I don't know if it is a general problem or only one around here (due perhaps to ignorance), but in most cases, a programmer cannot _easily_ add an ad hoc series of jobs to our CA7 system and schedule them. Not to mention that the programmers don't generally have that level of knowledge any way. I am not very JES3 literate, but I've heard that it solves this problem with DJC (Dependent Job Control). And, of course, not letting a job into an initiator when it would
Re: ISPF 3.4 Performance degradation on z/OS 1.13
Mark, I read the original post differently, and my reading of it makes it sound like if he just does the catalog search it comes back in a matter of seconds, then when he hits the shift right button to get the space info, that is when he gets the horrendous response time. I don't think it is a catalog problem. I.e., where Anthony says If the Initial View is changed to 1. Volumes then the performance is much the same. , he means that he gets a 10 second response time, then when he shifts right to get the space info, release 12 comes back in seconds and release 13 takes 20 minutes. Anthony, can you enlighten us on this? If your initial display is Volume, do you get the 10 second response time on release 13? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Zelden Sent: Tuesday, April 23, 2013 8:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF 3.4 Performance degradation on z/OS 1.13 On Mon, 22 Apr 2013 22:33:59 -0500, Anthony Fletcher flet...@nz1.ibm.com wrote: We have a customer running on a z800 in a capped LPAR. We just converted them from z/OS 1.12 to z/OS 1.13 and have found that performance has degraded. They are looking at a list of data sets - approx 98,000 under a HLQ, say ABCD with the Initial view set to 2. SPACE On z/OS 1.12 this list was retrieved in under 10 seconds On z/OS 1.13 this list took 20 Minutes to return. If the Initial View is changed to 1. Volumes then the performance is much the same. The view is paged right to get the space values, on the 1.12 system it comes back in seconds on the 1.13 system it takes minutes to come back. Many of the 98,000 data sets are on TAPE or migrated. Anyone recognise a feature that came with z/OS 1.13 that might cause this change in behaviour? Hmmm. I don't think this is related to z/OS 1.13 per se.But obviously something seems wrong. The first thing I can think of is maybe the COFVLFxx member was not carried forward and catalogs are not using VLF or perhaps your client was using enhanced catalog sharing and that isn't active. But even so, from 10 seconds to 20 minutes seems extreme even without VLF or ECS. I say this because you mentioned that even the initial view of VOLUME takes a long time and that is just a catalog lookup and that has to be done before the space usage is looked at in the vtocs. What if you try doing some lists without a catalog? Use a HLQ and an generic volser like SYS* for example. Another thing you can try is to use the sample CSI (catalog search interface) exec SYS1.SAMPLIB(IGGCSIRX) or my modified sample from my web site (CATSRCH) and see how that performs. That could help narrow down the performance issue. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Output Writer and TCP/IP
Ken, What are you using now? Is it a home-built product or is it, for example, IBM's PSF, or something else? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ken MacKenzie Sent: Wednesday, March 27, 2013 7:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Output Writer and TCP/IP A third-party product is not completely out of the question but since we have the current external writer routines well ensconced in the system with our own specific tailoring, etc. the thinking is that massaging a new product may be as costly and time consuming as amending what we have. The current routines do all the spool reading already so in some ways, the hardest part is already done. The project's in its infancy right now. Ken MacKenzie Pramerica Systems Ireland Limited is a private company limited by shares incorporated and registered in the Republic of Ireland with registered number 319900 and registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4, Ireland. From: John McKown john.archie.mck...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 27/03/2013 12:14 Subject:Re: Output Writer and TCP/IP Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU We use MacKinney's JQP. You put the output on the SPOOL like normal, with a DEST=. JQP is a started task which uses the JES API to read the output. It then uses the LPR protocol over IP to send the output to LPR printers, Windows print servers, and a product called RPM (I think) which runs on Windows and transcribes the LPR print output into a Windows file. I don't know much about RPM, but we use it for our report distribution system: Report to Web. JQP works well for us, and is inexpensive. LRS has VPS/TCPIP. An RYO solution by writing your own external writer type routine is likely not the wisest move. You'd need to write your own routines to read the SPOOL, and then communicate to the remote end via a protocol such as LPR over TCPIP. I'm not saying its impossible, just not as simple as writing to a disk file. If you need a freebie, then there is the every unpopular IBM Network Print Server, which is part of Communictions Server (TCPIP/VTAM). I actually got this working once. It stinks like Limburger cheese left in a closed up car in the Texas summer heat, but it did work. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1G310/CCONTENTS On Wed, Mar 27, 2013 at 4:47 AM, Ken MacKenzie ken.macken...@pramerica.iewrote: Hi All, I've been asked to look at our output writer routines to add the facility to print using TCP/IP instead of (or maybe as well as) Bus Tag (EXCP.) Can anyone with experience in this area direct me to the relevant IBM documentation, etc? Thanks-in-Advance. Ken MacKenzie Pramerica Systems Ireland Limited is a private company limited by shares incorporated and registered in the Republic of Ireland with registered number 319900 and registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4, Ireland. -- 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 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. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
how do i capture MVS command output into a batch job?
Hi list, I did some searching of the archives and didn't see anything so I'll ask what I hope to be a simple question. I have a need to be able to execute an MVS command and have the output available to a batch job for further processing. In this case, I want to be able to capture the output of a D PROG,APF command to parse the output. Any suggestions would be helpful. Thanks. Rex 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. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: how do i capture MVS command output into a batch job?
I'll reply to my own message. I did some more digging and found several examples of how I can do this, so never mind. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex R. Sent: Wednesday, March 27, 2013 10:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: how do i capture MVS command output into a batch job? Hi list, I did some searching of the archives and didn't see anything so I'll ask what I hope to be a simple question. I have a need to be able to execute an MVS command and have the output available to a batch job for further processing. In this case, I want to be able to capture the output of a D PROG,APF command to parse the output. Any suggestions would be helpful. Thanks. Rex 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. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information.If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited.If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataset DELETE question : IEBFR14 vs IDCAMS
Gil and Steve (and probably others who feel the same way), Before you get too whack-happy, there are other reasons why something like this could show up. At some point in the deep, dark past, if the system fell over for whatever reason (power outage, operator - or sysprog - error that caused an immediate drop, etc.) temporary datasets can be left out there. This scenario hasn't happened to me in a long time so I don't know if IBM changed the system IPL to clean up old temporary datasets or not. If IBM has added a cleanup routine, or if it is found that some poor JCL coder did code a DISP on a temporary dataset, then by all means, whack away. :-) Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, March 25, 2013 2:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dataset DELETE question : IEBFR14 vs IDCAMS On Mon, 25 Mar 2013 14:38:41 -0400, Steve Thompson wrote: Now, go whack the person that wrote the JCL that has the following similarly coded DD statement: //SYSUT3 DD UNIT=3390,SPACE=(CYL,10),DISP=(NEW,CATLG) This is what produces a data set name like this: SYS12048.T104505.RA000.IBMUSER.R018 The DISP is NOT needed for a step only work file / data set. So during DEALLOCATION at step end, this type of data set just goes away. Indeed. And for good measure, I'd whack the z/OS (...OS/360?) designer who decided that the proper behavior in this case is to KEEP but not CATLG the data set. I'd have made CATLG without DSNAME a JCL syntax error and never initiated the job. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe DASD
Hey Radoslaw, I read the original request much the same way you did, that Fred is looking to get info from EMC (corporate), Hitachi (corporate), and IBM (business partners instead of corporate). In fact, Fred is looking for business partners for each of the vendors. I sent him the name of an IBM BP that I've worked with in the past and he is also looking for BPs for the other two as well. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Monday, March 18, 2013 11:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: mainframe DASD W dniu 2013-03-18 16:20, Fred Lupher pisze: We are preparing an RFP for a mainframe DASD upgrade, and we'd like to send the RFP to EMC, Hitachi IBM business partners. Does anyone know where I might find a list of business partners? I think, you don't need the list, otherwise you would be interested in polish partners - are you? ;-) I would suggest to simply ask IBM about 2-3 business partners from your region with proper authorisation. BTW: in such RFP you ask business partner, but in fact you play with IBM, the prices are set there. Business partner's value added is marginal IMHO. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając 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 Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPPTS Spill Data Set
Skip, To answer your question about a Global zone display choking, the answer is no. I have done just what the original poster asked about, moved all the remaining PTFs from SMPPTS1,2 back to SMPPTS, removed the DDDEFs etc, and deleted the SMPPTSx datasets. SMP/E will happily find the PTFs in their new location. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Wednesday, February 13, 2013 10:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMPPTS Spill Data Set If you needed a spill data set in the past, you'll probably need one again some day. Given the trouble it takes to create and then delete a spill data set, I'm with others in recommending that you just leave it. I've never deleted one, but I know that displaying a sysmod in the Global zone shows which PTS it lives in. If you just move sysmods outside of SMPE., will Global zone display choke? My suggestions: 1. Make any PTS a PDSE so that you won't have directory block shortages. 2. Update SMPE management options so that compress is not attempted on any except the *last* defined PTS. If you use PDSEs, compress will not work anyway, but why bother trying? 3. In the case of a PDSE growing excessively large, you may want to shrink it manually now and then. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Staller, Allan allan.stal...@kbmg.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 02/13/2013 08:05 AM Subject:Re: SMPPTS Spill Data Set Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU 1) Copy all members from the SMPPTS spill dataset to be deleted to original SMPPTS dataset. 2) Remove DDDEFS pointing to the SMPPTS SPILL dataset. 3) Delete the dataset. 4) Remove references to the deleted SMPPTS spill dataset from all JCL. HTH, snip I have created one SMPPTS spill data set to complete receive job for large number of PTFS, After the APPLY and ACCEPT most of the PTFS deleted and I would like to delete the spill data set which still have few entries on it. If someone tried that before can you please advise the steps to do that? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: Searching for a 8232, 3172, or BTI model 1/2
Dave, I don't have one, but would a 3174-x1L with a network card in it work? It's been a long time since I played with one, so I don't know if it supported Ethernet or only Token Ring. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Boyes Sent: Thursday, December 20, 2012 3:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: OT: Searching for a 8232, 3172, or BTI model 1/2 I'm trying to get a 43xx series system up and running for a museum (yes, I found one!), and I'm trying to find a parallel channel-attached network interface for the box. If anyone has any of the above boxes languishing in a corner or knows where I might find one, would you please contact me offlist? Tnx - db -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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...@listserv.ua.edu with the message: INFO IBM-MAIN
ISPF simple question
Hi List, I am going to show my ISPF ignorance on this question. I have a system I'm working on that has the scroll amount set to PAGE. I can change the scroll amount to CSR and it works as advertised. However, when I log off and back onto the system, it is set back to PAGE. I had thought that if I changed it to CSR, that would be saved in my ISPPROF dataset and be there the next time I logged in. I have checked the obvious, the ISPPROF isn't being deleted/recreated when I log in, I have update access to it.Anybody care to share some words of wisdom as to what I could change here to make it save my preferences? I have checked and I'm not the only one on this system that is having this problem. Thanks. Rex 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ot: GOOGLE Chrome
I don't know how it works but Adobe nailed me last week with the same garbage. I needed to download flash on a rebuilt computer, and the next thing I knew there was a trial of a McAfee AV product. I don't remember which one it was, but it went away faster than it appeared. Fortunately McAfee didn't trash my legitimately requested and installed AV. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, November 19, 2012 7:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ot: GOOGLE Chrome On Sun, 18 Nov 2012 23:24:43 -0400, Clark Morris wrote: ... I think Adobe likes to also add Mc Afee products ... How does that work (but I think I've seen it)? Isn't McAfee a commercial product that I wouldn't expect to see drug along with a free upgrade to something else? Is it McAfee Lite, or McAfee Trial Version or ...? Can we expect to see HTML5 supplant Flash? (When?) Not if Google, Microsoft, Facebook, Amazon, and Adobe have their way. (Apple seems somehow to be on the other side.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New DFSMSrmm retention method
Thanks, Mike. Rereading the background posts helped me see my mix-up. What I had missed earlier was the fact that EXPDT is just JCL independent of RMM (I didn't know if there was a VRS rule with the same name as the JCL parameter...) and WHILECATALOG was the only VRS rule in place. So the WHILECATALOG would hold the tape forever, never getting to the EXPDT processing. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Wood Sent: Monday, October 22, 2012 5:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: New DFSMSrmm retention method Rex, The only way to link a VRS to the volume EXPDT is to use the UNTILEXPIRED retention type in the VRS. So, unless, UNTILEXPIRED is used, the WHILECATALOG VRS retains the data set until it is uncataloged, and only then, when the data set is dropped from VRS retention is the volume EXPDT considered. From R13, with EXPDT retention method you can ensure that only the volume EXPDT is considered. Mike Wood -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strange PDS members
Liz, What happens if you try to either edit or view the file? Just as an experiment, I just edited a PDS member and purposefully added a hex character to it. Browsing the member then just showed a period instead of the non-displayable character. Editing or viewing the member threw up the caution - data contains invalid characters message that didn't appear in browse.. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Friday, October 12, 2012 4:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Strange PDS members I have a strange issue. I browse a member of a PDS and it looks fine. But if I use SAS UNLOAD and that same member is showing tons of hex characters. IEBCOPY does not show any errors. Are there any FREEWARE PDS analysis tools? Or any ideas why a member might look normal in ISPF but with SAS Unload show lots of hex characters? Thanks.. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Has anyone taken out hardware support for z196 from anyone other than IBM
quote If IBM were to breach its commitments, the Commission could impose a fine of up to 10 per cent of IBM's total turnover without having to prove a violation of EU competition rules. /quote Without needing to prove anything was done wrong? NO room for abuse there, is there? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Roger Bowler Sent: Thursday, October 04, 2012 8:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Has anyone taken out hardware support for z196 from anyone other than IBM On Wed, 3 Oct 2012 12:04:38 -0500, Peter Gammage peter_a_gamm...@standardlife.com wrote: We currently have IBM Mainframe Hardware maintenance through a 3rd party and are considering options for how we do hardware maintenance of the next upgrade (z196 or z12 are most likely). So far have been unable to source hardware support for these from anyone other than IBM. According to last year's ruling by the European Commission, IBM are obliged to make spare parts and technical information swiftly available, under commercially reasonable and non-discriminatory terms, to independent mainframe maintainers. http://europa.eu/rapid/pressReleasesAction.do?reference=IP/11/1539 It will be interesting to know how this will work out in practice. The EC press release goes on to say If IBM were to breach its commitments, the Commission could impose a fine of up to 10 per cent of IBM's total turnover without having to prove a violation of EU competition rules. That would be quite a hefty fine. Regards, Roger Bowler Hercules the people's mainframe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IDCAMS ODDITY?
Esmie, As best I can see, neither of the examples you show below will work. At least as of z/OS 1.10, the double asterisk was not a valid form of wildcarding dataset names within IDCAMS. In addition, the single asterisk can only be used in place of a single qualifier, and you can only have one asterisk in a DSN. While other tools allow the double asterisk, IDCAMS does not. So you could do an A.B.*.D, but you cannot do A.*.*.D. HTH Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esmie moo Sent: Wednesday, October 03, 2012 12:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IDCAMS ODDITY? Now I am totally confused. Peter, am I understanding you correctly that if I had coded BAST.PROM1.** the alter command would have worked? Elardus, are you saying that if I coded BAST.*.*.*.*.D12191 the alter would have worked? Sorry for sounding like a donkey but could you clear it up? Thanks. From: Farley, Peter x23353 peter.far...@broadridge.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, October 3, 2012 12:57:42 PM Subject: Re: IDCAMS ODDITY? John, Actually that's not true. The restriction is to one wildcarded qualifier. It does not necessarily need to be the last. The OP's original example BAST.PROM1.*.*.*.* Is correctly coded as BAST.PROM1.** But AFAIK this is just as legal: BAST.PROM1.**.D12191 Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of McKown, John Sent: Wednesday, October 03, 2012 12:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IDCAMS ODDITY? WAD. You can only wild card the last node with IDCAMS. I have other utilities from other vendors which can do otherwise. Such a Co:Z Data Set Pipes' catsearch, which is a UNIX command. catsearch 'bast.prom1.**' |\ while read i;do tsocmd alter $i mgmtclas(mnobk2);done From a UNIX shell which is properly set up. The alter can be left in lower case because tsocmd automatically uppercases. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esmie moo Sent: Wednesday, October 03, 2012 11:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IDCAMS ODDITY? Good Morning Gentle Readers, I am not sure if it is a fluke. I am trying to alter the MGMTCLASS of a ton of dsns (SMS ACS for the MGMTCLAS has been changed) which are migrated or on DASD. The dsns have 6 qualifiers. When I try this ALTER command : ALTER BAST.PROM1.*.*.*.* - MGMTCLAS (MNOBK2) I get the following error message: IDC3203I ITEM 'BAST.PROM1.*.*.*.*' DOES NOT ADHERE TO RESTRICTIONS IDC3202I ABOVE TEXT BYPASSED UNTIL NEXT COMMAND. CONDITION CODE IS 12 However, I tried the following and it worked: ALTER BAST.PROM1.PROD.LIV.JCLLIB2.*- MGMTCLAS (MNOBK5) IDC0531I ENTRY BAST.PROM1.PROD.LIV.JCLLIB2.D12191 ALTERED IDC0531I ENTRY BAST.PROM1.PROD.LIV.JCLLIB2.D12228 ALTERED IDC0531I ENTRY BAST.PROM1.PROD.LIV.JCLLIB2.VER291 ALTERED IDC0531I ENTRY BAST.PROM1.PROD.LIV.JCLLIB2.VER367 ALTERED Does this mean that IDCAMS will only accept a WILDCARD for the last qualifier? Just curious if anybody has encountered this. 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 This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: SMP/E question
Bravo, Skip! This is what I always did as well. I had a former coworker who would go through and manually exclude every PTF that failed with a HOLDERROR, until he was able to get to a RC4 on his apply check. He wasted untold hours doing this, just so he could get a RC4 on his APPLY. I think he even went so far as to RESTORE the sysmods applied if he hit a space problem so his final APPLY would show all the PTFs being applied going in at once. Bizarre! Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Thursday, September 06, 2012 10:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E question I have never understood the fixation with rock bottom return codes. SMP/E maintenance is so much simpler without agonizing over every uneven cobblestone along the path. 1. RECEIVE HOLDDATA the same day you begin installing. If you're not sure how fresh your HOLDDATA is, pull it again. The cost is trivial. 2. APPLY CHECK (as others have said) excluding nothing but HOLDSYS. 3, Study the CAUSER report. If you see only messages about unresolved HOLD errors, you are good to go. Don't waste time building EXCLUDE lists. SMP/E will exclude error sysmods without your having to lift a finger. By design. 4. Resubmit the job with the word CHECK commented out. P.S. do not edit the source JCL; use SDSF SJ (or other product equivalent) so that the next submit from your CNTL library will retain CHECK. 5. Expect RC 8. (Anything less is miraculous. A miracle won't get you a raise or a hot date.) 6. Study the CAUSER report again. If all you see are unresolved HOLD errors, you're done. Move on. 7. If you see space or directory errors, you MUST fix them now. Use PDS command (or StarTool if you have it) to fix these errors. Modify secondary extents and/or directory blocks as needed. Then return to Step 4. If you are deeply disturbed by RC 8, either take a (physician prescribed) pill, or spend some of your vast spare time researching each error sysmod. If you determine that your shop desperately needs a particular PTF in error, then open an SR to see if IBM will give you an APAR testfix. This is itself the start of a whole new adventure that you may come to rue down the road. Reconsider the pill option. It's your choice. . . 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: Gibney, Dave gib...@wsu.edu To: IBM-MAIN@LISTSERV.UA.EDU Date: 09/06/2012 06:40 PM Subject:Re: SMP/E question Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU I exclude the specific PTFs with unresolved holderror and apply the rest. It is usually only a dozen or so. I really recommend order from server to insure you have all maint and all holddata. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of ??? ?? ??? Sent: Thursday, September 06, 2012 3:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E question Hi, I received the HOLDDATA from IBM. For example the first problem on the list is with PTF UA60617. I checked online, and it says that this PTF is from October 4th, 2011, and is still in error. Is there a way to find out if there is a fix for the fix? I will change my bypass statement. Gadi huge snippage -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: UNABLE TO DO A FULL VOLUME RESTORE - DFDSS
John, I'm going to take your word that the original DUMP that you created the COPYDUMP from was a full volume dump. That being said, the BYPASSACS parameter you have in your RESTORE attempt is only valid for dataset level restores, not full restores. You will need to use a restore parameter similar to what John McKown mentioned below. You will need something like this instead of the restore you are using: RESTORE FULL INDDNAME(TAPE1) OUTDDNAME(DASD1) If you leave the keyword FULL off, DFDSS is looking for a dataset level restore. I don't see NOCOPYVOLID in the manual, but there is a blurb that says for an SMS managed source volume 9or a source volume with a VSAM dataset on it), you must use COPYVOLID. You will probably need to restore the full volume with the original volser, which will knock it offline, clip the volser to something else, then if you really want it non-SMS, run a convertv routine to make it non-SMS. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Dawes Sent: Thursday, September 06, 2012 10:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: UNABLE TO DO A FULL VOLUME RESTORE - DFDSS I am trying to do a full volume restore to a non-SMS volume. The backup which was created is of a SMS managed volume. I want to validate the backup which was made using DFDSS COPYDUMP. From: McKown, John john.mck...@healthmarkets.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, 6 September 2012 11:08 AM Subject: Re: UNABLE TO DO A FULL VOLUME RESTORE - DFDSS Are you trying to do a full volume restore, or a logical data set restore? Looks like the latter. In which case, as the messages indicate, you have not specified which data set names/pattern to restore. You'd need a DATASET(INCL(**)) to restore all the data sets. If you want to do a full volume restore, then change the RESTORE to be something like: RESTORE INDDNAME(TAPE1) OUTDDNAME(DASD1) NOCOPYVOLID From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Dawes [jhn_da...@yahoo.com.au] Sent: Thursday, September 06, 2012 9:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: UNABLE TO DO A FULL VOLUME RESTORE - DFDSS G'Day, I am trying to perform a full volume restore of a SMS volume to a spare volume which is not SMS managed. I am encountering a problem and tried several things: The output volume has a different VOLSER. The reason for this is that I want to ensure that the tape which is being used to perform the restore could be read because it was created by a DFDSS COPYDUMP. Below is the restore parm and the error messages. We are running RELEASE z/OS 01.11.00 RESTORE INDDNAME(TAPE1) OUTDDNAME(DASD1) PURGE - BYPASSACS(**) - NULLSTORCLAS - NULLMGMTCLAS ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' ADR109I (R/I)-RI01 (01), 2012.250 10:34:33 INITIAL SCAN OF USER CONTROL STATEMEN ADR138E (001)-RI01 (02), REQUIRED (SUB)PARAMETER OF 'DATASET ' IS MISSING ADR139E (001)-RI01 (01), INCONSISTENT PARAMETERS INVOLVING 'BYPASSACS ' ADR138E (001)-RI01 (02), REQUIRED (SUB)PARAMETER OF 'DATASET ' IS MISSING ADR139E (001)-RI01 (01), INCONSISTENT PARAMETERS INVOLVING 'NULLSTORCLAS ' ADR138E (001)-RI01 (02), REQUIRED (SUB)PARAMETER OF 'DATASET ' IS MISSING ADR139E (001)-RI01 (01), INCONSISTENT PARAMETERS INVOLVING 'NULLMGMTCLAS ' ADR131E (001)-RI03 (01), ABOVE TEXT BYPASSED UNTIL NEXT COMMAND ADR017E (001)-CLTSK(01), 2012.250 10:34:33 TASK NOT SCHEDULED DUE TO ERROR. TASK ADR012I (SCH)-DSSU (01), 2012.250 10:34:33 DFSMSDSS PROCESSING COMPLETE. HIGHEST SYNTAX TASK001 Can this be done i.e. restore a SMS managed volume to a NON-SMS volume? 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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
Re: UNABLE TO DO A FULL VOLUME RESTORE - DFDSS
John, It depends on what you're actually trying to accomplish here. If all you want to do is verify that the COPYDUMP will restore successfully and the output is throw-away, you can do one of these (I'm sure there are many other things you could do as well): 1. Do the full volume restore. I am pretty certain that DFDSS will knock the volume you just restored offline and leave the original source online. Clip the offline volume to a different volser. Bring the renamed volume online. Verify the files are all there and look good. Take the volume offline and initialize it to throw the data away. 2. Do a dataset level restore using INCLUDE and/or EXCLUDE parameters to just bring back a subset of the data on the volume (you will possibly need to put some RENUNC statements in there as well due to the SMS versus non-SMS issue). If you can pull datasets off the full volume COPYDUMP, is that enough of a test to make sure you can use the COPYDUMP output? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Dawes Sent: Thursday, September 06, 2012 11:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: UNABLE TO DO A FULL VOLUME RESTORE - DFDSS Rex. I did the backup myself (used COPYDUMP) and it is from a full volume backup. I used RESTORE FULL INDDNAME(TAPE1) OUTDDNAME(DASD1). I cannot put the original volume offline because these contain all our pds libs. This is why I am trying the exercise of restoring the volume (physically) to a non-sms managed volume. This way no dsns weill b cataloged etc. I am using BYPASSACS because I thought I could bypass SMS. From: Pommier, Rex R. rex.pomm...@cnasurety.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, 6 September 2012 12:30 PM Subject: Re: UNABLE TO DO A FULL VOLUME RESTORE - DFDSS John, I'm going to take your word that the original DUMP that you created the COPYDUMP from was a full volume dump. That being said, the BYPASSACS parameter you have in your RESTORE attempt is only valid for dataset level restores, not full restores. You will need to use a restore parameter similar to what John McKown mentioned below. You will need something like this instead of the restore you are using: RESTORE FULL INDDNAME(TAPE1) OUTDDNAME(DASD1) If you leave the keyword FULL off, DFDSS is looking for a dataset level restore. I don't see NOCOPYVOLID in the manual, but there is a blurb that says for an SMS managed source volume 9or a source volume with a VSAM dataset on it), you must use COPYVOLID. You will probably need to restore the full volume with the original volser, which will knock it offline, clip the volser to something else, then if you really want it non-SMS, run a convertv routine to make it non-SMS. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Dawes Sent: Thursday, September 06, 2012 10:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: UNABLE TO DO A FULL VOLUME RESTORE - DFDSS I am trying to do a full volume restore to a non-SMS volume. The backup which was created is of a SMS managed volume. I want to validate the backup which was made using DFDSS COPYDUMP. From: McKown, John john.mck...@healthmarkets.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, 6 September 2012 11:08 AM Subject: Re: UNABLE TO DO A FULL VOLUME RESTORE - DFDSS Are you trying to do a full volume restore, or a logical data set restore? Looks like the latter. In which case, as the messages indicate, you have not specified which data set names/pattern to restore. You'd need a DATASET(INCL(**)) to restore all the data sets. If you want to do a full volume restore, then change the RESTORE to be something like: RESTORE INDDNAME(TAPE1) OUTDDNAME(DASD1) NOCOPYVOLID From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Dawes [jhn_da...@yahoo.com.au] Sent: Thursday, September 06, 2012 9:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: UNABLE TO DO A FULL VOLUME RESTORE - DFDSS G'Day, I am trying to perform a full volume restore of a SMS volume to a spare volume which is not SMS managed. I am encountering a problem and tried several things: The output volume has a different VOLSER. The reason for this is that I want to ensure that the tape which is being used to perform the restore could be read because it was created by a DFDSS COPYDUMP. Below is the restore parm and the error messages. We are running RELEASE z/OS 01.11.00 RESTORE INDDNAME(TAPE1) OUTDDNAME(DASD1) PURGE - BYPASSACS(**) - NULLSTORCLAS - NULLMGMTCLAS ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' ADR109I (R/I)-RI01 (01), 2012.250 10:34:33 INITIAL SCAN OF USER CONTROL STATEMEN ADR138E (001)-RI01 (02), REQUIRED (SUB)PARAMETER OF 'DATASET ' IS MISSING ADR139E (001
Re: DFDSS
Mark, I don't see any kind of rename syntax in your copy job. Is the OMVSF HLQ defined to be on the SMS volumes? Can it be that even with the BYPASSACS stuff in there that SMS is trying to look at SMS volumes only for it? Would it work to rename the current dataset to a different HLQ that isn't SMS-managed, and do a rename back in the copy step? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Steely Sent: Wednesday, August 29, 2012 2:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFDSS We are z/OS v1r13. I am trying to move a ZFS file from a non-sms volume to a sms volume. I am not able to get this to work. I have tried using the bypassacs(**) and have tried using STORCLAS, MGMTCLAS, STORGRP and all different combinations. I just receive an error message of not being selected. Any help would be appreciated. Control Parms: COPY DATASET( - INCLUDE( - OMVSF.XX- ))- BYPASSACS(**)- STORCLAS(PRDSTAND) - MGMTCLAS(LOGVOLS)- STORGRP(OMVSVOLP)- CANCELERROR - CATALOG - DELETE PURGE - ALLDATA(*) - ALLEXCP - PROCESS(SYS1,UNDEF) - TGTALLOC(SRC) Error message: ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'COPY ' ADR109I (R/I)-RI01 (01), 2012.242 14:35:03 INITIAL SCAN OF USER CONTROL STATEMENTS COMPLETED ADR825I (001)-SETUP(01), THE FOLLOWING VOLUMES WERE ALLOCATED FOR STORGRP OMVSVOLP: MVSOM3 MVSOM4 MVSOM5 ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK ADR006I (001)-STEND(01), 2012.242 14:35:03 EXECUTION BEGINS ADR383W (001)-DDDS (01), DATA SET OMVSF.XX NOT SELECTED ADR455W (001)-DDDS (03), THE FOLLOWING DATA SETS WERE NOT SUCCESSFULLY PROCESSED OMVSF.XX ADR470W (001)-DDDS (04), NO DATA SETS SELECTED FOR PROCESSING ADR006I (001)-STEND(02), 2012.242 14:35:03 EXECUTION ENDS ADR013I (001)-CLTSK(01), 2012.242 14:35:03 TASK COMPLETED WITH RETURN CODE 0004 ADR012I (SCH)-DSSU (01), 2012.242 14:35:03 DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE IS 0004 FROM TASK001 Thank You *** CONFIDENTIALITY NOTICE *** This e-mail message and all attachments transmitted with it may contain legally privileged and confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message from your system. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS
As it sits, would dump/restore have the same issues he's having trying to copy it? He may have to remove the HLQ from SMS control, run the DUMP, put the HLQ back, then do the RESTORE. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Doug Fuerst Sent: Wednesday, August 29, 2012 2:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFDSS Assuming the new HLQ's of the SMS z/FS are defined in an ACS, why not just dump the filesystem, then restore it to a new name? A bit easier maybe, and it always worked for me. Doug Doug Fuerst Principal Consultant BK Associates 718.921.2620 917.572.7364 d...@bkassociates.net -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Steely Sent: Wednesday, August 29, 2012 3:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFDSS We are z/OS v1r13. I am trying to move a ZFS file from a non-sms volume to a sms volume. I am not able to get this to work. I have tried using the bypassacs(**) and have tried using STORCLAS, MGMTCLAS, STORGRP and all different combinations. I just receive an error message of not being selected. Any help would be appreciated. Control Parms: COPY DATASET( - INCLUDE( - OMVSF.XX- ))- BYPASSACS(**)- STORCLAS(PRDSTAND) - MGMTCLAS(LOGVOLS)- STORGRP(OMVSVOLP)- CANCELERROR - CATALOG - DELETE PURGE - ALLDATA(*) - ALLEXCP - PROCESS(SYS1,UNDEF) - TGTALLOC(SRC) Error message: ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'COPY ' ADR109I (R/I)-RI01 (01), 2012.242 14:35:03 INITIAL SCAN OF USER CONTROL STATEMENTS COMPLETED ADR825I (001)-SETUP(01), THE FOLLOWING VOLUMES WERE ALLOCATED FOR STORGRP OMVSVOLP: MVSOM3 MVSOM4 MVSOM5 ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK ADR006I (001)-STEND(01), 2012.242 14:35:03 EXECUTION BEGINS ADR383W (001)-DDDS (01), DATA SET OMVSF.XX NOT SELECTED ADR455W (001)-DDDS (03), THE FOLLOWING DATA SETS WERE NOT SUCCESSFULLY PROCESSED OMVSF.XX ADR470W (001)-DDDS (04), NO DATA SETS SELECTED FOR PROCESSING ADR006I (001)-STEND(02), 2012.242 14:35:03 EXECUTION ENDS ADR013I (001)-CLTSK(01), 2012.242 14:35:03 TASK COMPLETED WITH RETURN CODE 0004 ADR012I (SCH)-DSSU (01), 2012.242 14:35:03 DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE IS 0004 FROM TASK001 Thank You *** CONFIDENTIALITY NOTICE *** This e-mail message and all attachments transmitted with it may contain legally privileged and confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message from your system. Thank you. -- 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 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS
DSS manual says you can copy both hfs and zfs datasets, but not files within the dataset. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Doug Fuerst Sent: Wednesday, August 29, 2012 3:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFDSS I would suggest looking at Redbook SG24-6580z/OS DFS/ZFS Implementation. I don't see anything that indicates a move of a z/FS, but there is a method to use IDCAMS to copy the aggregate. Doug Doug Fuerst Principal Consultant BK Associates 718.921.2620 917.572.7364 d...@bkassociates.net -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Steely Sent: Wednesday, August 29, 2012 4:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFDSS The OMVSF name is in the ACS routines. I really just wanted to copy to the SMS volume and not perform a rename. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex R. Sent: Wednesday, August 29, 2012 3:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFDSS As it sits, would dump/restore have the same issues he's having trying to copy it? He may have to remove the HLQ from SMS control, run the DUMP, put the HLQ back, then do the RESTORE. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Doug Fuerst Sent: Wednesday, August 29, 2012 2:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFDSS Assuming the new HLQ's of the SMS z/FS are defined in an ACS, why not just dump the filesystem, then restore it to a new name? A bit easier maybe, and it always worked for me. Doug Doug Fuerst Principal Consultant BK Associates 718.921.2620 917.572.7364 d...@bkassociates.net -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Steely Sent: Wednesday, August 29, 2012 3:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFDSS We are z/OS v1r13. I am trying to move a ZFS file from a non-sms volume to a sms volume. I am not able to get this to work. I have tried using the bypassacs(**) and have tried using STORCLAS, MGMTCLAS, STORGRP and all different combinations. I just receive an error message of not being selected. Any help would be appreciated. Control Parms: COPY DATASET( - INCLUDE( - OMVSF.XX- ))- BYPASSACS(**)- STORCLAS(PRDSTAND) - MGMTCLAS(LOGVOLS)- STORGRP(OMVSVOLP)- CANCELERROR - CATALOG - DELETE PURGE - ALLDATA(*) - ALLEXCP - PROCESS(SYS1,UNDEF) - TGTALLOC(SRC) Error message: ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'COPY ' ADR109I (R/I)-RI01 (01), 2012.242 14:35:03 INITIAL SCAN OF USER CONTROL STATEMENTS COMPLETED ADR825I (001)-SETUP(01), THE FOLLOWING VOLUMES WERE ALLOCATED FOR STORGRP OMVSVOLP: MVSOM3 MVSOM4 MVSOM5 ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK ADR006I (001)-STEND(01), 2012.242 14:35:03 EXECUTION BEGINS ADR383W (001)-DDDS (01), DATA SET OMVSF.XX NOT SELECTED ADR455W (001)-DDDS (03), THE FOLLOWING DATA SETS WERE NOT SUCCESSFULLY PROCESSED OMVSF.XX ADR470W (001)-DDDS (04), NO DATA SETS SELECTED FOR PROCESSING ADR006I (001)-STEND(02), 2012.242 14:35:03 EXECUTION ENDS ADR013I (001)-CLTSK(01), 2012.242 14:35:03 TASK COMPLETED WITH RETURN CODE 0004 ADR012I (SCH)-DSSU (01), 2012.242 14:35:03 DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE IS 0004 FROM TASK001 Thank You *** CONFIDENTIALITY NOTICE *** This e-mail message and all attachments transmitted with it may contain legally privileged and confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message from your system. Thank you. -- 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 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
Re: Thanks for the memories
All the best to you in your future endeavors. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Hal Merritt Sent: Wednesday, August 22, 2012 9:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Thanks for the memories Next week, life as I know it ends. At the same time, a new life begins as I exit employment and enter a brave new world of retirement/consulting. I want to thank each one of the participants of both the IBM MAIN and RACF lists. You have been of immeasurable help. May love and laughter light your days, and warm your heart and home. May good and faithful friends be yours, wherever you may roam. May peace and plenty bless your world with joy that long endures. May all life's passing seasons bring the best to you and yours! I'll be unsubscribing from these lists with this email address, but you can look me up on LinkedIn. To my ham radio friends: de kd5hw 73 sk. Hal Merritt Houston, Texas USA NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [z390] Anyone want Source code listing of last VSE program product Supervisor?
But usually software developers don't sell copies of the software, they sell licenses to use the software, and these are not normally transferable. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Friday, August 03, 2012 10:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [z390] Anyone want Source code listing of last VSE program product Supervisor? There is a copyright doctrine called first sale that basically says that when you buy a legal copy of something you can re-sell it as you wish. I would be violating copyright law if I made copies of a Spiderman movie and sold them, but I can legally sell the copy that I bought down at the video store. (Generally -- this is a gross oversimplification of a complex legal issue). The same is true for patents: generally you can't sell things that incorporate technology patented by Ford, but you can sell your used Ford that does. http://en.wikipedia.org/wiki/First-sale_doctrine Not sure how the doctrine might apply here. You legally obtained a single copy of this code. I suspect you *might* be entitled to dispose of it as you saw fit. The issue is particularly complex for software. http://en.wikipedia.org/wiki/Vernor_v._Autodesk,_Inc. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Norman Hollander on DesertWiz Sent: Friday, August 03, 2012 8:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [z390] Anyone want Source code listing of last VSE program product Supervisor? I would not assume that a license holder has the ability to transfer his license on his own. You should check with the vendor to be sure you are in compliance with the TC of that license. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DS6000 Console SNAFU
Ron, The DS6000 is a slightly different animal from the EMC/HDS/IBM DS8000 boxes. I've used all the above except the DS8000. The EMC and HDS boxes all have the pizza boxes or laptops built within the frame of the DASD and is supported by the vendor. The DS6000 was considered by IBM to be more of a midrange array similar to the EMC Clariion (I had 1 of them too - try loading the config software for a Clariion, XP512, and DS6800 all on the same PC - uh, no, don't try it, I did and it ain't pretty). The DS6000 SE/console where the DS6000 configuration code is loaded is a customer provided external box running some flavor of Windows. I don’t remember what the HDS name of our first HDS box was (relabeled HP XP512), but we purchased a separate pizza box to front end the SVP that was internal in the XP512. The DS6800 could roughly compare to the HDS/XP512 where the customer had no access to the SVP, and the SVP didn't have any kind of user interface that was accessible by mere mortals. :-) Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ron Hawkins Sent: Tuesday, July 17, 2012 4:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DS6000 Console SNAFU Karl, You may be surprised to know that configs on at least two other DASD brands are also loaded from a laptop. For HDS the SVP (Service Processor=Service Element) is FRU that you can order. Has anyone tried to simply order and install a new SE from IBM? As for storing configs MF host storage, are you suggesting that IBM should accommodate EMC and HDS configurations on the z10? And what would a non-mainframe shop do for storage? Just rhetorical questions mate. If you've ever built configurations for twelve or more storage controllers from scratch you would know why a laptop (and RDC) are so convenient. Ron old configuration file(s). I am kind of surprised that IBM would depend on an independent system to host configuration files for the mainframe as that sort of becomes the weak link. Maybe I don't know enough about the system but it would seem that it would be better to have the DASD configuration on the z10's hard drives. Karl Severson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Urgent help needed - Message ISN000E
Yep, One big concern I see in this at this point is if they shut the LPARs down and the SE isn't talking to the CEC, how do they bring them back up? Hopefully it is something simple like a bad power supply on one of the 2 laptops and they can either fairly quickly fix it or use the alternate. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Finnell Sent: Monday, July 16, 2012 4:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Urgent help needed - Message ISN000E Yep. Could be a bad power supply in Laptop, bad cable between Laptop and z900, hard drive failure. No indication that there's anything wrong with z900 at all(as of yet).. In a message dated 7/16/2012 3:53:24 P.M. Central Daylight Time, sy...@hotmail.com writes: Service Elements are the laptop computers inside the covers of the z900 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.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...@listserv.ua.edu with the message: INFO IBM-MAIN
