Re: Pervasive Encryption - why?
Lennie Dymoke-Bradshaw wrote: >My first reason for PE for data sets is that encryption >protects the data when it is accessed outside of its normal >environment (i.e. not via the data's normal RACF >environment). Some other examples, in no particular order: anything IPL'ed on the system (or that could be) that isn't z/OS with its security manager fully operating (e.g. ZZSA, standalone dump, Linux raw track access mode, Linux zdsfs, z/VM, the Customized Offerings Driver), some of the stuff Innovation Data Processing can do for backups, or a misconfigured program properties table (NOPASS). RACF is excellent, but you cannot assume it'll always be fully on guard. And it's not just "outside the normal environment." For example, it's possible (and common) to mount remote NFS directories, with z/OS acting as the NFS client. RACF might still be enforcing certain security controls from its local z/OS point of view, but if the data are in the clear then the NFS server at the other end is a weak link. Anybody who gets access to the NFS server's drives/directories gets to read everything if it's unencrypted. Roughly speaking this is "loosely attached DASD," and z/OS supports that. Of course the whole point of NFS is often to share data in certain, hopefully controlled ways across systems (including z/OS to z/OS), and the network connections can be/should be encrypted if there's a hop from the machine boundary. But what happens when someone decides to mount an NFS directory, do their authorized processing using that form of disk storage (to "escape" a chargeback?), such as backing up something there...and then somebody else reads the data from the NFS server, or from its backup? That'd be bad. z/OS now supports cloud object storage via IBM Cloud Tape Connector for z/OS and/or IBM DS8000 Transparent Cloud Tiering with z/OS DFSMShsm. It's a good idea to encrypt there, too. The cloud object storage can be physically located anywhere: within your data center(s), outside, or some of both. There are "break glass" RACF storage administrator credentials available in many shops, but even those emergency credentials shouldn't be able to access most data. Auditors shouldn't have access to most data either, although RACF has had some improvements fairly recently to cater better to auditors, to allow them to perform their important jobs but not to exceed them. z/OS Data Set Encryption helps make sure the auditors stay within their lanes, too. We should be a little careful (once again) to distinguish between z/OS Data Set Encryption and Pervasive Encryption. They are related but distinct. In this thread we're mostly discussing z/OS Data Set Encryption. Yes, please, get z/OS Data Set Encryption turned on for everything it supports, and keep expanding it. (z/OS 2.4 will introduce z/OS Data Set Encryption support for yet more types, such as PDSEs.) Pervasive Encryption is broader, and yes, you should make progress in the broader journey, too. For example, Coupling Facility (CF) structure data encryption is another capability within Pervasive Encryption strategy/architecture. J.O.Skip Robinson wrote: >For almost no cost, you can steer your company away >from potentially disastrous litigation. Why would >any management refuse that offer? Relatedly, for almost no cost you can steer *yourself* (and other administrators and operators) away from (many or most) potentially disastrous data breach investigations and culpability. Do you even want the ability to be able to read somebody else's data, such as your customers'? Why would any IT professional want the personal risk of even being accused? Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sort job to get price variance records
On 5/08/2019 11:33 am, Paul Gilmartin wrote: +1 I'm probably partisan, but I'd look to Rexx or awk, both of which provide useful associative arrays. Personally on z/OS I would look to Java. I used to use Rexx a lot, but after getting used to Java and similar languages I find Rexx very limiting. I'm not convinced an awk solution would be easier to understand than Sort -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sort job to get price variance records
On Mon, 5 Aug 2019 10:55:00 +1000, Andrew Rowley wrote: >On 1/08/2019 8:03 am, Ron Thomas wrote: >> >> We have a FB File LRECL = 80 bytes and here below is the layout. Buy_price >> is at position 65 of length 10 bytes . We need to pull those item nbrs >> which has same UPC,Vendor nbr ,State Code but there is price difference. >> Could anyone let me know how this to be done using dfsort. > >I am curious, why do you want to use Sort to perform these tasks? > +1 I'm probably partisan, but I'd look to Rexx or awk, both of which provide useful associative arrays. >The solutions are ingenious, but I wonder whether someone will be able >to understand them if modification is required in the future. > >Maybe a more general programming language would be better? > Perhaps Sort is the language most generally understood among the readers of the list. Or the one that elicits the most useful answers. On Thu, 1 Aug 2019 09:21:22 -0400, Cameron Conacher wrote: >... >I have a file of data containing extracts from some JCL. >Specifically, I am looking for all values of DATACLAS. >This all relates back to Pervasive Encryption. I just want a quick report >of the DATACLAS values in use today, as well as the counts for each >DATACLAS item I find. > >I ran a quick compare to get a report from our JCL Library, and now I am >building a SORT to look at the variable length input file data. >... Again, I'd look first to Rexx PARSE or sed regular expressions. There's considerable animus to regex in this list, but its complexity pales compared to Sort. I see error sources regardless: o JCL comments might look like DD statements, causing false positives. o Instream data sets even more so. o JCL might be built with symbol substitution, causing false negatives. o Likewise arguments to PROCs. The Swiss Army Knife is a wondrous facility, but there is probably a better tool to drive in a nail. (OT: is DFSORT Turing-complete?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: dfsort: Sort job to get price variance records
On 1/08/2019 8:03 am, Ron Thomas wrote: Hi. We have a FB File LRECL = 80 bytes and here below is the layout. Buy_price is at position 65 of length 10 bytes . We need to pull those item nbrs which has same UPC,Vendor nbr ,State Code but there is price difference. Could anyone let me know how this to be done using dfsort. I am curious, why do you want to use Sort to perform these tasks? The solutions are ingenious, but I wonder whether someone will be able to understand them if modification is required in the future. Maybe a more general programming language would be better? -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pervasive Encryption - why?
And I want to reiterate. For almost no cost, you can steer your company away from potentially disastrous litigation. Why would any management refuse that offer? . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of ITschak Mugzach Sent: Sunday, August 4, 2019 11:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Pervasive Encryption - why? And the major reason, it easy and allmost cost nothing. I have a client in the us that encrypted almost anything /(short block sizes are not supported). He claims that on z14 box cpu is almost the same. ITschak בתאריך יום א׳, 4 באוג׳ 2019, 19:51, מאת Lennie Dymoke-Bradshaw < lenni...@rsmpartners.com>: > Cameron, > > I missed this post the other day and I see many others have replied. > > My first reason for PE for data sets is that encryption protects the > data when it is accessed outside of its normal environment (i.e. not > via the data's normal RACF environment). So this includes removable > backups which are accessed away from your normal system. It covers > data extracted over PPRC links while being transferred to another > site. It also covers situations where production volumes may be > accessed from development LPARs or sysprog LPARs. This last case is > something I find at many sites. It is frequently justified in the name > of availability. I think if it was widely understood by auditors, they would > be raising a stink about it. > > My second reason is for compliance, whether that is to support GDPR, > PCI or whatever standard your installation is subject to. I have > always hoped that money spent on that compliance will actually improve > security. > > You may be interested in my paper on the backup of encrypted data. > https://rsmpartners.com/News.Data-Backups-&-PE-Technical-Paper.html > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > > Email:lenni...@rsmpartners.com > Web: www.rsmpartners.com > ‘Dance like no one is watching. Encrypt like everyone is.’ > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Cameron Conacher > Sent: 03 August 2019 17:49 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [IBM-MAIN] Pervasive Encryption - why? > > Hello everyone, > I have a curiousity question about Pervasive Encryption. > If we are already protecting resources with RACF, what additional > benefit do we get from Pervasive Encryption? I think it is a good > idea, since encrypted data lets me sleep better. Pervasive Encryption > appears to be very simple to implement. > My understanding (which may be incorrect) is that RACF will be used to > control encryption key access based on dataset profile rules and RACF rules. > If a RACF ID does not have access to the encryption keys then they > cannot access the dataset. > But at the same time, if a RACF ID does not have access to the > dataset, they cannot access it. > > So, if the underlying file is encrypted, what addition security is in > place? > Maybe if someone breaks into the data centre and steals the disk drives? > > If a hacker gets a RACF ID, and the RACF ID allows them to access the > dataset, then they can read the data. > But, isn't that where we are today? No RACF ID = no access. > > Obviously I am missing something here. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pervasive Encryption - why?
And the major reason, it easy and allmost cost nothing. I have a client in the us that encrypted almost anything /(short block sizes are not supported). He claims that on z14 box cpu is almost the same. ITschak בתאריך יום א׳, 4 באוג׳ 2019, 19:51, מאת Lennie Dymoke-Bradshaw < lenni...@rsmpartners.com>: > Cameron, > > I missed this post the other day and I see many others have replied. > > My first reason for PE for data sets is that encryption protects the data > when it is accessed outside of its normal environment (i.e. not via the > data's normal RACF environment). So this includes removable backups which > are accessed away from your normal system. It covers data extracted over > PPRC links while being transferred to another site. It also covers > situations where production volumes may be accessed from development LPARs > or sysprog LPARs. This last case is something I find at many sites. It is > frequently justified in the name of availability. I think if it was widely > understood by auditors, they would be raising a stink about it. > > My second reason is for compliance, whether that is to support GDPR, PCI > or whatever standard your installation is subject to. I have always hoped > that money spent on that compliance will actually improve security. > > You may be interested in my paper on the backup of encrypted data. > https://rsmpartners.com/News.Data-Backups-&-PE-Technical-Paper.html > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > > Email:lenni...@rsmpartners.com > Web: www.rsmpartners.com > ‘Dance like no one is watching. Encrypt like everyone is.’ > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Cameron Conacher > Sent: 03 August 2019 17:49 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [IBM-MAIN] Pervasive Encryption - why? > > Hello everyone, > I have a curiousity question about Pervasive Encryption. > If we are already protecting resources with RACF, what additional benefit > do we get from Pervasive Encryption? I think it is a good idea, since > encrypted data lets me sleep better. Pervasive Encryption appears to be > very simple to implement. > My understanding (which may be incorrect) is that RACF will be used to > control encryption key access based on dataset profile rules and RACF rules. > If a RACF ID does not have access to the encryption keys then they cannot > access the dataset. > But at the same time, if a RACF ID does not have access to the dataset, > they cannot access it. > > So, if the underlying file is encrypted, what addition security is in > place? > Maybe if someone breaks into the data centre and steals the disk drives? > > If a hacker gets a RACF ID, and the RACF ID allows them to access the > dataset, then they can read the data. > But, isn't that where we are today? No RACF ID = no access. > > Obviously I am missing something here. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pervasive Encryption - why?
Cameron, I missed this post the other day and I see many others have replied. My first reason for PE for data sets is that encryption protects the data when it is accessed outside of its normal environment (i.e. not via the data's normal RACF environment). So this includes removable backups which are accessed away from your normal system. It covers data extracted over PPRC links while being transferred to another site. It also covers situations where production volumes may be accessed from development LPARs or sysprog LPARs. This last case is something I find at many sites. It is frequently justified in the name of availability. I think if it was widely understood by auditors, they would be raising a stink about it. My second reason is for compliance, whether that is to support GDPR, PCI or whatever standard your installation is subject to. I have always hoped that money spent on that compliance will actually improve security. You may be interested in my paper on the backup of encrypted data. https://rsmpartners.com/News.Data-Backups-&-PE-Technical-Paper.html Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Email: lenni...@rsmpartners.com Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Cameron Conacher Sent: 03 August 2019 17:49 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] Pervasive Encryption - why? Hello everyone, I have a curiousity question about Pervasive Encryption. If we are already protecting resources with RACF, what additional benefit do we get from Pervasive Encryption? I think it is a good idea, since encrypted data lets me sleep better. Pervasive Encryption appears to be very simple to implement. My understanding (which may be incorrect) is that RACF will be used to control encryption key access based on dataset profile rules and RACF rules. If a RACF ID does not have access to the encryption keys then they cannot access the dataset. But at the same time, if a RACF ID does not have access to the dataset, they cannot access it. So, if the underlying file is encrypted, what addition security is in place? Maybe if someone breaks into the data centre and steals the disk drives? If a hacker gets a RACF ID, and the RACF ID allows them to access the dataset, then they can read the data. But, isn't that where we are today? No RACF ID = no access. Obviously I am missing something here. -- 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: Bruce Watts
He will be missed... :-( On 7/31/2019 8:15 AM, Steve Beaver wrote: If you did not known Bruce Watts died on 7/24 https://www.cochranfuneral.com/obituaries.php?L=w -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Getting ABEND reason code from attached subtask
what about the normal completion reason code (R0)? "Normal completion reason code" is not a concept supported by z/OS. Of course there is "value in R0 upon normal completion" but that is not surfaced. The TCB/STCB has the information that is available. Since you attached with ECB the TCB/STCB still remain, until you DETACH. STCBCMP/STCBCMPC is the best field for the return code (whether normal or abnormal completion). TCBARC has the abend reason code when bit TCBRV316 is on (looks like no one ever noticed the need to provide a suitable name for that bit, since it is never set directly in the code -- the abend macro ends up setting the bit into the high byte of the abend code). This is defined only for an abend event. I don't think the RB chain is intact at the time you are looking, so I don't think you can find the regs from time-of-normal-completion unless they're in the TCBGRSx fields (I did not check, but that seems very unlikely). It appears that TCBARC will have the value from the abend's R15 whether or not REASON was specified, but TCBRV316 will be off if REASON was not specified. At ABEND, R15 contains the REASON. To be picky, that is true only when the ABEND was issued with the REASON keyword. Otherwise, R15 contains a value that might or might not be considered a reason by the ABEND invoker. you can check the ABTERM flag in the subtask's TCB. The intended way to tell is now (and has been for quite a while) TcbEndingAbnormally (see the comments for STCBCMP). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
