Re: REXX vs other languages WAS: Rexx numeric digits and scientific notation question
There is no automatic environment integration. There is an API that makes it easy for the developer of an application to support Rexx scripts and there are environments whose developers have exploited that API. ooRexx is not inferior in that regard. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Jon Perryman Sent: Monday, April 15, 2024 1:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: REXX vs other languages WAS: Rexx numeric digits and scientific notation question >Java's not perfect, but it is powerful and it is pretty much universally >available on z/OS. People don't understand the ingenuity behind REXX and don't understand the real problems it solves. From a language standpoint, REXX is just another language but it's real strength is it's environment integration. Instead of the caller maintaining libraries, the environment automatically integrates with REXX. For instance, REXX in the TSO environment, gives you access to TSO commands (address TSO) and z/OS programs (address linkmvs). Start ISPF and address ISPEXEC is available. ISPF option 2 gives you address ISREDIT. SYSCALLS ON gives you address syscalls. For product developers, REXX is simple to integrate environments as witnessed by the plethora of integrated environments on z/VM, z/OS and probably z/VSE (e.g. some addressable environments: automation, CICS, CMS, CP, TSO, UNIX, SYSCALLS and more) OOREXX is not REXX because it does not have the automatic environment integration and as you say, using JAVA instead of OOREXX would be preferable. REXX on the other hand is preferable over JAVA in many IBM environments. For instance, why would you use JAVA as your system automation environment language? The complication of using OOP REXX is rarely beneficial for most environments. Generally, you are not building complicated applications. For instance, system automation will be the most complex but managing events under objects would be complicated and unmanageable given the current automation environment design. -- 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: ./ ADD - which utility?
On Tue, 16 Apr 2024 07:17:35 +1000, Wayne Bickerdike wrote: >I guess when the utility was developed JCL was way simpler and test cases >were limited. > >After Gil raised the various gotchas, I wrote myself a PUTPDS program with >a user defined delimiter. Eschewing 2 bytes means I can come up with a very >random string such as !@#$%^&* ADD NAME=MEMBER. Not likely to be embedded >in usual members. > >Now adding some bells and whistles. Not that I need it in retirement. Golf >today. > Bravo! Although I still favor off-the-shelf techniques such as IEBCOPY and TRANSMIT. Although those lack the flexibility of editable text transport containers. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IMS - DFSRRC00 vs ODBA
VSAM? No IMS / DB2 overhead. Datacom? PS-FB. On Mon, Apr 15, 2024 at 5:08 PM Pierre Fichaud wrote: > > I think in most cases, the database will be local. > > Assuming local, is access faster using DFSRRC00 or ODBA. > > If not local, what is faster? > > Thnx, Pierre > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: IBM key management products
If they hadn't had glass platters I would have seriously considered it! I didn't want to have the glass mess. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jousma, David Sent: Monday, April 15, 2024 2:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: IBM key management products Would have been fun to line them up on a fence, and do some target practice!!! Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of Pommier, Rex Date: Monday, April 15, 2024 at 2:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: IBM key management products Didn't phase the drill bit one bit (sorry for the bad pun). I just had to be careful not to punch a hole in the bottom of the drives so as to not get glass shards dropping on my (very messy) shop floor. -Original Message- From: IBM Didn't phase the drill bit one bit (sorry for the bad pun). I just had to be careful not to punch a hole in the bottom of the drives so as to not get glass shards dropping on my (very messy) shop floor. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Monday, April 15, 2024 12:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: IBM key management products Nice! That's the first I've heard of glass platters. Hope your drill bit survived the trauma :) On 4/15/2024 8:33 AM, Pommier, Rex wrote: > Hi Tom, > > Regarding #2, at a former job I got to decommission an HDS box that > was shared between the mainframe and Unix boxes. Unencrypted disk in > it. Mgmt wanted the data destroyed so they asked me to take the > individual drives home and drill through each of them. That was when > I found out that this particular disk drive had glass platters. There > was no getting data off them when the drill bit shattered every > platter in every spindle. > > Rex > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Tom Brennan > Sent: Friday, April 12, 2024 1:41 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: IBM key management products > > We use SKLM/GKLM for data-at-rest encryption of DS8000/TS7000 devices, all > internal disk storage, no external cartridge tapes. So what does that do for > the customer, since (unless you're using an additional form of encryption on > the mainframe) the data is still spit out of the devices unencrypted (not > counting the additional feature that allows FICON-in-transit encryption). > > I have a few theories on this: > > #1 If someone gets into the datacenter and steals disks (or the entire DS/TS > box), the encrypted contents should be useless. > > #2 When a DS/TS box is decommissioned, a customer could "potentially" > skip any further destruction of the data in the box. Still, what I've > seen in reality for decom is to run the IBM SDO (secure data overwrite > to blot out the disks) and sometimes even shred the individual disks > (I'd sure like to see that in action!) > > #3 If you steal a DS/TS box, make sure you steal the associated key server > unit too. > > I'd appreciate any comments on these theories. > > On 4/12/2024 9:21 AM, Jousma, David wrote: >> To place a bit more focus on what Rick says….. You lose/destroy the key(s), >> you have lost your data. There is a lot of discussion about the scope/use >> of the keys. One key, or one per application, or one per dataset, etc. >> There is no right/wrong answer (well just one key for everything is probably >> not advisable). >> >> I personally am still having a hard time wrapping my head around the “real >> benefit” of dataset encryption. Everyone who has READ or more access to >> the dataset, must also be permitted to the Key. Those same people are >> still able to copy/print/steal that data.So who does that leave? Those >> that are not permitted to the dataset, and those who administer the storage. >>Those that don’t have access to the dataset aren’t going to get the data, >> encrypted or not. Those who administer the storage usually have access to >> move/manage the installations data.These are the people who dataset >> encryption is protecting against. That is a very small population to go to >> this effort on. >> >> Dave Jousma >> Vice President | Director, Technology Engineering >> >> >> >> >> >> From: IBM Mainframe Discussion List on >> behalf of Rick Troth <058ff5c2d0a7-dmarc-requ...@listserv.ua.edu> >> Date: Friday, April 12, 2024 at 10:59 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: IBM key management products Not discounting Luke's >> excellent response: key management is hard. Look for utilities with >> reliable import/export capability. Be prepared to OWN your keys. I >> say this again as a CISSP, own your keys. This is your bread and >> butter, so to speak, >> >> >> Not discounting
Re: IMS - DFSRRC00 vs ODBA
I think in most cases, the database will be local. Assuming local, is access faster using DFSRRC00 or ODBA. If not local, what is faster? Thnx, Pierre -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ./ ADD - which utility?
I guess when the utility was developed JCL was way simpler and test cases were limited. After Gil raised the various gotchas, I wrote myself a PUTPDS program with a user defined delimiter. Eschewing 2 bytes means I can come up with a very random string such as !@#$%^&* ADD NAME=MEMBER. Not likely to be embedded in usual members. Now adding some bells and whistles. Not that I need it in retirement. Golf today. On Tue, Apr 16, 2024 at 12:47 AM Steve Thompson wrote: > In a single word, yes. > > And as has been stated, setting up "DLM=" requires, at times, a > scan of just the first several bytes of each logical record to > find what unique value(s) one can use. > > Steve Thompson > > On 4/15/2024 3:30 AM, wrote: > > Just curious. Have anyone had problem with this delimiter problem in > real life with anything other than JCL in the inline input data? > > (I mean the alternative of a separate file seems to be a better/normal > alternative unless the inline data is at the end of the member/ds.) > > > > -- > > 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 > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: IBM key management products
Would have been fun to line them up on a fence, and do some target practice!!! Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of Pommier, Rex Date: Monday, April 15, 2024 at 2:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: IBM key management products Didn't phase the drill bit one bit (sorry for the bad pun). I just had to be careful not to punch a hole in the bottom of the drives so as to not get glass shards dropping on my (very messy) shop floor. -Original Message- From: IBM Didn't phase the drill bit one bit (sorry for the bad pun). I just had to be careful not to punch a hole in the bottom of the drives so as to not get glass shards dropping on my (very messy) shop floor. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Monday, April 15, 2024 12:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: IBM key management products Nice! That's the first I've heard of glass platters. Hope your drill bit survived the trauma :) On 4/15/2024 8:33 AM, Pommier, Rex wrote: > Hi Tom, > > Regarding #2, at a former job I got to decommission an HDS box that > was shared between the mainframe and Unix boxes. Unencrypted disk in > it. Mgmt wanted the data destroyed so they asked me to take the > individual drives home and drill through each of them. That was when > I found out that this particular disk drive had glass platters. There > was no getting data off them when the drill bit shattered every > platter in every spindle. > > Rex > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Tom Brennan > Sent: Friday, April 12, 2024 1:41 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: IBM key management products > > We use SKLM/GKLM for data-at-rest encryption of DS8000/TS7000 devices, all > internal disk storage, no external cartridge tapes. So what does that do for > the customer, since (unless you're using an additional form of encryption on > the mainframe) the data is still spit out of the devices unencrypted (not > counting the additional feature that allows FICON-in-transit encryption). > > I have a few theories on this: > > #1 If someone gets into the datacenter and steals disks (or the entire DS/TS > box), the encrypted contents should be useless. > > #2 When a DS/TS box is decommissioned, a customer could "potentially" > skip any further destruction of the data in the box. Still, what I've > seen in reality for decom is to run the IBM SDO (secure data overwrite > to blot out the disks) and sometimes even shred the individual disks > (I'd sure like to see that in action!) > > #3 If you steal a DS/TS box, make sure you steal the associated key server > unit too. > > I'd appreciate any comments on these theories. > > On 4/12/2024 9:21 AM, Jousma, David wrote: >> To place a bit more focus on what Rick says….. You lose/destroy the key(s), >> you have lost your data. There is a lot of discussion about the scope/use >> of the keys. One key, or one per application, or one per dataset, etc. >> There is no right/wrong answer (well just one key for everything is probably >> not advisable). >> >> I personally am still having a hard time wrapping my head around the “real >> benefit” of dataset encryption. Everyone who has READ or more access to >> the dataset, must also be permitted to the Key. Those same people are >> still able to copy/print/steal that data.So who does that leave? Those >> that are not permitted to the dataset, and those who administer the storage. >>Those that don’t have access to the dataset aren’t going to get the data, >> encrypted or not. Those who administer the storage usually have access to >> move/manage the installations data.These are the people who dataset >> encryption is protecting against. That is a very small population to go to >> this effort on. >> >> Dave Jousma >> Vice President | Director, Technology Engineering >> >> >> >> >> >> From: IBM Mainframe Discussion List on >> behalf of Rick Troth <058ff5c2d0a7-dmarc-requ...@listserv.ua.edu> >> Date: Friday, April 12, 2024 at 10:59 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: IBM key management products Not discounting Luke's >> excellent response: key management is hard. Look for utilities with >> reliable import/export capability. Be prepared to OWN your keys. I >> say this again as a CISSP, own your keys. This is your bread and >> butter, so to speak, >> >> >> Not discounting Luke's excellent response: key management is hard. >> >> Look for utilities with reliable import/export capability. Be >> prepared >> >> to OWN your keys. >> >> I say this again as a CISSP, own your keys. This is your bread and >> >> butter, so to speak, the family jewels. >> >> So take care when using these products
Re: IMS - DFSRRC00 vs ODBA
If the database is local, ODBC will slow it down. DFSRRC00 is batch oriented ( may run with TM/DBCTL as well). The question you need to answer is where the database is. ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* בתאריך יום ב׳, 15 באפר׳ 2024 ב-20:06 מאת Pierre Fichaud : > To All, > My IMS is somewhat limited and my terminology may be incorrect. > > Is there a performance difference between 1) executing DFSRRC00 and > 2) executing an assembler program that uses ODBA calls ? > 1) An assembler routine and a PSB name would be provided to DFSRRC00. > I'm not sure what API is used in this case. > 2) The assembler program (JOB STEP program) would be supplied a PSB > name. > The calls would be CIMS INIT, APSB, GN, DPSB, TERM and TALL using > AERTDLI. > Thanks in advance, Pierre. > > > > -- > 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: [EXTERNAL] Re: IBM key management products
Nope, but I did take the now-holy disks back to work to show them the destruction. -Original Message- From: IBM Mainframe Discussion List On Behalf Of rpinion865 Sent: Monday, April 15, 2024 1:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: IBM key management products Did you have the auditors present so they could certify your actions :) ? Sent with Proton Mail secure email. On Monday, April 15th, 2024 at 2:32 PM, Pommier, Rex wrote: > Didn't phase the drill bit one bit (sorry for the bad pun). I just had to be > careful not to punch a hole in the bottom of the drives so as to not get > glass shards dropping on my (very messy) shop floor. > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf > Of Tom Brennan > > Sent: Monday, April 15, 2024 12:57 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [EXTERNAL] Re: IBM key management products > > Nice! That's the first I've heard of glass platters. Hope your drill > bit survived the trauma :) > > On 4/15/2024 8:33 AM, Pommier, Rex wrote: > > > Hi Tom, > > > > Regarding #2, at a former job I got to decommission an HDS box that > > was shared between the mainframe and Unix boxes. Unencrypted disk in > > it. Mgmt wanted the data destroyed so they asked me to take the > > individual drives home and drill through each of them. That was when > > I found out that this particular disk drive had glass platters. > > There was no getting data off them when the drill bit shattered > > every platter in every spindle. > > > > Rex > > > > -Original Message- > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On > > Behalf Of Tom Brennan > > Sent: Friday, April 12, 2024 1:41 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: [EXTERNAL] Re: IBM key management products > > > > We use SKLM/GKLM for data-at-rest encryption of DS8000/TS7000 devices, all > > internal disk storage, no external cartridge tapes. So what does that do > > for the customer, since (unless you're using an additional form of > > encryption on the mainframe) the data is still spit out of the devices > > unencrypted (not counting the additional feature that allows > > FICON-in-transit encryption). > > > > I have a few theories on this: > > > > #1 If someone gets into the datacenter and steals disks (or the entire > > DS/TS box), the encrypted contents should be useless. > > > > #2 When a DS/TS box is decommissioned, a customer could "potentially" > > skip any further destruction of the data in the box. Still, what > > I've seen in reality for decom is to run the IBM SDO (secure data > > overwrite to blot out the disks) and sometimes even shred the > > individual disks (I'd sure like to see that in action!) > > > > #3 If you steal a DS/TS box, make sure you steal the associated key server > > unit too. > > > > I'd appreciate any comments on these theories. > > > > On 4/12/2024 9:21 AM, Jousma, David wrote: > > > > > To place a bit more focus on what Rick says….. You lose/destroy the > > > key(s), you have lost your data. There is a lot of discussion about the > > > scope/use of the keys. One key, or one per application, or one per > > > dataset, etc. There is no right/wrong answer (well just one key for > > > everything is probably not advisable). > > > > > > I personally am still having a hard time wrapping my head around the > > > “real benefit” of dataset encryption. Everyone who has READ or more > > > access to the dataset, must also be permitted to the Key. Those same > > > people are still able to copy/print/steal that data. So who does that > > > leave? Those that are not permitted to the dataset, and those who > > > administer the storage. Those that don’t have access to the dataset > > > aren’t going to get the data, encrypted or not. Those who administer the > > > storage usually have access to move/manage the installations data. These > > > are the people who dataset encryption is protecting against. That is a > > > very small population to go to this effort on. > > > > > > Dave Jousma > > > Vice President | Director, Technology Engineering > > > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on > > > behalf of Rick Troth > > > 058ff5c2d0a7-dmarc-requ...@listserv.ua.edu > > > Date: Friday, April 12, 2024 at 10:59 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: IBM key management products Not discounting Luke's > > > excellent response: key management is hard. Look for utilities > > > with reliable import/export capability. Be prepared to OWN your > > > keys. I say this again as a CISSP, own your keys. This is your > > > bread and butter, so to speak, > > > > > > Not discounting Luke's excellent response: key management is hard. > > > > > > Look for utilities with reliable import/export capability. Be > > > prepared > > > > > > to OWN your keys. > > > > > > I say this
Re: IMS - DFSRRC00 vs ODBA
If the database is local, ODBC will slow it down. DFSRRC00 is batch oriented ( may run with TM/DBCTL as well). The question you need to answer is where the database is. ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* בתאריך יום ב׳, 15 באפר׳ 2024 ב-20:06 מאת Pierre Fichaud : > To All, > My IMS is somewhat limited and my terminology may be incorrect. > > Is there a performance difference between 1) executing DFSRRC00 and > 2) executing an assembler program that uses ODBA calls ? > 1) An assembler routine and a PSB name would be provided to DFSRRC00. > I'm not sure what API is used in this case. > 2) The assembler program (JOB STEP program) would be supplied a PSB > name. > The calls would be CIMS INIT, APSB, GN, DPSB, TERM and TALL using > AERTDLI. > Thanks in advance, Pierre. > > > > -- > 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: [EXTERNAL] Re: IBM key management products
Did you have the auditors present so they could certify your actions :) ? Sent with Proton Mail secure email. On Monday, April 15th, 2024 at 2:32 PM, Pommier, Rex wrote: > Didn't phase the drill bit one bit (sorry for the bad pun). I just had to be > careful not to punch a hole in the bottom of the drives so as to not get > glass shards dropping on my (very messy) shop floor. > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of Tom > Brennan > > Sent: Monday, April 15, 2024 12:57 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [EXTERNAL] Re: IBM key management products > > Nice! That's the first I've heard of glass platters. Hope your drill bit > survived the trauma :) > > On 4/15/2024 8:33 AM, Pommier, Rex wrote: > > > Hi Tom, > > > > Regarding #2, at a former job I got to decommission an HDS box that > > was shared between the mainframe and Unix boxes. Unencrypted disk in > > it. Mgmt wanted the data destroyed so they asked me to take the > > individual drives home and drill through each of them. That was when > > I found out that this particular disk drive had glass platters. There > > was no getting data off them when the drill bit shattered every > > platter in every spindle. > > > > Rex > > > > -Original Message- > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On > > Behalf Of Tom Brennan > > Sent: Friday, April 12, 2024 1:41 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: [EXTERNAL] Re: IBM key management products > > > > We use SKLM/GKLM for data-at-rest encryption of DS8000/TS7000 devices, all > > internal disk storage, no external cartridge tapes. So what does that do > > for the customer, since (unless you're using an additional form of > > encryption on the mainframe) the data is still spit out of the devices > > unencrypted (not counting the additional feature that allows > > FICON-in-transit encryption). > > > > I have a few theories on this: > > > > #1 If someone gets into the datacenter and steals disks (or the entire > > DS/TS box), the encrypted contents should be useless. > > > > #2 When a DS/TS box is decommissioned, a customer could "potentially" > > skip any further destruction of the data in the box. Still, what I've > > seen in reality for decom is to run the IBM SDO (secure data overwrite > > to blot out the disks) and sometimes even shred the individual disks > > (I'd sure like to see that in action!) > > > > #3 If you steal a DS/TS box, make sure you steal the associated key server > > unit too. > > > > I'd appreciate any comments on these theories. > > > > On 4/12/2024 9:21 AM, Jousma, David wrote: > > > > > To place a bit more focus on what Rick says….. You lose/destroy the > > > key(s), you have lost your data. There is a lot of discussion about the > > > scope/use of the keys. One key, or one per application, or one per > > > dataset, etc. There is no right/wrong answer (well just one key for > > > everything is probably not advisable). > > > > > > I personally am still having a hard time wrapping my head around the > > > “real benefit” of dataset encryption. Everyone who has READ or more > > > access to the dataset, must also be permitted to the Key. Those same > > > people are still able to copy/print/steal that data. So who does that > > > leave? Those that are not permitted to the dataset, and those who > > > administer the storage. Those that don’t have access to the dataset > > > aren’t going to get the data, encrypted or not. Those who administer the > > > storage usually have access to move/manage the installations data. These > > > are the people who dataset encryption is protecting against. That is a > > > very small population to go to this effort on. > > > > > > Dave Jousma > > > Vice President | Director, Technology Engineering > > > > > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on > > > behalf of Rick Troth 058ff5c2d0a7-dmarc-requ...@listserv.ua.edu > > > Date: Friday, April 12, 2024 at 10:59 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: IBM key management products Not discounting Luke's > > > excellent response: key management is hard. Look for utilities with > > > reliable import/export capability. Be prepared to OWN your keys. I > > > say this again as a CISSP, own your keys. This is your bread and > > > butter, so to speak, > > > > > > Not discounting Luke's excellent response: key management is hard. > > > > > > Look for utilities with reliable import/export capability. Be > > > prepared > > > > > > to OWN your keys. > > > > > > I say this again as a CISSP, own your keys. This is your bread and > > > > > > butter, so to speak, the family jewels. > > > > > > So take care when using these products to ensure that they do what > > > you > > > > > > want them to do and that you know what they're doing. > > > > > > One shop where I recently worked had a great
Re: [EXTERNAL] Re: IBM key management products
Didn't phase the drill bit one bit (sorry for the bad pun). I just had to be careful not to punch a hole in the bottom of the drives so as to not get glass shards dropping on my (very messy) shop floor. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Monday, April 15, 2024 12:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: IBM key management products Nice! That's the first I've heard of glass platters. Hope your drill bit survived the trauma :) On 4/15/2024 8:33 AM, Pommier, Rex wrote: > Hi Tom, > > Regarding #2, at a former job I got to decommission an HDS box that > was shared between the mainframe and Unix boxes. Unencrypted disk in > it. Mgmt wanted the data destroyed so they asked me to take the > individual drives home and drill through each of them. That was when > I found out that this particular disk drive had glass platters. There > was no getting data off them when the drill bit shattered every > platter in every spindle. > > Rex > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Tom Brennan > Sent: Friday, April 12, 2024 1:41 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: IBM key management products > > We use SKLM/GKLM for data-at-rest encryption of DS8000/TS7000 devices, all > internal disk storage, no external cartridge tapes. So what does that do for > the customer, since (unless you're using an additional form of encryption on > the mainframe) the data is still spit out of the devices unencrypted (not > counting the additional feature that allows FICON-in-transit encryption). > > I have a few theories on this: > > #1 If someone gets into the datacenter and steals disks (or the entire DS/TS > box), the encrypted contents should be useless. > > #2 When a DS/TS box is decommissioned, a customer could "potentially" > skip any further destruction of the data in the box. Still, what I've > seen in reality for decom is to run the IBM SDO (secure data overwrite > to blot out the disks) and sometimes even shred the individual disks > (I'd sure like to see that in action!) > > #3 If you steal a DS/TS box, make sure you steal the associated key server > unit too. > > I'd appreciate any comments on these theories. > > On 4/12/2024 9:21 AM, Jousma, David wrote: >> To place a bit more focus on what Rick says….. You lose/destroy the key(s), >> you have lost your data. There is a lot of discussion about the scope/use >> of the keys. One key, or one per application, or one per dataset, etc. >> There is no right/wrong answer (well just one key for everything is probably >> not advisable). >> >> I personally am still having a hard time wrapping my head around the “real >> benefit” of dataset encryption. Everyone who has READ or more access to >> the dataset, must also be permitted to the Key. Those same people are >> still able to copy/print/steal that data.So who does that leave? Those >> that are not permitted to the dataset, and those who administer the storage. >>Those that don’t have access to the dataset aren’t going to get the data, >> encrypted or not. Those who administer the storage usually have access to >> move/manage the installations data.These are the people who dataset >> encryption is protecting against. That is a very small population to go to >> this effort on. >> >> Dave Jousma >> Vice President | Director, Technology Engineering >> >> >> >> >> >> From: IBM Mainframe Discussion List on >> behalf of Rick Troth <058ff5c2d0a7-dmarc-requ...@listserv.ua.edu> >> Date: Friday, April 12, 2024 at 10:59 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: IBM key management products Not discounting Luke's >> excellent response: key management is hard. Look for utilities with >> reliable import/export capability. Be prepared to OWN your keys. I >> say this again as a CISSP, own your keys. This is your bread and >> butter, so to speak, >> >> >> Not discounting Luke's excellent response: key management is hard. >> >> Look for utilities with reliable import/export capability. Be >> prepared >> >> to OWN your keys. >> >> I say this again as a CISSP, own your keys. This is your bread and >> >> butter, so to speak, the family jewels. >> >> So take care when using these products to ensure that they do what >> you >> >> want them to do and that you know what they're doing. >> >> >> >> One shop where I recently worked had a great slogan, "crypto is easy; >> >> key management is hard". >> >> It's not that the crypto was easy but that it's done already, >> >> implemented, coded, packaged. But the keys *must* be managed by you >> and >> >> your team, not the kind of thing which can be outsourced. >> >> Keys and certs cannot be installed and forgotten. And sadly, some of >> the >> >> expirations we are given are too short to be practical. (Various >> >> government issued IDs and licenses commonly last
Re: [EXTERNAL] Re: IBM key management products
Nice! That's the first I've heard of glass platters. Hope your drill bit survived the trauma :) On 4/15/2024 8:33 AM, Pommier, Rex wrote: Hi Tom, Regarding #2, at a former job I got to decommission an HDS box that was shared between the mainframe and Unix boxes. Unencrypted disk in it. Mgmt wanted the data destroyed so they asked me to take the individual drives home and drill through each of them. That was when I found out that this particular disk drive had glass platters. There was no getting data off them when the drill bit shattered every platter in every spindle. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Friday, April 12, 2024 1:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: IBM key management products We use SKLM/GKLM for data-at-rest encryption of DS8000/TS7000 devices, all internal disk storage, no external cartridge tapes. So what does that do for the customer, since (unless you're using an additional form of encryption on the mainframe) the data is still spit out of the devices unencrypted (not counting the additional feature that allows FICON-in-transit encryption). I have a few theories on this: #1 If someone gets into the datacenter and steals disks (or the entire DS/TS box), the encrypted contents should be useless. #2 When a DS/TS box is decommissioned, a customer could "potentially" skip any further destruction of the data in the box. Still, what I've seen in reality for decom is to run the IBM SDO (secure data overwrite to blot out the disks) and sometimes even shred the individual disks (I'd sure like to see that in action!) #3 If you steal a DS/TS box, make sure you steal the associated key server unit too. I'd appreciate any comments on these theories. On 4/12/2024 9:21 AM, Jousma, David wrote: To place a bit more focus on what Rick says….. You lose/destroy the key(s), you have lost your data. There is a lot of discussion about the scope/use of the keys. One key, or one per application, or one per dataset, etc. There is no right/wrong answer (well just one key for everything is probably not advisable). I personally am still having a hard time wrapping my head around the “real benefit” of dataset encryption. Everyone who has READ or more access to the dataset, must also be permitted to the Key. Those same people are still able to copy/print/steal that data.So who does that leave? Those that are not permitted to the dataset, and those who administer the storage.Those that don’t have access to the dataset aren’t going to get the data, encrypted or not. Those who administer the storage usually have access to move/manage the installations data.These are the people who dataset encryption is protecting against. That is a very small population to go to this effort on. Dave Jousma Vice President | Director, Technology Engineering From: IBM Mainframe Discussion List on behalf of Rick Troth <058ff5c2d0a7-dmarc-requ...@listserv.ua.edu> Date: Friday, April 12, 2024 at 10:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM key management products Not discounting Luke's excellent response: key management is hard. Look for utilities with reliable import/export capability. Be prepared to OWN your keys. I say this again as a CISSP, own your keys. This is your bread and butter, so to speak, Not discounting Luke's excellent response: key management is hard. Look for utilities with reliable import/export capability. Be prepared to OWN your keys. I say this again as a CISSP, own your keys. This is your bread and butter, so to speak, the family jewels. So take care when using these products to ensure that they do what you want them to do and that you know what they're doing. One shop where I recently worked had a great slogan, "crypto is easy; key management is hard". It's not that the crypto was easy but that it's done already, implemented, coded, packaged. But the keys *must* be managed by you and your team, not the kind of thing which can be outsourced. Keys and certs cannot be installed and forgotten. And sadly, some of the expirations we are given are too short to be practical. (Various government issued IDs and licenses commonly last FIVE years. Why do PKI certs last only two? ... or ONE?) But I'm getting off topic. Sorry. The point is, keys are fundamentally different than any other software or data that we have to manage. And it's a good idea to limit keys to individuals when you can. (Like the combination to the bank vault.) It's all about trust. This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is
REXX vs other languages WAS: Rexx numeric digits and scientific notation question
>Java's not perfect, but it is powerful and it is pretty much universally >available on z/OS. People don't understand the ingenuity behind REXX and don't understand the real problems it solves. From a language standpoint, REXX is just another language but it's real strength is it's environment integration. Instead of the caller maintaining libraries, the environment automatically integrates with REXX. For instance, REXX in the TSO environment, gives you access to TSO commands (address TSO) and z/OS programs (address linkmvs). Start ISPF and address ISPEXEC is available. ISPF option 2 gives you address ISREDIT. SYSCALLS ON gives you address syscalls. For product developers, REXX is simple to integrate environments as witnessed by the plethora of integrated environments on z/VM, z/OS and probably z/VSE (e.g. some addressable environments: automation, CICS, CMS, CP, TSO, UNIX, SYSCALLS and more) OOREXX is not REXX because it does not have the automatic environment integration and as you say, using JAVA instead of OOREXX would be preferable. REXX on the other hand is preferable over JAVA in many IBM environments. For instance, why would you use JAVA as your system automation environment language? The complication of using OOP REXX is rarely beneficial for most environments. Generally, you are not building complicated applications. For instance, system automation will be the most complex but managing events under objects would be complicated and unmanageable given the current automation environment design. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IMS - DFSRRC00 vs ODBA
To All, My IMS is somewhat limited and my terminology may be incorrect. Is there a performance difference between 1) executing DFSRRC00 and 2) executing an assembler program that uses ODBA calls ? 1) An assembler routine and a PSB name would be provided to DFSRRC00. I'm not sure what API is used in this case. 2) The assembler program (JOB STEP program) would be supplied a PSB name. The calls would be CIMS INIT, APSB, GN, DPSB, TERM and TALL using AERTDLI. Thanks in advance, Pierre. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: IBM key management products
Hi Tom, Regarding #2, at a former job I got to decommission an HDS box that was shared between the mainframe and Unix boxes. Unencrypted disk in it. Mgmt wanted the data destroyed so they asked me to take the individual drives home and drill through each of them. That was when I found out that this particular disk drive had glass platters. There was no getting data off them when the drill bit shattered every platter in every spindle. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Friday, April 12, 2024 1:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: IBM key management products We use SKLM/GKLM for data-at-rest encryption of DS8000/TS7000 devices, all internal disk storage, no external cartridge tapes. So what does that do for the customer, since (unless you're using an additional form of encryption on the mainframe) the data is still spit out of the devices unencrypted (not counting the additional feature that allows FICON-in-transit encryption). I have a few theories on this: #1 If someone gets into the datacenter and steals disks (or the entire DS/TS box), the encrypted contents should be useless. #2 When a DS/TS box is decommissioned, a customer could "potentially" skip any further destruction of the data in the box. Still, what I've seen in reality for decom is to run the IBM SDO (secure data overwrite to blot out the disks) and sometimes even shred the individual disks (I'd sure like to see that in action!) #3 If you steal a DS/TS box, make sure you steal the associated key server unit too. I'd appreciate any comments on these theories. On 4/12/2024 9:21 AM, Jousma, David wrote: > To place a bit more focus on what Rick says….. You lose/destroy the key(s), > you have lost your data. There is a lot of discussion about the scope/use > of the keys. One key, or one per application, or one per dataset, etc. > There is no right/wrong answer (well just one key for everything is probably > not advisable). > > I personally am still having a hard time wrapping my head around the “real > benefit” of dataset encryption. Everyone who has READ or more access to the > dataset, must also be permitted to the Key. Those same people are still > able to copy/print/steal that data.So who does that leave? Those that > are not permitted to the dataset, and those who administer the storage. > Those that don’t have access to the dataset aren’t going to get the data, > encrypted or not. Those who administer the storage usually have access to > move/manage the installations data.These are the people who dataset > encryption is protecting against. That is a very small population to go to > this effort on. > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > From: IBM Mainframe Discussion List on > behalf of Rick Troth <058ff5c2d0a7-dmarc-requ...@listserv.ua.edu> > Date: Friday, April 12, 2024 at 10:59 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: IBM key management products Not discounting Luke's > excellent response: key management is hard. Look for utilities with > reliable import/export capability. Be prepared to OWN your keys. I say > this again as a CISSP, own your keys. This is your bread and butter, > so to speak, > > > Not discounting Luke's excellent response: key management is hard. > > Look for utilities with reliable import/export capability. Be prepared > > to OWN your keys. > > I say this again as a CISSP, own your keys. This is your bread and > > butter, so to speak, the family jewels. > > So take care when using these products to ensure that they do what you > > want them to do and that you know what they're doing. > > > > One shop where I recently worked had a great slogan, "crypto is easy; > > key management is hard". > > It's not that the crypto was easy but that it's done already, > > implemented, coded, packaged. But the keys *must* be managed by you > and > > your team, not the kind of thing which can be outsourced. > > Keys and certs cannot be installed and forgotten. And sadly, some of > the > > expirations we are given are too short to be practical. (Various > > government issued IDs and licenses commonly last FIVE years. Why do > PKI > > certs last only two? ... or ONE?) > > But I'm getting off topic. Sorry. > > > > The point is, keys are fundamentally different than any other software > > or data that we have to manage. > > And it's a good idea to limit keys to individuals when you can. (Like > > the combination to the bank vault.) > > It's all about trust. > > > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate it in > any manner. If you are not the intended recipient, any disclosure, copying, >
Re: ./ ADD - which utility?
In a single word, yes. And as has been stated, setting up "DLM=" requires, at times, a scan of just the first several bytes of each logical record to find what unique value(s) one can use. Steve Thompson On 4/15/2024 3:30 AM, wrote: Just curious. Have anyone had problem with this delimiter problem in real life with anything other than JCL in the inline input data? (I mean the alternative of a separate file seems to be a better/normal alternative unless the inline data is at the end of the member/ds.) -- 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: Join the COBOL 6 modernization features survey
This survey is BS. On the first page, it touts interoperability between 31-bit and 64-bit. This is only a thing because of the ridiculous decision to use XPLINK linkage for 64-bit Cobol. The z/OS architects made that a non-issue with F4SA, F5SA, etc. LE designers made some bad decisions when they designed XPLINK applications incompatible with standard applications, then they compounded that when they designed XPLINK-64 to be incompatible with XPLINK and standard applications. As an example, there are three formats of the CAA. One for standard linkage, one for XPLINK and a third for XPLINK-64, and they are not compatible. -- Tom Marchant On Mon, 15 Apr 2024 05:07:50 -0500, Dan Zhang wrote: >Take our quick survey on IBM Enterprise COBOL for z/OS (COBOL) 6 modernization >features: https://ibmxm.qualtrics.com/jfe/form/SV_5zhKYEpP68L4Yjc! Share your >feedback on learning and using the latest advancements in COBOL 6. It only >takes 5 minutes to complete. Your insights will shape the future of our >products and services to better serve you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Join the COBOL 6 modernization features survey
If not correctly shown, the surve link is: https://ibmxm.qualtrics.com/jfe/form/SV_5zhKYEpP68L4Yjc -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Join the COBOL 6 modernization features survey
Take our quick survey on IBM Enterprise COBOL for z/OS (COBOL) 6 modernization features: https://ibmxm.qualtrics.com/jfe/form/SV_5zhKYEpP68L4Yjc! Share your feedback on learning and using the latest advancements in COBOL 6. It only takes 5 minutes to complete. Your insights will shape the future of our products and services to better serve you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ./ ADD - which utility?
Just curious. Have anyone had problem with this delimiter problem in real life with anything other than JCL in the inline input data? (I mean the alternative of a separate file seems to be a better/normal alternative unless the inline data is at the end of the member/ds.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
