Re: COBOL for z/OS V6R2M0
Fifth Third Bank is already being used. On Fri, Aug 2, 2019, 16:14 Chris Hoelscher wrote: > So does SECONDTENNESSEE move up to FIRSTTENNESSEE ?? > > Thank You, > Chris Hoelscher| ITI . DB Services . Mainframe Database | Humana Inc.| T > 502.476.2538 or 502.407.7266 > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of PINION, RICHARD W. > Sent: Friday, August 2, 2019 2:19 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [IBM-MAIN] COBOL for z/OS V6R2M0 > > I have updated the COBOL options using IGY620.SIGYSAMP(IGYWDOPT), SMP/E > usermod to update the COBOL options. IGY620.SIGYCOMP is in the system link > list, and the usermod updates IGYCDOPT in that load library. After > updating the module I refresh LLA with F LLA,REFRESH. > > I have used ISRDDN to search both the system link list and LPA for module > IGYCDOPT. It only appears in the link listed load library IGY620.SIGYLOAD. > > I have changed ARCH=7 to ARCH=12, OPT=0 to OPT=2, and NOBLOCK0 to BLOCK0. > The changes I have made do not show up when I run a COBOL compile after > applying the usermod, and refreshing LLA. I have tried RESTORING the > usermod, refreshing LLA, and APPLY'ing the usermod again. Still the same > results. > > This is a ADCD z/OS 2.3 system running on IBM's zPDT environment. > > EXCITING NEWS! Beginning this fall, First Tennessee will become First > Horizon. Learn more: thenewfirsthorizon.com > > Confidentiality notice: > This e-mail message, including any attachments, may contain legally > privileged and/or confidential information. If you are not the intended > recipient(s), or the employee or agent responsible for delivery of this > message to the intended recipient(s), you are hereby notified that any > dissemination, distribution, or copying of this e-mail message is strictly > prohibited. If you have received this message in error, please immediately > notify the sender and delete this e-mail message from your computer. > > -- > 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: Extract next eight character positions after SubString Match
The dataset-inventory information is available using IDCAMS/DCOLLECT utility and DFSORT/ICETOOL provides decoder-ring logic to analyze the DCOLLECT output and report on DATACLAS usage (as well as other SMS-construct usage) within your z/OS system, including DFHSM-migrated datasets as well as those non-migrated. Visit / search the IBM.COM DFSORT software/support website for details. Scott Barry SBBWorks, Inc. On Fri, 2 Aug 2019 15:55:56 -0400, Cameron Conacher wrote: >Hello John, >Yes, I need to hit this from both sides. >What DATACLAS do we have in the data library, and what DATACLAS has been >used for files that are already cataloged. >I just need to be sure to cover all of the bases. > >On Thu, Aug 1, 2019 at 12:50 PM John McKown >wrote: > >> On Thu, Aug 1, 2019 at 8:22 AM Cameron Conacher >> wrote: >> >> > Hello to the DFSORT folks. >> > 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. >> > I can use 'INCLUDE COND=(5,70,SS,EQ,C'DATACLAS=') to select a subset of >> > records from the original compare report. >> > I could take this file and play with it in ISPF EDIT to pull out the >> eight >> > bytes following 'DATACLAS='. >> > However, I am wondering if I can do this in DFSORT. >> > So, if I have >> > DATACLAS=FRED, >> > I would want to extract and summarize FRED and if I have >> >DATACLAS=POTATO I would want to extract and summarize POTATO >> > I guess the question is how can I extract characters from the input >> records >> > that appear following the SubString match? >> > >> > Thanks >> > >> >> >> Presenting an alternative route: The DATACLASS for a catalogued dataset is >> in the catalog. Maybe you could use some sort of catalog product to scan >> all your catalogs and extract the DSN and DATACLASS. >> >> -- >> A sine curve goes off to infinity, or at least the end of the blackboard. >> -- Prof. Steiner >> >> Maranatha! <>< >> John McKown >> >> -- >> 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: Capital One Data Breach-100 Million Customers affected
https://krebsonsecurity.com/2019/08/what-we-can-learn-from-the-capital-one-hack/ The details are OT to mainframes, of course. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Johnson Sent: Wednesday, July 31, 2019 9:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Capital One Data Breach-100 Million Customers affected She breached an incorrectly configured firewall. Sent from Yahoo Mail for iPhone On Tuesday, July 30, 2019, 7:48 PM, Edward Finnell <000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote: https://www.usatoday.com/story/money/2019/07/29/capital-one-data-breach-2019-millions-affected-new-breach/1863259001/ A CLOUDy day in data processing. -- 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: Capital One Data Breach-100 Million Customers affected
I think the main take-away is that in almost all cases its either software bugs, poor security defaults that don’t force changes in credentials / passwords, bad default configurations for ease of use which results in poor configurations or perhaps malice in the form of allowing a breach. We need to be as vigilant if not more on Z given the assets we protect. Matt Hogstrom PGP key 0F143BC1 > On Aug 3, 2019, at 09:48, Charles Mills wrote: > > https://krebsonsecurity.com/2019/08/what-we-can-learn-from-the-capital-one-hack/ > > > The details are OT to mainframes, of course. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Johnson > Sent: Wednesday, July 31, 2019 9:33 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Capital One Data Breach-100 Million Customers affected > > She breached an incorrectly configured firewall. > > > Sent from Yahoo Mail for iPhone > > > On Tuesday, July 30, 2019, 7:48 PM, Edward Finnell > <000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote: > > https://www.usatoday.com/story/money/2019/07/29/capital-one-data-breach-2019-millions-affected-new-breach/1863259001/ > > A CLOUDy day in data processing. > > -- > 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: Capital One Data Breach-100 Million Customers affected
Amen to that, Brother. And complexity, which makes it hard to get everything right (and you only need to get one or two things wrong to have a problem). That is what struck me reading the Krebs piece. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Matt Hogstrom Sent: Saturday, August 3, 2019 10:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Capital One Data Breach-100 Million Customers affected I think the main take-away is that in almost all cases its either software bugs, poor security defaults that don’t force changes in credentials / passwords, bad default configurations for ease of use which results in poor configurations or perhaps malice in the form of allowing a breach. We need to be as vigilant if not more on Z given the assets we protect. Matt Hogstrom PGP key 0F143BC1 > On Aug 3, 2019, at 09:48, Charles Mills wrote: > > https://krebsonsecurity.com/2019/08/what-we-can-learn-from-the-capital-one-hack/ > > > The details are OT to mainframes, of course. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bill Johnson > Sent: Wednesday, July 31, 2019 9:33 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Capital One Data Breach-100 Million Customers affected > > She breached an incorrectly configured firewall. > > > Sent from Yahoo Mail for iPhone > > > On Tuesday, July 30, 2019, 7:48 PM, Edward Finnell > <000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote: > > https://www.usatoday.com/story/money/2019/07/29/capital-one-data-breach-2019-millions-affected-new-breach/1863259001/ > > A CLOUDy day in data processing. > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO 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
Re: COBOL for z/OS V6R2M0
If it is truly the case that the new version of the module is not being used, then clearly the old version is being found somewhere. If you have replaced the copy in the only data set where it lives and refreshed LLA, then these are the possibilities that come to mind -- you are not re-fetching at all because your jobstep has already fetched the previous copy and that copy is still usable -- you do have a tasklib, steplib, or joblib -- the fetch is being done identifying an opened DCB within which concatenation the previous copy exists -- the original copy is in LPA and your updated copy is not (whether by PLPA, MLPA, FLPA, or dynamic LPA) I presume that if the Cobol compiler found your new version but didn't like it in some way (so reverted to old behavior) it would tell you. Various fetch monitoring tools can provide some clue of where a module was found when it was fetched. 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
Re: Pervasive Encryption - why?
One use case is backups. If someone can access a backup outside of the controls the system it resides on employs they could not compromise the data. Consider potential data services that host backups offsite for instance. Your protecting your data while entrusting someone with ensuring its available That’s a strong use case I think Matt Hogstrom +1 (919) 656-0564 > On Aug 3, 2019, at 12:48, Cameron Conacher wrote: > > 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: Pervasive Encryption - why?
On Sat, 3 Aug 2019 13:24:46 -0400, Matt Hogstrom wrote: >One use case is backups. If someone can access a backup outside of the >controls the system it resides on employs they could not compromise the data. >Consider potential data services that host backups offsite for instance. Your >protecting your data while entrusting someone with ensuring its available >> On Aug 3, 2019, at 12:48, Cameron Conacher wrote: >> ... >> 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? >> Or, compromises a communication channel to remote storage. -- gil -- 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?
Hello Matt, I am not sure about backups. This is Pervasive Encryption. So, again my understanding is that IF your RACFID can access the file, you will read the data and it will be presented to you as unencrypted. Now, if you write it to DASD and encryption is on for that device it will be encrypted, otherwise not encrypted. And if you write it to TAPE, then it depends what your tape systems does. I am just trying to find that corner case where someone you don't want to have access, could possibly be able to gain access to the data when the file is already protected with RACF? I cannot see a blackhat breaking into the mainframe. If they did manage that, I cannot see them bypassing RACF. If they did, manage to get by RACF, then regardless of whether or not the file was encrypted, they ought to be able to read it, since they have somehow gotten RACF access. Same is true for an internal compromise. If you can get RACF access to the file, it will not matter whether or not the data is encrypted. Maybe I am missing something. Physically taking a drive is the only one I have come up with so far. I like the idea of encryption. If we decommission a drive and somehow it ends up on eBay, the data is useless. But, there would need to be a lot of processes that are ignored/bypassed to get that far. On Sat, Aug 3, 2019 at 1:25 PM Matt Hogstrom wrote: > One use case is backups. If someone can access a backup outside of the > controls the system it resides on employs they could not compromise the > data. Consider potential data services that host backups offsite for > instance. Your protecting your data while entrusting someone with ensuring > its available > > That’s a strong use case I think > > Matt Hogstrom > +1 (919) 656-0564 > > > On Aug 3, 2019, at 12:48, Cameron Conacher wrote: > > > > 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?
The protective side of data security is only half technical. The other half is GDPR (General Data Protection Regulation), a set of controls that spell out Draconian penalties for any entity that allows--or presides over--a data breach affecting EU citizens. The hair-raising penalties are more or less forgiven if the stolen data is encrypted. There is no consideration in the regulations for software or hardware security mechanisms such as SAF (RACF, ACF2, TSS) . That makes pervasive encryption hugely valuable. If data is breached, it will be presumably useless to the perpetrator. You can't hire enough lawyers to equal that advantage. . . 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 Matt Hogstrom Sent: Saturday, August 3, 2019 10:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Pervasive Encryption - why? One use case is backups. If someone can access a backup outside of the controls the system it resides on employs they could not compromise the data. Consider potential data services that host backups offsite for instance. Your protecting your data while entrusting someone with ensuring its available That’s a strong use case I think Matt Hogstrom +1 (919) 656-0564 > On Aug 3, 2019, at 12:48, Cameron Conacher wrote: > > 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
Getting ABEND reason code from attached subtask
I'm curious. Say that I have something like: ATTACH EP=MYPROG,ECB=MYECB LTR R15,R15 BZ ATTERR ST R1,MYTCB WAIT 1,ECB=MYECB DETACH MYTCB I know that I can get either the subtask return code or ABEND completion code(s) from the ECB. But in the case of an ABEND, is there an easy way to get the reason code? Or do I need an ESTAI routine on the ATTACH to capture that? Similarly, what about the normal completion reason code (R0)? Thanks, Kirk Wolf Dovetailed Technologies http://dovetail.com -- 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?
There are some good presentations on SHARE about this. The point about backups is that the backups are made of the encrypted file, by personnel and software that do *not* have the access to the decryption key. That allows admins & sysprogs to manage storage & such without having the ability to actually read the data. And any copies or backups are secure. Users & systems that do have the authorization to decrypt and access the data are responsible for not compromising that access. That's no different with pervasive encryption. Making unencrypted copies would pretty much destroy the usefulness of pervasive encryption. So presumably (hopefully) you have other controls to stop users from doing that. Anyway, it's a piece of the puzzle. sas -- 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
Is the RB chain intact after an ABEND? If so, you can look at R15. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Kirk Wolf Sent: Saturday, August 3, 2019 2:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Getting ABEND reason code from attached subtask I'm curious. Say that I have something like: ATTACH EP=MYPROG,ECB=MYECB LTR R15,R15 BZ ATTERR ST R1,MYTCB WAIT 1,ECB=MYECB DETACH MYTCB I know that I can get either the subtask return code or ABEND completion code(s) from the ECB. But in the case of an ABEND, is there an easy way to get the reason code? Or do I need an ESTAI routine on the ATTACH to capture that? Similarly, what about the normal completion reason code (R0)? Thanks, Kirk Wolf Dovetailed Technologies http://secure-web.cisco.com/1dsNePaOANn8XRbYwmnZpDKwNBiSFxchJB8OqygwaXMjrIA1rN8R-MMyngCIk3Zuz0G0vDKG_rD8RVD9P9hwPJcN6eS4LKSthQcKYRpVph3Pj6unY5PpuIVQz3zFIt4QQjOacglgeOUFn92mswmebcNvTXA4xo955wRLxa9PNl9aJMAQuPCUwHsmJRjLd7pbqQS1LMEf-OlmknK1R5bWVVahZiCEhih605vn4TOKIg2jHXkaDs9UO5xJGtAUm4fOjPcJIdsbNvje7O3dWx188nUwdTsSNAzkCVa1z_dcAyRrVhg-5nlwaJSfn6fo-6npw10UbbFCIIGr8rTDFj810ZupilRA8y8E_99luw6zQPxp4K9t3BeejLHUmxurvoGCSBOZaKhKDAo5406seFYwdJg4_b-3p562Gvkij01do6AcnxcouflqxflZnucNmTjhh/http%3A%2F%2Fdovetail.com -- 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: Getting ABEND reason code from attached subtask
@Kirk, is the ABEND reason code somewhere in the TCB? I would do the search but you can do it as well as I. Is R0 = normal completion reason code "architected"? I don't recall that it is. It is something of a convention, but is it an "MVS linkage"? If not, I *suspect* the contents of R0 have vanished. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf Sent: Saturday, August 3, 2019 2:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Getting ABEND reason code from attached subtask I'm curious. Say that I have something like: ATTACH EP=MYPROG,ECB=MYECB LTR R15,R15 BZ ATTERR ST R1,MYTCB WAIT 1,ECB=MYECB DETACH MYTCB I know that I can get either the subtask return code or ABEND completion code(s) from the ECB. But in the case of an ABEND, is there an easy way to get the reason code? Or do I need an ESTAI routine on the ATTACH to capture that? Similarly, what about the normal completion reason code (R0)? -- 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?
Others have mentioned backups. The real value is in the right to *do* backups. Your storage administrator may have access to the dataset, but not the decryption key. So he can do backups, but he can't steal credit card numbers or health information. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Cameron Conacher Sent: Saturday, August 3, 2019 12:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 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: Getting ABEND reason code from attached subtask
ITYM R15. description of ABEND includes " ,REASON=reason code". -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Saturday, August 3, 2019 4:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Getting ABEND reason code from attached subtask @Kirk, is the ABEND reason code somewhere in the TCB? I would do the search but you can do it as well as I. Is R0 = normal completion reason code "architected"? I don't recall that it is. It is something of a convention, but is it an "MVS linkage"? If not, I *suspect* the contents of R0 have vanished. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf Sent: Saturday, August 3, 2019 2:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Getting ABEND reason code from attached subtask I'm curious. Say that I have something like: ATTACH EP=MYPROG,ECB=MYECB LTR R15,R15 BZ ATTERR ST R1,MYTCB WAIT 1,ECB=MYECB DETACH MYTCB I know that I can get either the subtask return code or ABEND completion code(s) from the ECB. But in the case of an ABEND, is there an easy way to get the reason code? Or do I need an ESTAI routine on the ATTACH to capture that? Similarly, what about the normal completion reason code (R0)? -- 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?
Thanks everyone. That certainly helps. On Sat, Aug 3, 2019 at 4:31 PM Charles Mills wrote: > Others have mentioned backups. The real value is in the right to *do* > backups. Your storage administrator may have access to the dataset, but not > the decryption key. So he can do backups, but he can't steal credit card > numbers or health information. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Cameron Conacher > Sent: Saturday, August 3, 2019 12:49 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: 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: Getting ABEND reason code from attached subtask
At ABEND, R15 contains the REASON. For a normal return, R15 contains the return code, and R0 often contains a reason, but that is a weaker convention. On a normal return, registers come back however the called program sets them. However, a subtask returns to the system. Maybe you could find the extant contents of R0 somewhere, but that isn't usually done. If really necessary, I'd probably consider a shell program to handle it. As for distinguishing between an ABEND code and RC in the ECB, you can check the ABTERM flag in the subtask's TCB. sas On Sat, Aug 3, 2019 at 4:54 PM Seymour J Metz wrote: > ITYM R15. > > description of ABEND includes " ,REASON=reason code". -- 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
On 2019-08-04 4:06 AM, Kirk Wolf wrote: I'm curious. Say that I have something like: ATTACH EP=MYPROG,ECB=MYECB LTR R15,R15 BZ ATTERR ST R1,MYTCB WAIT 1,ECB=MYECB DETACH MYTCB I know that I can get either the subtask return code or ABEND completion code(s) from the ECB. But in the case of an ABEND, is there an easy way to get the reason code? Or do I need an ESTAI routine on the ATTACH to capture that? Similarly, what about the normal completion reason code (R0)? Should that be BNZ ATTERR ? By the time control returns after the ATTACH, you don't really know if the subtask has started, is running, or has completed unless you have organised some inter-task protocol. After the WAIT on the ECB has popped, you know the task has completed. Further, the subtask's resources that it owned such as virtual storage and probably ENQs and maybe even Name/Token pairs and such have also gone. The programs it loaded have been deleted, and it is no longer on the TCBTCB chain. All that you are entitled to assume is that the TCB and the STCB are still extant, and it is still in the TCBOTC/TCBLTC+TCBNTC tree. The TCB and STCB will be deleted by the DETACH. Before issuing the DETACH, you can harvest the TCBCMP word and the TCBARC word. I have also been known to extract the task's CPU time before issuing DETACH. The TCBRV316 bit in the TCBCMPF byte will tell you if the abend actually set a reason code. For the occasions that I code both the attaching task and the attached task, I have been guilty of knowing that the attached task does not issue any user abends, and have consequently used logic which assumes an abend only if the 12 system abend code bits are not all zeros. I expect I should have used the TCBENDINGABNORMALLY bit in the TCBFLGS8 byte. Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
