Re: Rmm extended dataset
Hello Mike, Is the field XVMDMVID or XVVOLCNT existing for multi-volume tape dataset? I found some entries in rmm extended dataset has neither filed. I guess only staring from a specific rmm version , above two filed began to show up in RMM CDS. I want to find a common method to calculate multi-volume tape dataset's volcnt, could you help? Regards Victor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYNCSORT - Save a data item for use in OUTREC output
Another source for assistance would be joining Syncsort's user community. This community is a blog site where you can get product usage assistance from a wider community. The site to register and log on is http://community.syncsort.com/ This community consists of public and private groups of Syncsort product users from many companies and many countries. Syncsort employees participate in and host many of this community's groups. This would seem to be an ideal place to post your HOWTO type of question and get some quick targeted help. Best Regards, Sam Knutson -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of George, William@FTB Sent: Sunday, July 08, 2012 3:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYNCSORT - Save a data item for use in OUTREC output Wayne It appears the E15 exit will not work for our needs. And I humbly apologize as the example I gave was far too simplistic and I left off some of the requirements that make the E15 exit 'probably' not doable. - First of all the E15 requires the creation of another program which is one thing we do not care to do. - Secondly, the data item we would like to save and utilize actually will only be used within the HEADER record for any OUTFILs that do not have records in the input file. That is, if an OUTFIL has zero records written then the HEADER and TRAILER written for it will have a count of 0. But... we would like the saved data (a date range) to be plugged into the Header title area. This date is part of the input record and works fine for OUTFIL groups with an input record but when the HEADER is written for the OUTFIL groups when there are zero input records for the group, this data is not available. Thanks Bill -Original Message- From: IBM Mainframe Discussion List on behalf of George, William@FTB Sent: Sat 7/7/2012 3:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYNCSORT - Save a data item for use in OUTREC output Thanks, I'll look into this! -Original Message- From: IBM Mainframe Discussion List on behalf of Wayne Bickerdike Sent: Sat 7/7/2012 1:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYNCSORT - Save a data item for use in OUTREC output Use an E15 exit to read the input file, store the value you need to preserve and on each successive record just overwrite with the saved value and pass the record to sort. I have a few examples of E15 exit code but the SYNCSORT manual should have some examples of exit code. Wayne Bickerdike On Sat, Jul 7, 2012 at 7:40 AM, George, William@FTB william.geo...@ftb.ca.gov wrote: Sorry, the formatting didn't retain how I had originally keyed it. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of George, William@FTB Sent: Friday, July 06, 2012 2:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SYNCSORT - Save a data item for use in OUTREC output Is there a means via SYNCSORT to save a data item found on the 1st input record and then have it placed on all subsequent output records. For example. 1. Input 1 - 07/06/2012 asfasdlfjl. (save the date 07/06/2012 and not output the record) 2. Input 2 - poiutkjgfertqe Output - 07/06/2012 poiutkjgfertqe... That is, place the saved data item (date) someplace in the output record 3. Input 3 - (same as #2 and to the end of file) Thanks for any insights. ith the message: INFO IBM-MAIN This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Monitoring - managing zOS, CICS and DB2 metrics and thresholds
How much time does it take you to define which metrics in z/OS, CICS and DB2 to monitor and set thresholds? Does anyone use different thresholds throughout the day? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Secure Encryption Keys vs Protected Keys
Sorry to hear you didn't get the special briefing, John. -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von John Gilmore Gesendet: Montag, 9. Juli 2012 15:28 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: Secure Encryption Keys vs Protected Keys David Stokes wrote begin extract CEX otoh is accessed via a queuing mechanism. It is asynchronous and suspends the executing work unit until the crypto-operation is complete (along with encrypting and decrypting keys etc). /end extract In its standard use the word 'asynchronous' and the behavior he describes are incompatible. Did he perhaps mean 'synchronous' instead? Or is he using the word 'asynchronous' in a private, arcane sense? If so, he needs to explain that very special sense. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYNCSORT - Save a data item for use in OUTREC output
As a concept, I would copy the first record to a new dataset (using sort) and expand the record by one character - a blank. In a second OUTFIL statement I would expand all of the other records by the same 1 character - a blank. Then I would JOIN the two expanded datasets using the added blank as the key. I would tell the JOIN that the records are already sorted. Then in the JOIN's REFORMAT statement you can add the field from the one record file to where ever you want in all of the records. You can decide if the first record record should be in both expanded files or not (I would think so). Ken Leidner kleid...@earthlink.net -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYNCSORT - Save a data item for use in OUTREC output
Thanks Sam. I did just this over the weekend! -Original Message- From: IBM Mainframe Discussion List on behalf of Knutson, Sam Sent: Mon 7/9/2012 5:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYNCSORT - Save a data item for use in OUTREC output Another source for assistance would be joining Syncsort's user community. This community is a blog site where you can get product usage assistance from a wider community. The site to register and log on is http://community.syncsort.com/ This community consists of public and private groups of Syncsort product users from many companies and many countries. Syncsort employees participate in and host many of this community's groups. This would seem to be an ideal place to post your HOWTO type of question and get some quick targeted help. Best Regards, Sam Knutson -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of George, William@FTB Sent: Sunday, July 08, 2012 3:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYNCSORT - Save a data item for use in OUTREC output Wayne It appears the E15 exit will not work for our needs. And I humbly apologize as the example I gave was far too simplistic and I left off some of the requirements that make the E15 exit 'probably' not doable. - First of all the E15 requires the creation of another program which is one thing we do not care to do. - Secondly, the data item we would like to save and utilize actually will only be used within the HEADER record for any OUTFILs that do not have records in the input file. That is, if an OUTFIL has zero records written then the HEADER and TRAILER written for it will have a count of 0. But... we would like the saved data (a date range) to be plugged into the Header title area. This date is part of the input record and works fine for OUTFIL groups with an input record but when the HEADER is written for the OUTFIL groups when there are zero input records for the group, this data is not available. Thanks Bill -Original Message- From: IBM Mainframe Discussion List on behalf of George, William@FTB Sent: Sat 7/7/2012 3:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYNCSORT - Save a data item for use in OUTREC output Thanks, I'll look into this! -Original Message- From: IBM Mainframe Discussion List on behalf of Wayne Bickerdike Sent: Sat 7/7/2012 1:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYNCSORT - Save a data item for use in OUTREC output Use an E15 exit to read the input file, store the value you need to preserve and on each successive record just overwrite with the saved value and pass the record to sort. I have a few examples of E15 exit code but the SYNCSORT manual should have some examples of exit code. Wayne Bickerdike On Sat, Jul 7, 2012 at 7:40 AM, George, William@FTB william.geo...@ftb.ca.gov wrote: Sorry, the formatting didn't retain how I had originally keyed it. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of George, William@FTB Sent: Friday, July 06, 2012 2:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SYNCSORT - Save a data item for use in OUTREC output Is there a means via SYNCSORT to save a data item found on the 1st input record and then have it placed on all subsequent output records. For example. 1. Input 1 - 07/06/2012 asfasdlfjl. (save the date 07/06/2012 and not output the record) 2. Input 2 - poiutkjgfertqe Output - 07/06/2012 poiutkjgfertqe... That is, place the saved data item (date) someplace in the output record 3. Input 3 - (same as #2 and to the end of file) Thanks for any insights. ith the message: INFO IBM-MAIN This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- 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
Greg, I can't tell.. was that a correction or clarification? Rob Schramm Senior Systems Consultant Imperium Group On Mon, Jul 9, 2012 at 10:29 AM, Rob Schramm rob.schr...@gmail.com wrote: Nope. It is correct. As is your statement. The key (no pun intended) is that the protected key scheme is dependent on having secure keys to start with. Rob Schramm Senior Systems Consultant Imperium Group On Mon, Jul 9, 2012 at 10:21 AM, Tom Ambros thomas_amb...@keybank.comwrote: 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Online 3270 manual? [was: RE: PCOMM copy-paste (quite another issue)]
Sorry for the late reply, but can you point to an online copy of the -9 edition of that manual? Bitsavers has only the -0 and -5 editions, and I can't seem to find it anywhere on the IBM sites either. Lots of references to it, but no actual copies. The replacement manual for the -10 edition, GA23-0060-0, which bitsavers does have, seems to have only pages E1 and E2. At least, there is no figure E2 present. TIA for any info/url you can provide. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Thursday, July 05, 2012 7:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PCOMM copy-paste (quite another issue) In 5949005395636248.wa.alanaltmarkus.ibm@listserv.ua.edu, on 07/05/2012 at 09:19 AM, Alan Altmark alan_altm...@us.ibm.com said: Fidelity in copy/paste requires that both applications know what they're doing with the clipboard. Of course. Default locale for Western Windows assumes code page 1252. But not even DOS code page 437 has all of the APL characters in it, No; see, e.g. GA27-2749-9, IBM 3270 Information Display Station, Figure E-2 on p. E-4. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Secure Encryption Keys vs Protected Keys
Well, to quote from POP (for one PCKMO option) (should be Perform Cryptographic Key Management Operation, btw) The 8-byte cryptographic key, K, in byte offsets 0-7 of he parameter block is encrypted using the DEA wrapping key. (See the section Protection of Crypto- graphic Key on page 7-339 for the encryption algo- rithm.) The result is placed back in byte offsets 0-7 of he parameter block. The contents of the DEA wrap- ping-key verification-pattern register are placed in byte offsets 8-31 of the parameter block. So going to 7-339 it says things like Each time a clear reset is performed, a new set of wrapping keys and their associated verification pat- terns are generated. The contents of the two wrap- ping-key registers are kept internal to the model so that no program, including the operating system, can directly observe their clear value. I.e, they're just generated in the hardware. Apparently. (I'm reading this stuff for the first time, out of curiosity mostly. It usually takes about ten times nowadays before true enlightenment dawns). David Stokes INTERCHIP AG Munich -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von Rob Schramm Gesendet: Montag, 9. Juli 2012 18:13 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: Secure Encryption Keys vs Protected Keys How is the key generated? Rob Schramm Senior Systems Consultant Imperium Group On Mon, Jul 9, 2012 at 12:07 PM, David Stokes sto...@interchip.de wrote: Well, you can encrypt a protected key with PCKMO (Perform cryptographic management operation) instruction, as appears to be done in some of the white paper tests, so I'm not convinced CEX is absolutely required. However, I see little sense, as I said before, in doing such a thing. It would somewhat void the point of having protected (i.e. secure) keys in the first place. I didn't feel the point important enough to comment on before. -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von Tom Ambros Gesendet: Montag, 9. Juli 2012 16:22 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: 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
Re: Secure Encryption Keys vs Protected Keys
Not that key. The key that will be stored under the wrapping key. Rob Schramm Senior Systems Consultant Imperium Group On Mon, Jul 9, 2012 at 12:38 PM, David Stokes sto...@interchip.de wrote: Well, to quote from POP (for one PCKMO option) (should be Perform Cryptographic Key Management Operation, btw) The 8-byte cryptographic key, K, in byte offsets 0-7 of he parameter block is encrypted using the DEA wrapping key. (See the section Protection of Crypto- graphic Key on page 7-339 for the encryption algo- rithm.) The result is placed back in byte offsets 0-7 of he parameter block. The contents of the DEA wrap- ping-key verification-pattern register are placed in byte offsets 8-31 of the parameter block. So going to 7-339 it says things like Each time a clear reset is performed, a new set of wrapping keys and their associated verification pat- terns are generated. The contents of the two wrap- ping-key registers are kept internal to the model so that no program, including the operating system, can directly observe their clear value. I.e, they're just generated in the hardware. Apparently. (I'm reading this stuff for the first time, out of curiosity mostly. It usually takes about ten times nowadays before true enlightenment dawns). David Stokes INTERCHIP AG Munich -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von Rob Schramm Gesendet: Montag, 9. Juli 2012 18:13 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: Secure Encryption Keys vs Protected Keys How is the key generated? Rob Schramm Senior Systems Consultant Imperium Group On Mon, Jul 9, 2012 at 12:07 PM, David Stokes sto...@interchip.de wrote: Well, you can encrypt a protected key with PCKMO (Perform cryptographic management operation) instruction, as appears to be done in some of the white paper tests, so I'm not convinced CEX is absolutely required. However, I see little sense, as I said before, in doing such a thing. It would somewhat void the point of having protected (i.e. secure) keys in the first place. I didn't feel the point important enough to comment on before. -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von Tom Ambros Gesendet: Montag, 9. Juli 2012 16:22 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: 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
AW: Secure Encryption Keys vs Protected Keys
If I understand correctly what you are asking, that key comes from your program, which is why it is not an ultimately secure way of doing things. Although if you are holding the protected key in storage for a communication session it does reduce the exposure, of course. There's a little document I found TechDocID: WP100647 www.ibm.com/support/techdocs which says (amongst other things) re CPACF protected key Alternatively, if no CEX3C is available, an application could use a clear key as the source for a protected key without using ICSF. In this case, the application is responsible for creating or loading a clear key value and then using the new PCKMO instruction (new on z10 GA3 - Nov. 2009 or later microcode) to wrap the key under the appropriate wrapping key. Since the wrapping key is unique to each LPAR, a protected key cannot be shared with another LPAR. Either the original secure key or the clear key value, not the protected key, would be shared or stored. The underlying secure key or clear key would need to be retrieved and wrapped with the wrapping key within each LPAR. David Stokes INTERCHIP AG Munich -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von Rob Schramm Gesendet: Montag, 9. Juli 2012 19:07 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: Secure Encryption Keys vs Protected Keys Not that key. The key that will be stored under the wrapping key. Rob Schramm Senior Systems Consultant Imperium Group On Mon, Jul 9, 2012 at 12:38 PM, David Stokes sto...@interchip.de wrote: Well, to quote from POP (for one PCKMO option) (should be Perform Cryptographic Key Management Operation, btw) The 8-byte cryptographic key, K, in byte offsets 0-7 of he parameter block is encrypted using the DEA wrapping key. (See the section Protection of Crypto- graphic Key on page 7-339 for the encryption algo- rithm.) The result is placed back in byte offsets 0-7 of he parameter block. The contents of the DEA wrap- ping-key verification-pattern register are placed in byte offsets 8-31 of the parameter block. So going to 7-339 it says things like Each time a clear reset is performed, a new set of wrapping keys and their associated verification pat- terns are generated. The contents of the two wrap- ping-key registers are kept internal to the model so that no program, including the operating system, can directly observe their clear value. I.e, they're just generated in the hardware. Apparently. (I'm reading this stuff for the first time, out of curiosity mostly. It usually takes about ten times nowadays before true enlightenment dawns). David Stokes INTERCHIP AG Munich -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von Rob Schramm Gesendet: Montag, 9. Juli 2012 18:13 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: Secure Encryption Keys vs Protected Keys How is the key generated? Rob Schramm Senior Systems Consultant Imperium Group On Mon, Jul 9, 2012 at 12:07 PM, David Stokes sto...@interchip.de wrote: Well, you can encrypt a protected key with PCKMO (Perform cryptographic management operation) instruction, as appears to be done in some of the white paper tests, so I'm not convinced CEX is absolutely required. However, I see little sense, as I said before, in doing such a thing. It would somewhat void the point of having protected (i.e. secure) keys in the first place. I didn't feel the point important enough to comment on before. -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von Tom Ambros Gesendet: Montag, 9. Juli 2012 16:22 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: 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
Re: Secure Encryption Keys vs Protected Keys
Yep. By using ICSF plus CEX, and using protected key.. you get more of the performance characteristics of CPACF but retain the more secure nature of secure key. Yes the exposure is less.. but it will always be suspect. Ultimately, the protected key is dependent on the source key material being secure or not secure... I don't see a category for sort of secure VBG. And yet.. less exposure is always a better idea. In the case of encrypting things like PINs .. I don't think securing under protected key without the original key material resting in ICSF under CEX MK is a good idea. (dang.. I think I fell into a not logic sentence) Rob Schramm Senior Systems Consultant Imperium Group On Mon, Jul 9, 2012 at 1:38 PM, David Stokes sto...@interchip.de wrote: If I understand correctly what you are asking, that key comes from your program, which is why it is not an ultimately secure way of doing things. Although if you are holding the protected key in storage for a communication session it does reduce the exposure, of course. There's a little document I found TechDocID: WP100647 www.ibm.com/support/techdocs which says (amongst other things) re CPACF protected key Alternatively, if no CEX3C is available, an application could use a clear key as the source for a protected key without using ICSF. In this case, the application is responsible for creating or loading a clear key value and then using the new PCKMO instruction (new on z10 GA3 - Nov. 2009 or later microcode) to wrap the key under the appropriate wrapping key. Since the wrapping key is unique to each LPAR, a protected key cannot be shared with another LPAR. Either the original secure key or the clear key value, not the protected key, would be shared or stored. The underlying secure key or clear key would need to be retrieved and wrapped with the wrapping key within each LPAR. David Stokes INTERCHIP AG Munich -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von Rob Schramm Gesendet: Montag, 9. Juli 2012 19:07 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: Secure Encryption Keys vs Protected Keys Not that key. The key that will be stored under the wrapping key. Rob Schramm Senior Systems Consultant Imperium Group On Mon, Jul 9, 2012 at 12:38 PM, David Stokes sto...@interchip.de wrote: Well, to quote from POP (for one PCKMO option) (should be Perform Cryptographic Key Management Operation, btw) The 8-byte cryptographic key, K, in byte offsets 0-7 of he parameter block is encrypted using the DEA wrapping key. (See the section Protection of Crypto- graphic Key on page 7-339 for the encryption algo- rithm.) The result is placed back in byte offsets 0-7 of he parameter block. The contents of the DEA wrap- ping-key verification-pattern register are placed in byte offsets 8-31 of the parameter block. So going to 7-339 it says things like Each time a clear reset is performed, a new set of wrapping keys and their associated verification pat- terns are generated. The contents of the two wrap- ping-key registers are kept internal to the model so that no program, including the operating system, can directly observe their clear value. I.e, they're just generated in the hardware. Apparently. (I'm reading this stuff for the first time, out of curiosity mostly. It usually takes about ten times nowadays before true enlightenment dawns). David Stokes INTERCHIP AG Munich -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von Rob Schramm Gesendet: Montag, 9. Juli 2012 18:13 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: Secure Encryption Keys vs Protected Keys How is the key generated? Rob Schramm Senior Systems Consultant Imperium Group On Mon, Jul 9, 2012 at 12:07 PM, David Stokes sto...@interchip.de wrote: Well, you can encrypt a protected key with PCKMO (Perform cryptographic management operation) instruction, as appears to be done in some of the white paper tests, so I'm not convinced CEX is absolutely required. However, I see little sense, as I said before, in doing such a thing. It would somewhat void the point of having protected (i.e. secure) keys in the first place. I didn't feel the point important enough to comment on before. -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von Tom Ambros Gesendet: Montag, 9. Juli 2012 16:22 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: 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
Re: . Searching for a cross=reference list of manuals ...
Thank you for the input. The IBM site contains some information. The site lists 672 titles. The set I am working with contains over 1800 titles. And, the Windows solution. I am at the mercy of our desktop group for a workstation configuration. This includes hardware and software. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: . Searching for a cross=reference list of manuals ...
I still find IBM's Softcopy Librarian, Shelf Organizer and Reader sufficient and effective. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Yuhas Sent: Monday, July 09, 2012 12:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: . Searching for a cross=reference list of manuals ... Thank you for the input. The IBM site contains some information. The site lists 672 titles. The set I am working with contains over 1800 titles. And, the Windows solution. I am at the mercy of our desktop group for a workstation configuration. This includes hardware and software. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Secure Encryption Keys vs Protected Keys
Effectively, you need both ICSF and a CEX3 to take advantage of Protected Keys. As was pointed out in another append, you can use the PCKMO instruction to wrap a key. That is, you would take a clear key and wrap it, creating a protected key. And as was also pointed out in that post, I'm not sure why you would do that. Once you bring the key, in the clear, into storage, it could be viewed by an attacker. So you would have to make sure the system is secured (i.e. no other apps or users accessing the system) while you're using the PCKMO to wrap it. And even then, you would have to be sure to use that wrapped key right away. There is no point in saving a copy of the wrapped key because there is no guarantee that the wrapping key won't have changed before you use it again. If the LPAR is deactivated and activated then the wrapping key will change and your wrapped key is no longer usable. So the value of protected key is to leverage the security of the CEX3 (for storing your application key as a secure key) with the performance of the CPACF. and responding to John Gilmore's comments, I say that the performance numbers are 'ivory tower' because few customers will ever obtain those metrics. For example, the SSL tests are intended to measure the performance of the handshake. I believe the payload in that example was 1 byte of data. That's not a very realistic exercise, but it does effectively demonstrate the value of the CEX card on the SSL handshake. So the data is valuable and useful. In the report you can see the expected throughput given AES vs TDES or the various blocksizes. And you can see the relative impact of secure key vs clear key vs protected key. But you must temper your expectations. Crypto has a cost and it can be significant, but I would also suggest that the application design can have a significant impact on your performance expectations as well. Greg Boyd IBM Advanced Technical Support Supporting Crypto on System z -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
New Goodies in ISPF z/OS 01.12.00 - missing
We just brought up z/OS 01.12.00 on one LPAR, up from 01.11.00. I immediately logged on to ISPF to see if there were any wonderful NEW goodies. Intense disappointment. :-( From the ISPF Status Panel ZOS390RL = z/OS 01.12.00 The z/OS release running on your system. ZISPFOS = ISPF FOR z/OS 01.11.00 The level of ISPF code that is running as part of z/OS on your system. This might or might not match ZOS390RL. And TUTOR ISR5 gave RXJ67 HELP z/OS 01.11.00 ISPF -- Tutorial Select option for information about the desired release or press ENTER for current release information. Current Release Changes 1 z/OS 01.11.00 ISPF /~~~ snip ~~~/ z/OS V1R12 information center shows z/OS V1R12.0 ISPF User's Guide Vol I SC34-4822-09 === Same as V1R11 z/OS V1R12.0 ISPF User's Guide Vol II SC34-4823-09 === Same as V1R11 etc Oh the shame of it all! Or did I miss something - big time? I ran SuperC and there were a few differences in the ISP PDSes, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: . Searching for a cross=reference list of manuals ...
The page I gave you is for 1 version of z/OS. Make not include manuals for additional products. The third part consisting of the 9th and 10th character change with each published edition, most manuals have at least one change with every version of z/OS. So if the first 8 match the title probably matches except for version differences. On Mon, Jul 9, 2012 at 2:14 PM, Mark Yuhas mark.yu...@paccar.com wrote: Thank you for the input. The IBM site contains some information. The site lists 672 titles. The set I am working with contains over 1800 titles. And, the Windows solution. I am at the mercy of our desktop group for a workstation configuration. This includes hardware and software. -- 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
Re: New Goodies in ISPF z/OS 01.12.00 - missing
We did not ship any changes for z/OS 1.12. Now if you had jumped to z/OS 1.13 ;-) Hank, ISPF From: David Speake david.spe...@bcbssc.com To: IBM-MAIN@listserv.ua.edu, Date: 10/07/2012 08:37 AM Subject:New Goodies in ISPF z/OS 01.12.00 - missing Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu We just brought up z/OS 01.12.00 on one LPAR, up from 01.11.00. I immediately logged on to ISPF to see if there were any wonderful NEW goodies. Intense disappointment. :-( From the ISPF Status Panel ZOS390RL = z/OS 01.12.00 The z/OS release running on your system. ZISPFOS = ISPF FOR z/OS 01.11.00 The level of ISPF code that is running as part of z/OS on your system. This might or might not match ZOS390RL. And TUTOR ISR5 gave RXJ67 HELP z/OS 01.11.00 ISPF -- Tutorial Select option for information about the desired release or press ENTER for current release information. Current Release Changes 1 z/OS 01.11.00 ISPF /~~~ snip ~~~/ z/OS V1R12 information center shows z/OS V1R12.0 ISPF User's Guide Vol I SC34-4822-09 === Same as V1R11 z/OS V1R12.0 ISPF User's Guide Vol II SC34-4823-09 === Same as V1R11 etc Oh the shame of it all! Or did I miss something - big time? I ran SuperC and there were a few differences in the ISP PDSes, -- 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
Enabling RRS Error
Dear List, Good Day. I am trying to Enable RRS facility for a DB2 related stuff. I am using the below JCL for defining the Logstream : DATA TYPE(LOGR) DEFINE LOGSTREAM NAME(ATR.PLEX1.MAIN.UR) LOWOFFLOAD(60) HIGHOFFLOAD(80) DASDONLY(YES) HLQ(IXGLOGR) LS_SIZE(1024) LS_DATACLAS(VSAMLS) STG_SIZE(1024) DEFINE LOGSTREAM NAME(ATR.PLEX1.DELAYED.UR) LOWOFFLOAD(60) HIGHOFFLOAD(80) DASDONLY(YES) HLQ(IXGLOGR) LS_SIZE(960) LS_DATACLAS(VSAMLS) STG_SIZE(960) DEFINE LOGSTREAM NAME(ATR.PLEX1.ARCHIVE) LOWOFFLOAD(0) HIGHOFFLOAD(80) DASDONLY(YES) HLQ(IXGLOGR) LS_SIZE(960) LS_DATACLAS(VSAMLS) AUTODELETE(YES) RETPD(2) STG_SIZE(2000) DEFINE LOGSTREAM NAME(ATR.PLEX1.RM.DATA) LOWOFFLOAD(60) HIGHOFFLOAD(80) DASDONLY(YES) HLQ(IXGLOGR) LS_SIZE(192) LS_DATACLAS(VSAMLS) STG_SIZE(192) DEFINE LOGSTREAM NAME(ATR.PLEX1.RESTART) LOWOFFLOAD(60) HIGHOFFLOAD(80) DASDONLY(YES) HLQ(IXGLOGR) LS_SIZE(960) LS_DATACLAS(VSAMLS) STG_SIZE(960) Z/OS : 1.13 DB2 : 10.1 But I am ending up with an error : IXG010E NO SPACE IS AVAILABLE FOR LOGSTREAM ENTRIES IXG002E LOGR POLICY PROCESSING ENDED WITH RETCODE=0008 RSNCODE=0823 All the definition starting with IXGLOGR.ATR.** are ACS controlled and they sit in a dedicated LOGR volume DEVLOG'. I can see DEVLOG volume is still 94 % free and I still Get an error message as NO SPACE IS AVAILABLE FOR LOGSTREAM ENTRIES. Reviewing the Log I can see ATR.PLEX1.MAIN.UR and ATR.PLEX1.DELAYED.UR are getting defined, but the other consecutive steps are abending with space issue. Is it something I have to reduce the STG_SIZE for the next LOGSTREAM ? Reducing the STG_SIZE will have any impact on the performance side ? Please advise me. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enabling RRS Error
lizette, Probably I missed saying that I referred the LOOKAT ibm. LOOKAT explanation says : *IXG010E* *NO* *SPACE* *IS* *AVAILABLE* *FOR* type *ENTRIES* *Explanation:* The system logger couple data set defined by the LOGR policy has no free space for the type of entry you are trying to define. Here in my case I am not defining the Couple dataset so Just defining the Logstream to DASD. *IXG002E* *LOGR* *POLICY* *PROCESSING* *ENDED* *WITH* *RETCODE=* retcode *RSNCODE=* rsncode IXG002E LOGR POLICY PROCESSING ENDED WITH RETCODE=0008 RSNCODE=0823 Jake Jake On Tue, Jul 10, 2012 at 9:44 AM, Lizette Koehler stars...@mindspring.comwrote: Dear List, Good Day. I am trying to Enable RRS facility for a DB2 related stuff. I am using the below JCL for defining the Logstream : DATA TYPE(LOGR) DEFINE LOGSTREAM NAME(ATR.PLEX1.MAIN.UR) LOWOFFLOAD(60) HIGHOFFLOAD(80) DASDONLY(YES) HLQ(IXGLOGR) LS_SIZE(1024) LS_DATACLAS(VSAMLS) STG_SIZE(1024) DEFINE LOGSTREAM NAME(ATR.PLEX1.DELAYED.UR) LOWOFFLOAD(60) HIGHOFFLOAD(80) DASDONLY(YES) HLQ(IXGLOGR) LS_SIZE(960) LS_DATACLAS(VSAMLS) STG_SIZE(960) DEFINE LOGSTREAM NAME(ATR.PLEX1.ARCHIVE) LOWOFFLOAD(0) HIGHOFFLOAD(80) DASDONLY(YES) HLQ(IXGLOGR) LS_SIZE(960) LS_DATACLAS(VSAMLS) AUTODELETE(YES) RETPD(2) STG_SIZE(2000) DEFINE LOGSTREAM NAME(ATR.PLEX1.RM.DATA) LOWOFFLOAD(60) HIGHOFFLOAD(80) DASDONLY(YES) HLQ(IXGLOGR) LS_SIZE(192) LS_DATACLAS(VSAMLS) STG_SIZE(192) DEFINE LOGSTREAM NAME(ATR.PLEX1.RESTART) LOWOFFLOAD(60) HIGHOFFLOAD(80) DASDONLY(YES) HLQ(IXGLOGR) LS_SIZE(960) LS_DATACLAS(VSAMLS) STG_SIZE(960) Z/OS : 1.13 DB2 : 10.1 But I am ending up with an error : IXG010E NO SPACE IS AVAILABLE FOR LOGSTREAM ENTRIES IXG002E LOGR POLICY PROCESSING ENDED WITH RETCODE=0008 RSNCODE=0823 All the definition starting with IXGLOGR.ATR.** are ACS controlled and they sit in a dedicated LOGR volume DEVLOG'. I can see DEVLOG volume is still 94 % free and I still Get an error message as NO SPACE IS AVAILABLE FOR LOGSTREAM ENTRIES. Reviewing the Log I can see ATR.PLEX1.MAIN.UR and ATR.PLEX1.DELAYED.UR are getting defined, but the other consecutive steps are abending with space issue. Is it something I have to reduce the STG_SIZE for the next LOGSTREAM ? Reducing the STG_SIZE will have any impact on the performance side ? Please advise me. Jake Jake, Did you even try to look up the error message before posting? You seem to post without doing any research. Advise: Look up the error and see if that tells you what you need to know. Lizette -- 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
