Re: zFS aggregate growth amount query
Yeah, this is one of the things that has me muttering darkly upon occasion. The mount parm is "AGGRGROW". The command is "zfsadm grow". No aggr. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: "Staller, Allan" To: IBM-MAIN@LISTSERV.UA.EDU Date: 03/03/2014 09:31 Subject:Re: zFS aggregate growth amount query Sent by:IBM Mainframe Discussion List There is a currently open APR on ZFS secondary allocation. See OA44214. I have always had success w/ zfsadm agggrow -size (final desired size). Check the fine manual for syntax. I am sure the above is incorrect. Listcat the zFS. It is the secondary allocation by default, I do believe. You can override this by hand with the zfsadm grow command but if it is done as a result of the AGGRGROW parm on the mount it is the secondary allocation of the linear VSAM cluster, IIRC. > I've developed a zFS aggregate & am loading it up with a fairly large amount of data. I keep on seeing console messages sequences like: IOEZ00078E zFS aggregate exceeds 99% full (1282681/1285920) (WARNING) IOEZ00312I Dynamic growth of aggregate in progress, (by user ). IOEZ00309I Aggregate successfully dynamically grown (by user ). IOEZ00078E zFS aggregate exceeds 99% full (1285920/1289160) (WARNING) My question is with regard to the amount that the aggregate has grown by. The difference between the '1285920' and '1289160' is 3240 - presumably that is # 8k-byte blocks, but available documentation appears to be woefully inadequate. Who defines that '3420'? I certainly didn't specify it when creating the cluster, nor with any parm value when formatting it with IOEAGFMT. When I look at either IOEFSPRM or IOEPRMxx, all I see is a bunch of comment lines. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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
Re: zFS aggregate growth amount query
Listcat the zFS. It is the secondary allocation by default, I do believe. You can override this by hand with the zfsadm grow command but if it is done as a result of the AGGRGROW parm on the mount it is the secondary allocation of the linear VSAM cluster, IIRC. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: John Compton To: IBM-MAIN@LISTSERV.UA.EDU Date: 03/02/2014 14:09 Subject:zFS aggregate growth amount query Sent by:IBM Mainframe Discussion List ...not sure if I'm in the right forum here - doubtless I'll be told :) I've developed a zFS aggregate & am loading it up with a fairly large amount of data. I keep on seeing console messages sequences like: IOEZ00078E zFS aggregate exceeds 99% full (1282681/1285920) (WARNING) IOEZ00312I Dynamic growth of aggregate in progress, (by user ). IOEZ00309I Aggregate successfully dynamically grown (by user ). IOEZ00078E zFS aggregate exceeds 99% full (1285920/1289160) (WARNING) My question is with regard to the amount that the aggregate has grown by. The difference between the '1285920' and '1289160' is 3240 - presumably that is # 8k-byte blocks, but available documentation appears to be woefully inadequate. Who defines that '3420'? I certainly didn't specify it when creating the cluster, nor with any parm value when formatting it with IOEAGFMT. When I look at either IOEFSPRM or IOEPRMxx, all I see is a bunch of comment lines. How can I override this value? I expected to see something far larger... Any help would be much appreciated -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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
Re: IOCDS Write Protected
You wrote: "In such case one should write new IOCDS from current IODF file." Always, then switch it to active in the HCD dialog after activating the IODF. That write protects it. I'm fairly certain that releases write protect on the last one. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: "R.S." To: IBM-MAIN@LISTSERV.UA.EDU Date: 02/21/2014 14:36 Subject:Re: IOCDS Write Protected Sent by:IBM Mainframe Discussion List W dniu 2014-02-21 20:17, Gibney, Dave pisze: > In the interest of avoiding foot shooting, IMO, your current active IOCDS should always be write protected. > Yes, but it's important to know what is "current active" IOCDS. If you performed POR month ago and no changes in HCD/IODF were made, then it's obvious - POR IOCDS is the "current" one. However let's imagine another scenario: last POR was performed 2 years ago, several upgrades were made, maybe new DASD box arrived, maybe some devices were disconnected, some cards added... In such scenarion POR IOCDS may be useless. In such case one should write new IOCDS from current IODF file. My ?0.02 -- 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 authorized 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. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.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.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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
Re: Sysplex Common Time Source
In my opinion you may run into some interesting issues with timestamped stuff in the CFs and whatnot if the times start coming in a slightly unpredictable sequence. I don't think I'd take that risk. When we migrated from ETR to mixed to all STP CTN, the key was two machines were ETR and had the STP feature, we had one machine that was ETR only with no STP but it was getting fed by the two ETR/STP machines. Note that we had two machines as time sources, I'm also not totally sure I'd go with one machine connected to the 9037 and rely on that. I do not believe that anything z196 and up can do ETR at all. I'm pretty sure I read that in the z196 Tech Guide redbook somewhere. (Page 14 - STP section) Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: "Staller, Allan" To: IBM-MAIN@LISTSERV.UA.EDU Date: 02/07/2014 09:03 Subject:Re: Sysplex Common Time Source Sent by:IBM Mainframe Discussion List ISTR that all time references in a SYSPLEX must be within a certain tolerance (I have no recollection of the actual value). If the local time source exceeded this tolerance, the ETR (STP/9037) would guide them to the same value, or failing that , remove the system from the plex. The act of syncing the STP and the 9037 to the same time ETR might/might not provide sufficient accuracy. HTH, >That was what we originally though too, but our local IBM support >person told us we couldn't. Thinking further about configuration >activities to migrate to mixed CTN mode, I'm not seeing how on the non >STP capable processor we're going to be able to set the name of the >mixed CTN, since it isn't going to have the STP tab for that CEC, I'm not sure that that matters. IIRC, the requirement is that all systems in the sysplex get their time from the same source. As long as the z10 gets it from the timers, and there's another CEC in the CTN getting it from the same timers and acting as the primary time server for the CTN, I believe that would work. z10 <- timer zEC12 <- timer | Primary time server \/ STP other STP CECs Before STP, there was no STP tab on the HMC and the CECs were able to participate in the sysplex by virtue of using the same timer. I *think* the migration would be to make the time source the timer connected to one zEC12, make that the PTS, then add the z10 pointing to the timer. But I haven't read the fine manuals for some time, and it seems like the PTS becomes a sinle point of failure, unless at least one other machine in the CTS has a timer connection too. The point about the mixed mode CTN being envisioned as a fall-back situation, not an expected long-term situation is also good one. And if IBM is telling you "no", it's hard to argue that you'd want to try to do it. Scott -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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
Re: Impact of XCF offline
You don't have another working console in the sysplex? If you don't vary the offending system out of the sysplex when it behaves as you describe it'll be a while (failure interval) before serialized resources are freed up and any new serialization takes place, if I remember correctly. If you don't have the luxury of a sysplex that is all non-production you run the risk of affecting your production workload. We went to the trouble of implementing the BCPii interface to handle a system that can't be partitioned because it is unreachable by any other means just for this situation. I forget precisely what they called it, the first iteration was a function in System Automation. It was a while back we did it. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: "van der Grijn, Bart (B)" To: IBM-MAIN@LISTSERV.UA.EDU Date: 01/20/2014 07:59 Subject:Re: Impact of XCF offline Sent by:IBM Mainframe Discussion List Peter, We used to IPL our systems without the V XCF,,OFFLINE. That worked for years until we started to run into issues with signaling structures (one of the systems would occasionally not use one of the signaling structures after an IPL). We opened a PMR and IBM's response was to perform the V XCF as per < http://www-03.ibm.com/systems/z/advantages/pso/removing.html>. We changed our IPL procedure and haven't seen the problem since. (This was back in z/OS 1.10) So yes, we did see an impact with not using the V XCF OFFLINE. Bart -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of mf db Sent: Sunday, January 19, 2014 9:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Impact of XCF offline Hello All, This question might sound little basic and dummy, but my apologies first. There are some situation in our shop when one of our Development LPAR do undergo to unresponsive state(This happens when our developers do some destructive testings or many other factors) and even we cannot issue any commands on Console. To resolve this we just do a de-activate and activate to re-ipl the system. As a normal IPL procedure we issue V XCF,OFF,SYSNAME=something. Will there be any impact to the system when we do not issue the V XCF,OFFLINE and just do a de-activate and activate ? Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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
Re: New and improved V2R1 manuals (UNCLASSIFIED)
Perhaps because it is a new version all that stuff starts over. Just a guess. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: "Storr, Lon A CTR USARMY HRC (US)" To: IBM-MAIN@LISTSERV.UA.EDU Date: 11/20/2013 09:10 Subject:New and improved V2R1 manuals (UNCLASSIFIED) Sent by:IBM Mainframe Discussion List Classification: UNCLASSIFIED Caveats: NONE Hello List, I have been scanning the manuals associated with z/OS V2R1 and have noticed the following in those I've seen: 1) Summary of changes at the beginning of the manual has been deleted and replaced by a reference to other manuals 2) The vertical bars in the left margin that denote changes no longer appear (e.g. JCL Reference: description of EXPORT statement and SYMBOLS keyword on DD statement). If this is a permanent "improvement", I shall miss them. Alan Classification: UNCLASSIFIED Caveats: NONE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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
Re: SET CONSOLE every time you invoke SDSF ULOG
Is there any reason to change the console ID other than to your boss's ID right before you do something mischievous? Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: Paul Gilmartin To: IBM-MAIN@LISTSERV.UA.EDU Date: 10/04/2013 11:34 Subject:Re: SET CONSOLE every time you invoke SDSF ULOG Sent by:IBM Mainframe Discussion List On Fri, 4 Oct 2013 09:06:59 -0500, Yashshri G wrote: > >I have designed a REXX to invoke SDSF and SET CONSOLE name automatically to a random value as follows, > >/* REXX */ >CONNAM="SDSF"RANDOM() > Eek! Think "Collisions!" http://en.wikipedia.org/wiki/Birthday_problem (But then a capable and prolific contributor to this list and to CBTTAPE favors such a scheme to generate DDNAMEs.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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
Two RACF databases with different definitions in a single sysplex?
A group is concerned that we have a single RACF database and there is no 'test' RACF database where the organization can implement 'test' rulesets. We have two sysplexes - a systems sandbox with no applications and a mixed development/production sysplex where all the applications reside. The only way I see this happening is if non-production partitions refer to one RACF database and the production partitions refer to the other. However, there is no binary separation of production and non-production work, and all resources (datasets etc.) are accessible from every partition. Intuitively I think their idea is not good practice, to say the very least. Does anybody know of IBM documentation that can allow me to back up my assertion that they are proposing a mistake? 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
Re: Central Storage reallocation on z9 - requirement to be contiguous? - Never mind, didn't read enough... or reply with enough information,
OK, I'll try and make it clear. PR/SM Planning Guide spells out that at partition activation the initial storage allocation is made in contiguous segments. If you follow the sequence of the scenario I presented, you'll see that I am in fact asking whether lpar A, when activated, would be able to have two discontiguous storage segments - the storage released by lpar C past the end of its new allocation and its original segment. It cannot, if I understand what is written in the PR/SM Planning Guide. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: "Pommier, Rex R." To: IBM-MAIN@LISTSERV.UA.EDU Date: 07/11/2013 15:47 Subject:Re: Central Storage reallocation on z9 - requirement to be contiguous? - Never mind, didn't read enough... or reply with enough information, Sent by:IBM Mainframe Discussion List 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" 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 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 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 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 --
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" 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 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 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 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 liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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
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 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 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
Central Storage reallocation on z9 - requirement to be contiguous?
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
STP-only CTN, timing links between standalone CFs for PTS/BTS coordination
We're migrating from mixed-mode to STP-only mode in the near future. The standalone coupling facilities are such that we will need to drop the CF links to the last ETR-only machine after it is shut down and replace them with STP-only links between the coupling facilities, no room to do otherwise. We are going to make the coupling facilities our PTS and BTS machines so they need to coordinate with each other. I am not completely clear on one point. Is it possible to simply connect up the STP-only links and configure them online at the coupling facilities and expect the STP function to recognize them as available links? I am unsure because if I logically connect them in HCD I end up with an STP CNTLUNIT macro in the coupling facility hardware definitions that wasn't there before. I've looked in the Planning and Configuration redbooks but it isn't explicit enough for me to grasp. Does anybody have experience with this? I'm thinking of being conservative and implementing the I/O configuration with the links connected but on the other hand I don't want to break something that'll work. 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
Re: CFRM Policy with new CPU
I vaguely remember some advice somewhere that it is cleaner to remove the CF definitions as you go. 'Setting Up A Sysplex' has procedures to do this. Same reason we don't maintain the DR CF definitions in our policies because structure allocation may get twisty. I'd go something like this: - Activate CFRM policy removing CF External Old entirely - no definition, no preflist. Drain CF External Old. Rebuild Reallocate anything else pending. SA panels are great for this. - Install CF External New, make sure you have connectivity - Activate CFRM policy with CF External New and populate it. If you're feeling brave, combine this with the next step. I never do. Don't know if you can. - Activate CFRM policy removing CF Internal Old entirely - no definition, no preflist. Drain CF Internal Old. Rebuild Reallocate etc etc. Now you've got everything in CF External New. - Shut down the z9 and bring up the zEC12 - When you're satisfied with zOS, activate a CFRM policy including both new CFs. Populate CF Internal New. Rebuild Reallocate the stuff that stays where it is but has new preflist. - Execute JES2 checkpoint reconfig to put it back in the CF... both copies on disk before you begin prevents embarrassing cold starts, eh? Plex outage is enough explaining for one day. This way you keep CF names and partition names the same as before, and if the zEC12 isn't hosting all your zOS images you don't take an outage. Extra steps but all along the way you have the assurance stuff is still working. This used to be a chore before the SA panels and more advanced SETXCF REBUILD options but is fairly straightforward now. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: Alan Field To: IBM-MAIN@LISTSERV.UA.EDU Date: 05/02/2013 15:58 Subject:Re: CFRM Policy with new CPU Sent by:IBM Mainframe Discussion List Yes, you will need new names for the CFs. We just upgraded our processors and we had CF1 and CF2, In the new processors I defined CF3 and CF4 so we are now running with CFs named CF3 and CF4 only. Note though. In the IOCDS I named the NEW CF lpars CF1 and CF2 s so that in the CFRM policy CF3 runs in lpar CF1 etc. I'm thinking at some point I'll change the CFRM policy back to CF1 and CF2 to match the LPAR names. Yes - you need to make this change on your running system before you IPL the new system. Alan Field Technical Engineer Principal BCBS Minnesota Phone: 651.662.3546 Mobile: 651.428.8826 From: "Mohamed Juma" To: IBM-MAIN@LISTSERV.UA.EDU Date: 05/02/2013 14:50 Subject:Re: CFRM Policy with new CPU Sent by:IBM Mainframe Discussion List Alan, in this case, I have to put new names for the new CF. I was thinking to keep the old names. I think you also mean, that I have to make this change in the running system before IPL the new system. Mohamed From: Jerry Whitteridge To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 2, 2013 10:33 PM Subject: Re: CFRM Policy with new CPU Agree with this. Given a recent experience I'd also very specifically also update the COUPLExx member to explicitly load the correct policy. This is more a safety measure than anything else - I had a bad experience in just updating a CFRM policy and now am pretty gun-shy about updates like this. However we have routinely had non connected CF's in our production policies listing our DR CF's(I got bit during a development upgrade ) Jerry Whitteridge Lead Systems Programmer Safeway Inc. 925 951 4184 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Alan Field Sent: Thursday, May 02, 2013 12:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CFRM Policy with new CPU Create a CFRM policy with ALL your CFs defined, both existing and new. Change the PREFLIST to specify ALL the CFs. e.g. PREFLIST(NEW1,NEW2,OLD1,OLD2) Activate the policy. This the key step. Now no matter what combination of old and new CFs you come up on the structures will be allocated. Alan Field Technical Engineer Principal BCBS Minnesota From: "Mohamed Juma" To:IBM-MAIN@LISTSERV.UA.EDU Date: 05/02/2013 14:06 Subject:CFRM Policy with new CPU Sent by:IBM Mainframe Discussion List Hi We are in migration stage from old Z9 to zEC12 CPU, in parallel sysplex environment, regarding CFRM we referring now to two CFs, internal and external CFs. I will configure new CFRM policy referring to the new CFs. I have some doubt, that when I will IPL with the new policy with the new CPU, still it will point to the old CFRM policy, even if I define the new policy in COUPLExx member in parmlib. Any advise or recommendation will be appreciated to help me. Mohamed -- For
Re: Assigning Same SVC Number
Does the product give you the option of specifying the SVC number, a la Hogan? Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: David Andrews To: IBM-MAIN@LISTSERV.UA.EDU Date: 03/05/2013 08:21 Subject:Re: Assigning Same SVC Number Sent by:IBM Mainframe Discussion List On Tue, 2013-03-05 at 17:53 +0530, Jake anderson wrote: > Can we assign the same SVC numbers to the same Product of two different > Versions when two different Versions of same product are running parallely If you named the product, someone with specific knowledge could help. For example: in my environment IDMS SVC code is downward compatible. You may NOT replace the SVC code with the IDMS CV running. -- David Andrews A. Duda & Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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
IPSec filter rule definition for sysplex distributed dynamic VIPA
ROUTED or LOCAL? I *think* it may have to be ROUTED but I am not finding any information to conclusively prove that and before I test it out, I ask. The reason I ask is because I have reason to specify a traffic descriptor for a restricted set of ports and that would not be in compliance with RFC 4301. I understand that the distributing stack forwards the packets, but at the same time the VIPA is on the distributing stack... so is it local or is it routed? 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
Re: OT - Huge Maple Syrup heist solved.
Family are producers in Vermont so seeing the cache described in the NYT as the 'global strategic reserve' gave me a chuckle. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: Mike Schwab To: IBM-MAIN@LISTSERV.UA.EDU Date: 12/27/2012 01:28 Subject:OT - Huge Maple Syrup heist solved. Sent by:IBM Mainframe Discussion List http://www.cbc.ca/news/canada/new-brunswick/story/2012/12/20/arrests-maple-syrup-quebec.html -- 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 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
Re: Correlating workstation userid to TN3270 logon using client certificates
This is what I was thinking. I believe I can require my admin users to use a particular port on the TN3270 server task and assign a unique set of LUs that way. Non-admin users would not have access to that port. If a user connects to the open port, they would wind up with an LU that would not be eligible for admin sign-on, so a non-admin user that somehow gets an admin's RACF userid and password would not get anywhere easily. The sticky part is finding that LU for the RACF exit. We'll see how that goes. Express Logon Feature is attractive, if I can't manage what I'm thinking, what I'd need to be able to do is require the function for admin users, so they'd have to pass a cert to log on and knowing the RACF password wouldn't get it done. Then there are all the operational issues, such as how to grant access when my brilliant schemes break. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: Charles Mills To: IBM-MAIN@LISTSERV.UA.EDU Date: 12/04/2012 17:27 Subject:Re: Correlating workstation userid to TN3270 logon using client certificates Sent by:IBM Mainframe Discussion List I am not an expert on your exact question but I have done a lot with SSL certificates and with SMF data from RACF and from TCP/IP. I think RACF is pretty far removed from your TCP/IP sign-on, because TN3270 sits in the middle. As far as RACF is concerned, your client didn't sign on, a virtual terminal owned by TN3270 signed on. You would have to capture it from TCP/IP somehow and hand it off to your RACF exit. Not an entire answer, but I hope this helps. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Ambros Sent: Tuesday, December 04, 2012 11:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Correlating workstation userid to TN3270 logon using client certificates I apologize if this has been covered already, but I probably need to tell somebody if this can be done before I read up and put the pieces together. If I have an SSL-capable emulator, is it possible to validate the client certificate and extract the userid (this part, at least, I know can be done) and somehow persistently store it so that the RACF logon exits can locate it and verify that the userid entered at the application logon screen is the same userid that was presented in the client certificate? There are two factor authentication products that work at RACF logon but they have their drawbacks, we're musing about the possibility of fitting in with some of the distributed schemes for consistency's sake and closing the gap where one can get on a workstation with one set of credentials and then use another set that fell off the back of a truck to have a good old time in ways that may be distasteful to some. The distributed schemes involve seemingly robust what I have and what I know type processes and if we can then implement something reasonably inobtrusive on zOS we'd be in better shape. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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
Correlating workstation userid to TN3270 logon using client certificates
I apologize if this has been covered already, but I probably need to tell somebody if this can be done before I read up and put the pieces together. If I have an SSL-capable emulator, is it possible to validate the client certificate and extract the userid (this part, at least, I know can be done) and somehow persistently store it so that the RACF logon exits can locate it and verify that the userid entered at the application logon screen is the same userid that was presented in the client certificate? There are two factor authentication products that work at RACF logon but they have their drawbacks, we're musing about the possibility of fitting in with some of the distributed schemes for consistency's sake and closing the gap where one can get on a workstation with one set of credentials and then use another set that fell off the back of a truck to have a good old time in ways that may be distasteful to some. The distributed schemes involve seemingly robust what I have and what I know type processes and if we can then implement something reasonably inobtrusive on zOS we'd be in better shape. 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
Re: IPSec
You want to use zOSMF and the configuration selections within there. It is possible to write the configuration files yourself but it is much like taping together the contents of a shredder bucket to restore the original documents. It is not a requirement to use the GUI but you will be glad you did. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: Scott Ford To: IBM-MAIN@LISTSERV.UA.EDU Date: 09/21/2012 11:08 Subject:IPSec Sent by:IBM Mainframe Discussion List All, I am looking at implementing IPSec between z/os and windows/XP server. The RedBook sg247342 mentions using IBMs Configuration Assistant, does anyone know if this is a requirement ? Scott ford www.identityforge.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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
PCI-DSS, sysplex implementation question.
We are in the process of implementing the Payment Card Industry Data Security Standards and in an effort to cover everything and not be obliged to look at each instance in a one-off we are curious how other sysplex implementations were done. We would like to understand if we can approach this as virtually a single system image with the appropriate obfuscation, data and network access controls or if it gets more complicated than that. We're running a single zOS sysplex that hosts all our workload and we'd like to keep it that way. We've read the PCI-DSS standard documentation and were impressed by how much they leave open to interpretation and we have read the atsec doc on large system implementations. What has been the experience of the people here? Thank you for your help, maybe we can offer an idea or two of our own that might be useful. 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
Re: The IBM zEnterprise EC12 announcment
It cracks me up that there are about 12 posts about the name and nothing about the content. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: Phil Smith III To: IBM-MAIN@LISTSERV.UA.EDU Date: 08/28/2012 08:47 Subject:Re: The IBM zEnterprise EC12 announcment Sent by:IBM Mainframe Discussion List On Tue, Aug 28, 2012 at 6:27 AM, Alvaro Guirao Lopez wrote: >I did'nt see it, but I understand EC12 means Enterpise Class 12 (why 12?) 12 comes after 11, and while the z196 wasn't called the z-anything-11, it logically was. I think we can safely consider the z196 naming convention to be an aberration, hopefully not to be repeated (although these are the same folks who brought us the "Magic Box" and "Super Human Software" campaigns, so anything's possible). >That could be the reason mainframezone had chaged the name to Enterprise >Class. Hm? Thomas Publications aka Enterprise Systems Media changed Mainframe Executive to Enterprise Executive, and z/Journal to Enterprise Tech Journal. "Enterprise Class" was IBM's name for the big machines since the z9 machines. (As opposed, of course, to "Business Class", which always struck me as funny, since IBM essentially co-opted the name "enterprise" to be synonymous with "business" back in 1990 with the ESA announcement. Reminds me of a meeting I was in once, where a marketroid was describing something about support options. "Suppose we have three levels of support", he began. "Basic, Standard, and.um" - he paused to think of a third name. "Regular?" I suggested, which got me a dirty look!) I believe the Thomas changes were to broaden the publications' appeal, acknowledging the reality that nobody is *just* a mainframe shop any more. With the zBX, even that hypothetical all-mainframe shop isn't necessarily that any more. .phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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
Re: REXX ISPF edit FIND failing
Different in CLIST or Rexx? Not according to the documentation. >From the Edit and Edit Macros doc: Section 3.3.80 SCAN--Set Command Scan Mode Examples To set a line whose number is in variable &LNUM to: &SYSDATE is a CLIST built-in function set scan mode off and issue the LINE command with &&SYSDATE as the CLIST function name. The CLIST processor strips off the first &, but, because scan mode is off, the editor does not remove the second &:; ISREDIT SCAN OFF ISREDIT LINE &LNUM = "&&SYSDATE is a CLIST built-in function" ISREDIT SCAN ON Because the ISPEXEC call interface for REXX EXECs allows you to specify parameters as symbolic variables, a single scan always takes place before the syntax check of a statement. Therefore, the rule of using two ampersands (&) before variable names to avoid substitution of variable names also applies to REXX EXECs. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: Paul Gilmartin To: IBM-MAIN@LISTSERV.UA.EDU Date: 07/19/2012 12:35 Subject:Re: REXX ISPF edit FIND failing Sent by:IBM Mainframe Discussion List On Thu, 19 Jul 2012 09:12:54 -0700, John Mattson wrote: >And the grand prize goes to Tom Ambros >Yes, use DOUBLE AMPERSANDS in REXX and the FINDs work properly. >So simple when we finally see it. Many thanks to everyone. > So is the behavior of EDIT different when identical command strings are issued from Rexx vs. CLIST? Ugh! But might this be because the ISPF developers recognized that '&' symbolics would be elaborated by CLIST but not by Rexx and made a misguided attempt to make the Rexx behavior superficially more CLIST-like by processing Rexx command strings in a front-end? Did they break an API to offset their misunderstanding of Rexx? What's the behavior when the macro is written in Assembler/ PL/I/C using the CALL interface? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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
Re: REXX ISPF edit FIND failing
That's strange, they work fine as Rexx for me:
JCL: Note line 4
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(&SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR(SYSTEM)
//* TEST LINE TO BE X ALL'ED AND NOT FOUND IN FIND ALLS
//SYSINDD DISP=SHR,DSN=&PDQ.ALC.UNVLIB(&UCMIN)
X/MYSCRIPT DD DISP=SHR,DSN=&PDQ.ALC.UNVLIB(&MY)
Macro Source: Note the double ampersands as documented in the ISPF Edit
and Edit Macros manual.
/* REXX */
"ISREDIT MACRO (MEM) NOPROCESS"
trace i
"CONTROL ERRORS RETURN"
"ISREDIT X ALL"
"ISREDIT SCAN OFF"
"ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'"
"ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&&PDQR' "
"ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&&PDQR.' "
"ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&&PDQR.(' "
"ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&&PDQR.(&&'"
"ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&&PDQR.(&&SYSTEM)' "
"ISREDIT F ALL 'DISP=SHR,DSN=&&PDQ.ALC.UNVLIB(&&UCMIN)' "
"ISREDIT F ALL 'DISP=SHR,DSN=&&PDQ.ALC.UNVLIB(&&MY)'"
Trace:
4 *-* "CONTROL ERRORS RETURN"
>L> "CONTROL ERRORS RETURN"
IKJ56500I COMMAND CONTROL NOT FOUND
+++ RC(-3) +++
5 *-* "ISREDIT X ALL"
>L> "ISREDIT X ALL"
6 *-* "ISREDIT SCAN OFF"
>L> "ISREDIT SCAN OFF"
7 *-* "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'"
>L> "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE' "
8 *-* "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&&PDQR' "
>L> "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&&PDQR'"
9 *-* "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&&PDQR.' "
>L> "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&&PDQR.' "
10 *-* "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&&PDQR.(' "
>L> "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&&PDQR.(' "
11 *-* "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&&PDQR.(&&' "
>L> "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&&PDQR.(&&'
"
12 *-* "ISREDIT F ALL
'DISP=SHR,DSN=MSYS.UCMD.REMOTE&&PDQR.(&&SYSTEM)' "
>L> "ISREDIT F ALL
'DISP=SHR,DSN=MSYS.UCMD.REMOTE&&PDQR.(&&SYSTEM)' "
13 *-* "ISREDIT F ALL 'DISP=SHR,DSN=&&PDQ.ALC.UNVLIB(&&UCMIN)'"
>L> "ISREDIT F ALL 'DISP=SHR,DSN=&&PDQ.ALC.UNVLIB(&&UCMIN)'"
14 *-* "ISREDIT F ALL 'DISP=SHR,DSN=&&PDQ.ALC.UNVLIB(&&MY)' "
>L> "ISREDIT F ALL 'DISP=SHR,DSN=&&PDQ.ALC.UNVLIB(&&MY)' "
JCL member now shows:
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(&SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(SYSTEM)
//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR(SYSTEM)
- - - - - - - - - - - - - - - - - - - 1 Line(s) not
Displayed
//SYSINDD DISP=SHR,DSN=&PDQ.ALC.UNVLIB(&UCMIN)
X/MYSCRIPT DD DISP=SHR,DSN=&PDQ.ALC.UNVLIB(&MY)
Thomas Ambros
Operating Systems and Connectivity Engineering
518-436-6433
From: John Mattson
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/19/2012 10:49
Subject:Re: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List
Shmuel ! I sent my original source, and it was REXX. Having a few spare
moments, I quickly converted the REXX to CLIST and all of the FIND's
worked as a clist. Oddly, they work with or withOUT SCAN OFF. Whether
the problem belongs to ISPF, REXX, or both is not my problem. These
commands should work as a REXX. I'll let IBM sort it out.
From: "Shmuel Metz (Seymour J.)"
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/19/2012 07:17 AM
Subject:Re: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List
In
<9b26bc6a6df52d4483dd73b1fe7b4b0658b83d6...@uspho-mxvs07.amer.thermo.com>,
on 07/18/2012
at 10:37 AM, "Hardee, Chuck" said:
>Uh, I don't think so.
>You're thinking CLIST not REXX.
I doubt it. What he wrote was 'The problem is that ISPF/ISREDIT
evaluates/substitutes any ISPF variable, which in this case is
"&PDQR".', which does not refer to either CLIST or REXX variables.
>Try adding the statement: &PDQR="A"
To set the ISPF variable PDQR from REXX he needs to dreop the
ampersand:
PDQR="A"
>You will see in the trace that &PDQR was not substituted.
In what trace? The REXX trace is not relevant to substitutions
performed by ISPF.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the mess
Re: REXX ISPF edit FIND failing
This is probably easier.
ISREDIT "SCAN OFF"
ISREDIT "F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&&PDQR' "
ISREDIT "SCAN ON"
Scan is initialized to ON when the macro starts so unconditionally
changing it is probably OK.
Thomas Ambros
Operating Systems and Connectivity Engineering
518-436-6433
From: "Hardee, Chuck"
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/18/2012 14:35
Subject:Re: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List
You need to be careful with your picture string components.
It didn't work with your suggested string below and in looking at the
rules for pictures, the "." (period) represents any non-displayable
character. Since a "." as it is used in the JCL example is a displayable
character, when I changed the "." in the picture string to be an "=" then
I found the string.
I used P'DISP=SHR=DSN=MSYS=UCMD=REMOTE$PDQR=$'
Charles (Chuck) Hardee
Senior Systems Engineer
Database Administration
Information Technology Services
Thermo Fisher Scientific
300 Industry Drive
Pittsburgh, PA 15275
Direct: 724-517-2633
FAX: 412-490-9230
chuck.har...@thermofisher.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lizette Koehler
Sent: Wednesday, July 18, 2012 1:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX ISPF edit FIND failing
Personally I would use the ISPF Picture string instead of a physical line
For example
"ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.' "
would become
"ISREDIT F ALL p'DISP=SHR=DSN=MSYS.UCMD.REMOTE$PDQR$' "
The equal signs equate to any char.
The $ equate to any special char (& . , etc...)
This might make it work better
Lizette
-Original Message-
>From: John Mattson
>Sent: Jul 18, 2012 9:47 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: REXX ISPF edit FIND failing
>
>I have a little dataset which contains
>//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(&SYSTEM)
>//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(SYSTEM)
>//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR(SYSTEM)
>//SYSINDD DISP=SHR,DSN=&PDQ.ALC.UNVLIB(&UCMIN)
>X/MYSCRIPT DD DISP=SHR,DSN=&PDQ.ALC.UNVLIB(&MY)
>
>I have a little REXX which I want to "FIND" these strings
>/* REXX */
>TRACE I
>Address ISPEXEC
>"ISREDIT MACRO (MEM) NOPROCESS"
>"CONTROL ERRORS RETURN"
>"ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'"
>"ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR' "
>"ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.' "
>"ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(' "
>"ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(&'"
>"ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(&SYSTEM)' "
>"ISREDIT F ALL 'DISP=SHR,DSN=&PDQ.ALC.UNVLIB(&UCMIN)' "
>"ISREDIT F ALL 'DISP=SHR,DSN=&PDQ.ALC.UNVLIB(&MY)'"
>EXIT
>
>The First Three FIND's work fine. Starting from the fourth find,
>they all get RC=4, not found. Even tho I can clearly see that the
strings
>exist in the dataset. What in the whirled is going on here?? Is there
>something "special" about two &'s in a string? I have tried removing the
>second & from both the find and my dataset and the find still fails. I
am
>at wits end here.
>I have also tried "extracting" the actual finds like: F ALL
>'DISP=SHR,DSN=&PDQ.ALC.UNVLIB(&MY)'and executing them in TSO, and they
all
>work. What is special here. FYI, the final " is in col 71
>
--
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 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.
Re: SV: REXX ISPF edit FIND failing - oops, forgot SCAN mode
Check out SCAN mode discussion in ISPF Edit and Edit Macros doc. It has
good instructions and example.
Thomas Ambros
Operating Systems and Connectivity Engineering
518-436-6433
From: Tom Ambros
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/18/2012 13:41
Subject:Re: SV: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List
Is it possible that if you code &PDQR as &&PDQR edit strips the first
ampersand and looks for the string the way you want? I have some code
which does something similar with &SYSNAME variable in the started task
JCL. I change a string containing that variable during DR adjustments of
the VTAM proc.
Thomas Ambros
Operating Systems and Connectivity Engineering
518-436-6433
From: Thomas Berg
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/18/2012 13:27
Subject:SV: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List
The problem is that ISPF/ISREDIT evaluates/substitutes any ISPF variable,
which in this case is "&PDQR".
So:
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'"
is the same as
"ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR' "
and is the same as
"ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.' "
In the latter two cases (apparently) "&PDQR" resolves into "" (empty) and
"&PDQR." also. (The dot "." is used as an end-of-variable-name marker,
IIRC.)
In e g this:
"ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(' "
- resolves to: "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE(' "
wich is no to be found in the dataset.
Etc.
Regards,
Thomas Berg
___
Thomas Berg Specialist AM/SM&S SWEDBANK AB (publ)
> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> För John Mattson
> Skickat: den 18 juli 2012 18:48
> Till: IBM-MAIN@LISTSERV.UA.EDU
> Ämne: REXX ISPF edit FIND failing
>
> I have a little dataset which contains
> //REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(&SYSTEM)
> //REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(SYSTEM)
> //REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR(SYSTEM)
> //SYSINDD DISP=SHR,DSN=&PDQ.ALC.UNVLIB(&UCMIN)
> X/MYSCRIPT DD DISP=SHR,DSN=&PDQ.ALC.UNVLIB(&MY)
>
> I have a little REXX which I want to "FIND" these strings
> /* REXX */
> TRACE I
> Address ISPEXEC
> "ISREDIT MACRO (MEM) NOPROCESS"
> "CONTROL ERRORS RETURN"
> "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'"
> "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR' "
> "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.' "
> "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(' "
> "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(&'"
> "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(&SYSTEM)' "
> "ISREDIT F ALL 'DISP=SHR,DSN=&PDQ.ALC.UNVLIB(&UCMIN)' "
> "ISREDIT F ALL 'DISP=SHR,DSN=&PDQ.ALC.UNVLIB(&MY)'"
> EXIT
>
> The First Three FIND's work fine. Starting from the fourth
> find, they all get RC=4, not found. Even tho I can clearly see that the
> strings exist in the dataset. What in the whirled is going on here?? Is
> there something "special" about two &'s in a string? I have tried
> removing the second & from both the find and my dataset and the find
> still fails. I am at wits end here.
> I have also tried "extracting" the actual finds like: F ALL
> 'DISP=SHR,DSN=&PDQ.ALC.UNVLIB(&MY)'and executing them in TSO, and they
> all work. What is special here. FYI, the final " is in col 71
>
> --
> 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 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
Re: SV: REXX ISPF edit FIND failing
Is it possible that if you code &PDQR as &&PDQR edit strips the first
ampersand and looks for the string the way you want? I have some code
which does something similar with &SYSNAME variable in the started task
JCL. I change a string containing that variable during DR adjustments of
the VTAM proc.
Thomas Ambros
Operating Systems and Connectivity Engineering
518-436-6433
From: Thomas Berg
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/18/2012 13:27
Subject:SV: REXX ISPF edit FIND failing
Sent by:IBM Mainframe Discussion List
The problem is that ISPF/ISREDIT evaluates/substitutes any ISPF variable,
which in this case is "&PDQR".
So:
ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'"
is the same as
"ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR' "
and is the same as
"ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.' "
In the latter two cases (apparently) "&PDQR" resolves into "" (empty) and
"&PDQR." also. (The dot "." is used as an end-of-variable-name marker,
IIRC.)
In e g this:
"ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(' "
- resolves to: "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE(' "
wich is no to be found in the dataset.
Etc.
Regards,
Thomas Berg
___
Thomas Berg Specialist AM/SM&S SWEDBANK AB (publ)
> -Ursprungligt meddelande-
> Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> För John Mattson
> Skickat: den 18 juli 2012 18:48
> Till: IBM-MAIN@LISTSERV.UA.EDU
> Ämne: REXX ISPF edit FIND failing
>
> I have a little dataset which contains
> //REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(&SYSTEM)
> //REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(SYSTEM)
> //REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR(SYSTEM)
> //SYSINDD DISP=SHR,DSN=&PDQ.ALC.UNVLIB(&UCMIN)
> X/MYSCRIPT DD DISP=SHR,DSN=&PDQ.ALC.UNVLIB(&MY)
>
> I have a little REXX which I want to "FIND" these strings
> /* REXX */
> TRACE I
> Address ISPEXEC
> "ISREDIT MACRO (MEM) NOPROCESS"
> "CONTROL ERRORS RETURN"
> "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE'"
> "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR' "
> "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.' "
> "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(' "
> "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(&'"
> "ISREDIT F ALL 'DISP=SHR,DSN=MSYS.UCMD.REMOTE&PDQR.(&SYSTEM)' "
> "ISREDIT F ALL 'DISP=SHR,DSN=&PDQ.ALC.UNVLIB(&UCMIN)' "
> "ISREDIT F ALL 'DISP=SHR,DSN=&PDQ.ALC.UNVLIB(&MY)'"
> EXIT
>
> The First Three FIND's work fine. Starting from the fourth
> find, they all get RC=4, not found. Even tho I can clearly see that the
> strings exist in the dataset. What in the whirled is going on here?? Is
> there something "special" about two &'s in a string? I have tried
> removing the second & from both the find and my dataset and the find
> still fails. I am at wits end here.
> I have also tried "extracting" the actual finds like: F ALL
> 'DISP=SHR,DSN=&PDQ.ALC.UNVLIB(&MY)'and executing them in TSO, and they
> all work. What is special here. FYI, the final " is in col 71
>
> --
> 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 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
Re: Secure Encryption Keys vs Protected Keys
Phil Smith wrote: "Yes, Protected Key requires ICSF and a CEX." Should that not read "Yes, Secure Key requires ICSF and a CEX."? Blatant plagiarism follows from my copy of the z196 Tech Guide, Section 6.2.2 'CPACF Protected key': "The zEnterprise CPCs support the protected key implementation. Since PCIXCC deployment, secure keys are processed on the PCI-X and PCIe cards, requiring an asynchronous operation to move the data and keys from the general purpose CP to the crypto cards. Clear keys process faster than secure keys because the process is done synchronously on the CPACF. Protected keys blend the security of Crypto Express3 coprocessors (CEX3C) and the performance characteristics of the CPACF, running closer to the speed of clear keys. An enhancement to CPACF facilitates the continued privacy of cryptographic key material when used for data encryption. In Crypto Express3 coprocessors, a secure key is encrypted under a master key, whereas a protected key is encrypted under a wrapping key that is unique to each LPAR. After the wrapping key is unique to each LPAR, a protected key cannot be shared with another LPAR. CPACF, using key wrapping, ensures that key material is not visible to applications or operating systems during encryption operations. CPACF code generates the wrapping key and stores it in the protected area of hardware system area (HSA). The wrapping key is accessible only by firmware. It cannot be accessed by operating systems or applications. DES/T-DES and AES algorithms were implemented in CPACF code with support of hardware assist functions. Two variations of wrapping key are generated, one for DES/T-DES keys and another for AES keys." Note that CPACF generates the wrapping key and the use of the term 'protected key' in this context. Thus my confusion, I am not entirely sure that the CEX hardware is required in this case. I see the distinction that is drawn between 'secure key' and 'protected key' and I believe it is significant. 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
Re: 'Inexperienced' RBS tech operative's blunder led to banking meltdown
We just happened to upgrade our scheduler earlier this year and the tech doing it took advantage of a DR test to practice the production upgrade and backout, he had done the backout in the sandbox but wanted to see how long production would take. He happens to be the tech with the least tenure as a tech but with many years of operations and batch support experience... sort of how a lot of people used to end up in tech, I guess. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: Jerry Whitteridge To: IBM-MAIN@LISTSERV.UA.EDU Date: 06/27/2012 12:48 Subject:Re: 'Inexperienced' RBS tech operative's blunder led to banking meltdown Sent by:IBM Mainframe Discussion List One relates to a conditioning PTF required on the back level system to be able to backout an upgrade from a higher using a backup (DMPQ/MOVQ) process native to CA-7. As I read it they attempted to backout using the standard documented process but the downlevel system couldn't use the data formatted for the uplevel system and queue corruption might have occurred. It's shutting the door after the event - but also points to a code not a process problem. Jerry Whitteridge Lead Systems Programmer Safeway Inc. 925 951 4184 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Ashton Sent: Wednesday, June 27, 2012 9:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 'Inexperienced' RBS tech operative's blunder led to banking meltdown Without having seen the HIPERs, it could be that they are trying to keep others from blowing off their feet if they have staff who are "operationally challenged." B On Wed, Jun 27, 2012 at 12:34 PM, Jerry Whitteridge < jerry.whitteri...@safeway.com> wrote: > I've just seen 3 HIPER PTF's from CA related to CA-7 that also fit the > reported information on the RBS outage. I'd not be too hasty in blaming > staff at this point. > > Jerry Whitteridge > Lead Systems Programmer > Safeway Inc. > 925 951 4184 > > If you feel in control > you just aren't going fast enough. > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Knutson, Sam > Sent: Wednesday, June 27, 2012 6:49 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: 'Inexperienced' RBS tech operative's blunder led to banking > meltdown > > To someone who is inexperienced on platform I imagine managing a CA-7 > upgrade is like having the world's smartest dog but it only responds to > commands in Latin. Miscommunication is likely to be a source of > dissatisfaction. > > The average person <30 is not stupid because they haven't been editing > command decks and JCL for 25 years or lazy but software on our platform > tends to be very particular and sometimes unforgiving of mistakes i.e. > failure to specify QUEUE=NOFORMAT or some non-obvious phrase as part of > START command. Since business is no longer content to bring in newbies > and let them spend 5-10 years to reach Journeyman status under the guidance > of more senior folks software is going to have to get smarter and more > forgiving, documentation is going to have to be written with less > assumptions about the expertise of the "systems programmer" and zNextGen > (generic) is going to operate "our" mainframes weather we think they are > ready or not. Some of those next generation folks are not going to be > based in the home office anymore either whether we like that or not. > > The Register is fun reading sometimes but they rarely have enough detail > to get real insight into what actually happened. So really anything we say > here is just idle speculation. Feels like Friday so that's my .02 worth > of idle speculation :-) > > Best Regards, > > Sam Knutson, GEICO > System z Team Leader > mailto:sknut...@geico.com > (office) 301.986.3574 > (cell) 301.996.1318 > > "Think big, act bold, start simple, grow fast..." > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Tom Ambros > Sent: Wednesday, June 27, 2012 8:25 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: 'Inexperienced' RBS tech operative's blunder led to banking > meltdown > > "Complicated legacy mainframe system"? It's CA-7! If they think that's > complicated they probably can't work a Mr. Coffee. > > Thomas Ambros > Operating Systems and Connectivi
Re: 'Inexperienced' RBS tech operative's blunder led to banking meltdown
And whoever decided Tuesday night was the most appropriate probably has some explaining to do. Right before a full sized cycle? Unless every night is like that, probably not the most prudent decision. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: "McKown, John" To: IBM-MAIN@LISTSERV.UA.EDU Date: 06/27/2012 11:26 Subject:Re: 'Inexperienced' RBS tech operative's blunder led to banking meltdown Sent by:IBM Mainframe Discussion List I somewhat agree (as difficult as that is for me). In today's world, it is expected that a worker will just walk in off the street and have the "intuitive" knowledge of how to use computers. As much as I dislike it personally, z/OS really needs the "new look" interface to present to the end users, and even programmers. I wonder if anybody has done a study of productivity between "old style" development using ISPF and edit-compile-test versus using the RD/z Eclipse based software. -- 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 Knutson, Sam > Sent: Wednesday, June 27, 2012 8:49 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: 'Inexperienced' RBS tech operative's blunder led > to banking meltdown > > To someone who is inexperienced on platform I imagine > managing a CA-7 upgrade is like having the world's smartest > dog but it only responds to commands in Latin. > Miscommunication is likely to be a source of dissatisfaction. > > The average person <30 is not stupid because they haven't > been editing command decks and JCL for 25 years or lazy but > software on our platform tends to be very particular and > sometimes unforgiving of mistakes i.e. failure to specify > QUEUE=NOFORMAT or some non-obvious phrase as part of START > command. Since business is no longer content to bring in > newbies and let them spend 5-10 years to reach Journeyman > status under the guidance of more senior folks software is > going to have to get smarter and more forgiving, > documentation is going to have to be written with less > assumptions about the expertise of the "systems programmer" > and zNextGen (generic) is going to operate "our" mainframes > weather we think they are ready or not. Some of those next > generation folks are not going to be based in the home office > anymore either whether we like that or not. > > The Register is fun reading sometimes but they rarely have > enough detail to get real insight into what actually > happened. So really anything we say here is just idle > speculation. Feels like Friday so that's my .02 worth of > idle speculation :-) > > Best Regards, > > Sam Knutson, GEICO > System z Team Leader > mailto:sknut...@geico.com > (office) 301.986.3574 > (cell) 301.996.1318 > > "Think big, act bold, start simple, grow fast..." > > > -Original Message- > From: IBM Mainframe Discussion List > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Ambros > Sent: Wednesday, June 27, 2012 8:25 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: 'Inexperienced' RBS tech operative's blunder led > to banking meltdown > > "Complicated legacy mainframe system"? It's CA-7! If they > think that's complicated they probably can't work a Mr. Coffee. > > Thomas Ambros > Operating Systems and Connectivity Engineering > 518-436-6433 > > > > > > From: Ed Gould > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 06/27/2012 00:44 > Subject:'Inexperienced' RBS tech operative's blunder led to > banking meltdown > Sent by:IBM Mainframe Discussion List > > > > > http://www.theregister.co.uk/2012/06/26/rbs_natwe
Re: 'Inexperienced' RBS tech operative's blunder led to banking meltdown
"Complicated legacy mainframe system"? It's CA-7! If they think that's complicated they probably can't work a Mr. Coffee. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: Ed Gould To: IBM-MAIN@LISTSERV.UA.EDU Date: 06/27/2012 00:44 Subject:'Inexperienced' RBS tech operative's blunder led to banking meltdown Sent by:IBM Mainframe Discussion List http://www.theregister.co.uk/2012/06/26/ rbs_natwest_ca_technologies_outsourcing/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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
