Re: Request for help with removing sequence numbers from PDS members
Apologies, you wanted to do a PDS member. //EDIT EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * EDIT 'LEN.X.TEST.NVSAM.PDS(#ASM)' DATA LIST UNNUM LIST END SAVE /* // Note the LIST commands are optional. Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lennie Dymoke-Bradshaw Sent: 11 January 2021 19:48 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Request for help with removing sequence numbers from PDS members Here's how to do it using TSO EDIT. //EDIT EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * EDIT 'LEN.X.TEST.NVSAM.FB80' DATA LIST UNNUM LIST END SAVE /* // Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lennie Bradshaw Sent: 11 January 2021 12:26 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Request for help with removing sequence numbers from PDS members How about TSO EDIT (yes TSO, not ISPF) in batch. Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: 11 January 2021 10:21 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Request for help with removing sequence numbers from PDS members W dniu 11.01.2021 o 10:05, Sean Gleann pisze: > This has almost certainly cropped up before but try as I might, I > can't spot anything obvious in the archives. > > I have a need to strip sequence numbers from members in a PDS or PDSE. > The input PDS(E) has DCB characteristics of REFCM=FB,LRECL-80, and > contains an unknown number of members. Of those members, some will > have records with 'old data' in character positions 73-80 (that is - > sequence numbers, or whatever remains of them). > I want to be able to copy this input PDS(E) to a new one with the same > DCB info, but all records in all members must have spaces in positions 73-80. > > I thought that ICETOOL might be able to do this but as far as I can > see, ICETOOL needs to be told which member names to process. That > information is readily available while developing and testing a > solution, but not when the result is used in a more general scenario. > > Can anyone point me at some sort of solution that I might adapt, please? > Perhaps there is something on the CBT tape that might help... I don't know any tool, but I have some idea how to do it. Use REXX script. It's quite simple to get member list and do somethin in a loop until last member is processed. What to do? Again, I don't know any tool, however it could be feasible to use IEBGENER with non-empty SYSIN, ICEMAN, or TSO EDIT, or ISPF EDIT, or something else. Caution: things are simple when you just want to replace position 73-80 despite of its actual content, that means without checking it. HTH -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną działalnością bankową. Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be remin
Re: Request for help with removing sequence numbers from PDS members
Here's how to do it using TSO EDIT. //EDIT EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * EDIT 'LEN.X.TEST.NVSAM.FB80' DATA LIST UNNUM LIST END SAVE /* // Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lennie Bradshaw Sent: 11 January 2021 12:26 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Request for help with removing sequence numbers from PDS members How about TSO EDIT (yes TSO, not ISPF) in batch. Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: 11 January 2021 10:21 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Request for help with removing sequence numbers from PDS members W dniu 11.01.2021 o 10:05, Sean Gleann pisze: > This has almost certainly cropped up before but try as I might, I > can't spot anything obvious in the archives. > > I have a need to strip sequence numbers from members in a PDS or PDSE. > The input PDS(E) has DCB characteristics of REFCM=FB,LRECL-80, and > contains an unknown number of members. Of those members, some will > have records with 'old data' in character positions 73-80 (that is - > sequence numbers, or whatever remains of them). > I want to be able to copy this input PDS(E) to a new one with the same > DCB info, but all records in all members must have spaces in positions 73-80. > > I thought that ICETOOL might be able to do this but as far as I can > see, ICETOOL needs to be told which member names to process. That > information is readily available while developing and testing a > solution, but not when the result is used in a more general scenario. > > Can anyone point me at some sort of solution that I might adapt, please? > Perhaps there is something on the CBT tape that might help... I don't know any tool, but I have some idea how to do it. Use REXX script. It's quite simple to get member list and do somethin in a loop until last member is processed. What to do? Again, I don't know any tool, however it could be feasible to use IEBGENER with non-empty SYSIN, ICEMAN, or TSO EDIT, or ISPF EDIT, or something else. Caution: things are simple when you just want to replace position 73-80 despite of its actual content, that means without checking it. HTH -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną działalnością bankową. Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. We are the controller of your personal data, which you provided in connection with correspondence with us. We process your data for purposes resulting from the subject of correspondence, including those related to the banking services. More information on how we protect and process personal data can be found in the GDPR Packages (in English and Polish), which are on
Re: EBCDIC-ASCII converter and other tools
Maybe it does not have the capabilities you need but have a look at the V file viewer. https://www.fileviewer.com/ It is quite a favourite of mine. It handles XMI files beautifully too. Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: 29 December 2020 14:31 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: EBCDIC-ASCII converter and other tools W dniu 29.12.2020 o 15:20, Lennie Dymoke-Bradshaw pisze: > For the first requirement I was going to recommend SVC 103 but maybe that > doesn't run under windows. > > Where does the second utility have to run? Windows also. Yes, on z/OS side there would be not a problem - everything is available in the system. I was looking for iebgener.exe, idcams.exe, iceman.exe, iconv.exe, etc. - no success ;-) Fortunately I can use Minesweeper and Paint... -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną działalnością bankową. Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. We are the controller of your personal data, which you provided in connection with correspondence with us. We process your data for purposes resulting from the subject of correspondence, including those related to the banking services. More information on how we protect and process personal data can be found in the GDPR Packages (in English and Polish), which are on www.mbank.pl/rodo. -- 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: EBCDIC-ASCII converter and other tools
For the first requirement I was going to recommend SVC 103 but maybe that doesn't run under windows. Where does the second utility have to run? Lennie Dymoke-Bradshaw Consultant working on contract for BMC mainframe Services by RSM Partners ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: 29 December 2020 13:30 To: IBM-MAIN@LISTSERV.UA.EDU Subject: EBCDIC-ASCII converter and other tools 1. I'm looking for some simple tool for conversion EBCDIC to ASCII and vice versa. Unfortunately it has to run under Windows. Requirements: Run under Windows, preferrably in batch mode (command line interface) Custom-defined tables of conversion 2. I'm looking for a tool similar to IDCAMS SKIP/COUNT - the goal is to skip first nnn bytes of the file or skip file remainder. Any clue? -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat. Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną działalnością bankową. Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. We are the controller of your personal data, which you provided in connection with correspondence with us. We process your data for purposes resulting from the subject of correspondence, including those related to the banking services. More information on how we protect and process personal data can be found in the GDPR Packages (in English and Polish), which are on www.mbank.pl/rodo. -- 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: does anyone recall any details about MVS/XA?
Doh. 32bits + 12bits = 44bits Lennie Dymoke-Bradshaw Consultant working on contract for BMC mainframe Services by RSM Partners ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lennie Dymoke-Bradshaw Sent: 09 December 2020 20:31 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: does anyone recall any details about MVS/XA? Under MVS/ESA we had expanded storage. Expanded storage allowed each page to be addressed using a 32 bit address. As each page held 4096 (2**12) bytes the effective addressing was 32bits + 12bits = 48bits. Is this what you were thinking of? Lennie Dymoke-Bradshaw Consultant working on contract for BMC mainframe Services by RSM Partners ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: 09 December 2020 18:19 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: does anyone recall any details about MVS/XA? Somewhere in the past, there was an article printed where somebody was gazing into a crystal ball. I have (maybe had) it on paper but can't find it right now. They were conjecturing on IBM's next OS and they called it MVS/ESB. They were pretty convinced that IBM's next move from 31 bit was going to be to 48 bit. Unfortunately I can't find the paper right now. Ranked right up there (without the massive publicity) of Steward Alsop's prediction of the last mainframe being unplugged in 1995. Does anybody else recall ever hearing anything like this? Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Wawiorko Sent: Wednesday, December 9, 2020 8:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: does anyone recall any details about MVS/XA? I remember an IBM SE presenting XA to us saying 31 bit addressing and 2GB memory would serve every need. Now how long since 64 bit? How long before everything fully supports 64 bit though? 128 bit next? Mike Wawiorko The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- 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: does anyone recall any details about MVS/XA?
Under MVS/ESA we had expanded storage. Expanded storage allowed each page to be addressed using a 32 bit address. As each page held 4096 (2**12) bytes the effective addressing was 32bits + 12bits = 48bits. Is this what you were thinking of? Lennie Dymoke-Bradshaw Consultant working on contract for BMC mainframe Services by RSM Partners ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: 09 December 2020 18:19 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: does anyone recall any details about MVS/XA? Somewhere in the past, there was an article printed where somebody was gazing into a crystal ball. I have (maybe had) it on paper but can't find it right now. They were conjecturing on IBM's next OS and they called it MVS/ESB. They were pretty convinced that IBM's next move from 31 bit was going to be to 48 bit. Unfortunately I can't find the paper right now. Ranked right up there (without the massive publicity) of Steward Alsop's prediction of the last mainframe being unplugged in 1995. Does anybody else recall ever hearing anything like this? Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Wawiorko Sent: Wednesday, December 9, 2020 8:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: does anyone recall any details about MVS/XA? I remember an IBM SE presenting XA to us saying 31 bit addressing and 2GB memory would serve every need. Now how long since 64 bit? How long before everything fully supports 64 bit though? 128 bit next? Mike Wawiorko The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- 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: does anyone recall any details about MVS/XA? [EXTERNAL]
I ran these CBIPO installs in the early eighties. I am pretty sure it used SMP/E to perform the generation using the GENERATE command. I had an MVS/SP driving system of course. The first MVS/XA system I built was XA 2.1.2 I think. Lennie Dymoke-Bradshaw Consultant working on contract for BMC mainframe Services by RSM Partners ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: 08 December 2020 22:30 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: does anyone recall any details about MVS/XA? [EXTERNAL] Paul, Thank you for that memory jog. Yep, it was MVS/Express. It was a stand-alone restore tape of MVS/XA (ours was 2.1.7) that once restored was an IPLable XA system - and reasonably current on maintenance. Fun time was going to a class for MVS newbies and using the MVS/express tape. 8 of us trying to restore stand-alone tapes on top of a VM 4381. Watching the tape turn ever-so-slowly trying to load MVS. So when we initially brought up XA 2.1.7, it was the express tape which was the starter system soon followed by a CBIPO tape to load down a more current set of software and yes, there was a SYSGEN in the middle of the CBIPO install process. Those are old, rusty memories. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Feller, Paul Sent: Tuesday, December 8, 2020 4:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: does anyone recall any details about MVS/XA? [EXTERNAL] For those new to MVS there was the MVS/XA Express option. You have to qualify to get it. A shop I worked at a long time ago was a VSE shop that was going to convert to MVS and that is how we started off. I believe the MVS/XA Express was a complete IPL system that IBM built based on your environment. I think it was basically a restore and IPL type situation. After that I don't recall what had to be done. It was a long (long) time ago so the memory is a little fuzzy. Thanks.. Paul Feller GTS Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Jacobs Sent: Tuesday, December 8, 2020 3:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: does anyone recall any details about MVS/XA? [EXTERNAL] The *fun* memories of a POR before every time we tested MVS/XA and then another one when we went back to MVS/SP for production just returned. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://urldefense.proofpoint.com/v2/url?u=https-3A__api.protonmail.ch_pks_lookup-3Fop-3Dget-26search-3Dmarkjacobs-40protonmail.com=DwIFaQ=9g4MJkl2VjLjS6R4ei18BA=eUhu3PeeWy6RTndlJVKembFjFsvwCa8eeU_gm45NyOc=KK1yXXNOBVuutibinfGrz7q-E8DxWAgMfozPwM_fdas=Aeq0PrNdOcRqdsiFkHkGJt4xsGO8Guev3vSwvmvSc-s= ‐‐‐ Original Message ‐‐‐ On Tuesday, December 8th, 2020 at 4:18 PM, Farley, Peter x23353 <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > ISTR there was also a special version of VM/XA made available "early" so that > customers could run both 24-bit MVS/SP and 31-bit MVS/XA on the same physical > machine. > > Peter > > -Original Message- > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf > Of Brian France > > Sent: Tuesday, December 8, 2020 4:11 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: does anyone recall any details about MVS/XA? > > I kinda remember MVS/XA and later ESA being CBIPO and CBPDO for maint. > > SYSGEN I think was still needed for XA and maybe ESA. > > I'm not sure what you meant by Optional Source Materials. If by that you > meant optional source code to install, I think they went the microsloth bloat > ware option later... > > On 12/8/2020 4:00 PM, Joe Monk wrote: > > > i thought MVS/XA was CBIPO? > > > > Joe > > > > On Tue, Dec 8, 2020 at 2:04 PM Mark S Waterbury < > > > > 01c3f560aac1-dmarc-requ...@listserv.ua.edu> wrote: > > > > > Hi, all, > > > > > > Does anyone recall how MVS/XA was first distributed and installed? e.g. > > > > > > was there some kind of a "starter system"? If so, what was it? MVS > > > > > > 3.8J, or MVS/SE or MVS/SP or what? > > > > > > I seem to recall that someone told me that there was no longer any > > > > > > "SYSGEN" process used to install MVS/XA? So, how was this task > > > > > > accomplished? > > > > > > Also, does anyone recall whether IBM made available any "optional > > > > > > source materials" for MVS/XA, either machine readable, on magnetic > > > > > > tape, or was that only available on microfiche, if it was available at > > > all? > &
IBM z/OS Authorized Code Scanner
Has anyone any feedback on the IBM Authorised Code Scanner? https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=AN=CA pname=gpateam=897=ENUS220-225 Lennie Dymoke-Bradshaw Consultant working on contract for BMC mainframe Services by RSM Partners 'Dance like no one is watching. Encrypt like everyone is.' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RBOPSW question
I usually look in the system trace for that information. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: 03 December 2020 17:14 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RBOPSW question I know for sure I’m going to say something stupid but the PRB for my program is when the program started I’ll look at it up thanks > On Dec 3, 2020, at 12:06 PM, Seymour J Metz wrote: > > From force of habit, I normally look at the RB chain. The PRB for your > program contains the PSW and the SVRB for for the SVC contains the registers. > If you can find a copy of Jerry Ng's excellent diagnostic presentation at > Share, I suggest that you read it. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of Joseph Reichman [reichman...@gmail.com] > Sent: Thursday, December 3, 2020 11:56 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: RBOPSW question > > Hi > > This question is related to recovery routines > > In the case there is SDWARBAD and SDWANAME is not there > > So for example my program abended in a SVC > > So RBOPSW is somewhere in that SVC > > The rbregs should be my program > > But my question is would I have an address or could I determine from > what address in my program I called the SVC > > Thanks > > -- > 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: Finding the STEIN of another address space
Whew! That makes more sense. After all, I had coded using the ASSBISQN and it worked. Thanks for the further clarification Peter. Lennie Dymoke-Bradshaw -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: 25 November 2020 00:06 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Finding the STEIN of another address space To (my)self: Open mouth, insert foot. Or its analog in typing. I was thinking of the ASTE sequence number, not the ASTE instance number. The ASTE instance number is indeed set when an address space starts, changed only when an ASID is reused. And matches ASSBISQN (which then, correctly, unlike what I said, is the answer to the original poster's query). Thanks to Erik J for noticing. 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Finding the STEIN of another address space
Peter, Thanks for extra information. However, your somewhat cryptic message doesn't really clarify which field I should use. I think the question I need to ask is, Under what circumstances is the ASSBISQN field different from the ASTE1IN field? The code in question is for a diagnostic utility I wrote about 20 years back. It only ever examines fields in the secondary address space. It has an error recovery routine which has proved robust over the years. It has been reporting the 0D3-0013 abends for a while and recovering gracefully. Lennie Dymoke-Bradshaw -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: 19 November 2020 14:01 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Finding the STEIN of another address space ASSBISQN is not always the same as the ASTE Instance Number (ASTE rather than STE). Maybe the back-handed hint is that this is not something you should be doing? I wouldn't go that far. Architecturally, the ASTE instance number is in the ASTE. 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Finding the STEIN of another address space
Thank you Binyamin. After posting I had found the ASTE1IN which looks to be the same value as ASSBISQN, but is not a programming interface. Looks like your answer is better. Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Binyamin Dissen Sent: 18 November 2020 19:06 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Finding the STEIN of another address space ASSBISQN On Wed, 18 Nov 2020 18:04:26 - Lennie Dymoke-Bradshaw <032fff1be9b4-dmarc-requ...@listserv.ua.edu> wrote: :>I have some cross-memory code written many years ago. :>It uses the ASVT to get the ASID of various address spaces and then uses the :>ASID in a SSAR to establish a cross-memory link (having first issued an :>AXSET AX=ONE). :>All works fine until faced with an address space with a reusable ASID. Then :>the SSAR gets a program check X'0013' and abends with a 0D3-0013 abend. This :>is all documented in the extended addressability manual here. :>https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2. ie :>aa500/ieaa500101.htm :>So in order to correct my code I need to replace the SSAR instruction with :>an SSAIR instruction, whenever the target address space is reusable. This :>requires that I locate the STEIN (Second Table Entry Instance Number) of the :>target address space and specify it as a SASTEIN in the high order 4 bytes :>of the 64-byte register specified on the SSAIR instruction. :>How can I find the STEIN of the target address space? -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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
Finding the STEIN of another address space
Greetings, I have some cross-memory code written many years ago. It uses the ASVT to get the ASID of various address spaces and then uses the ASID in a SSAR to establish a cross-memory link (having first issued an AXSET AX=ONE). All works fine until faced with an address space with a reusable ASID. Then the SSAR gets a program check X'0013' and abends with a 0D3-0013 abend. This is all documented in the extended addressability manual here. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ie aa500/ieaa500101.htm So in order to correct my code I need to replace the SSAR instruction with an SSAIR instruction, whenever the target address space is reusable. This requires that I locate the STEIN (Second Table Entry Instance Number) of the target address space and specify it as a SASTEIN in the high order 4 bytes of the 64-byte register specified on the SSAIR instruction. How can I find the STEIN of the target address space? Lennie Dymoke-Bradshaw -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Can a non-admin restrict others from viewing one of their own MVS data sets?
Frank, By default a RACF userid can modify RACF dataset profiles which have a high-level qualifier of that userid. Also by default the RACF userid can create new data set profiles with the userid as the high level qualifier. There are numerous way to alter this behaviour including use of GLOBAL profiles, RACF exits and products such as zSecure command verifier. So it really depends what else is present on your system. But by default you can create a generic profile to cover "your" data sets and then adjust the access list as you see fit using the PERMIT command. Lennie Dymoke-Bradshaw Consultant working on contract for BMC mainframe Services by RSM Partners 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: 06 November 2020 21:43 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Can a non-admin restrict others from viewing one of their own MVS data sets? In the Unix world one can use chmod (change mode) on their own files to make it so non-superusers cannot view a particular file. Is there anything similar for MVS data sets? -- 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: SMF to capture user login history
Yes. But to do this, you will need to switch off "list of groups" processing. This option was introduced in the 1980s and most shops decided to turn it on. The concept of the "connect group" as the group specified at logon time (or if you like RACINIT time) has largely gone. What you ask could also be performed in various RACF exits of course. Lennie Dymoke-Bradshaw Consultant working on contract for BMC mainframe Services by RSM Partners 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: 26 October 2020 16:30 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history Curious question. Is it possible to have a single user ID with different privileges depending on what group you specify when logging in (to TSO, for example)? From: IBM Mainframe Discussion List on behalf of Seymour J Metz Sent: Sunday, October 25, 2020 8:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history > two sets of IDs Multiple ids can be very usefull. If you have a lot of privileges and write code that is supposed to work without those privileges, it's useful to have a bare bones userid. If you have work that requires privileges that you consider too dangerous for normal work, it's nice to have a more privileged userid and proxy permission. BTDT, GTTS. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Horein [steve.hor...@gmail.com] Sent: Sunday, October 25, 2020 9:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF to capture user login history On Sun, Oct 25, 2020 at 1:11 AM kekronbekron < 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > I hope no one encourages this kind of snooping on the list. > Stinks of an attempt to police working hours. > > - KB > Meh. The first shop I worked in implemented something like that to track the use of privileged IDs that had elevated permissions to update production resources. At the time, the scope had been TSO, so I wrote some automation that would send an email to the "security operations center" if RACF IDs matching specific patterns generated an IEF125I, IEF126I, or an IEF45* message. The time frames from logon to logoff/abend needed to be justified with a change request or incident, otherwise it would be considered suspicious activity. Yes, it meant having to maintain two sets of IDs - a BAU ID for day to day work, and the privileged ID for changes or recovery support, but it satisfied someone's requirement. -- 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: IBM KEYXFER rexx
I have a copy of this. The last update on mine 10/08/2009, which I think is 8th October. I confess I never used it. From memory, I think it requires the source and target systems to use the same master key. I have another facility for moving DES and 3DES keys between systems using a transport key. Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Dave Jousma Sent: 19 October 2020 14:31 To: IBM-MAIN@LISTSERV.UA.EDU Subject: IBM KEYXFER rexx All, Do any of you have a copy of IBM AS-IS utility “KEYXFER”? The copy I have is from 2006, was updated in 2018. IBM has moved all their stuff into GITHUB now, and the README is there, but not the REXX code. The code also used to live at ftp://ftp.software.ibm.com/s390/zos/tools/keyxfer/. I'm able to get to the site, but cant download anything. FYI, this utility is for exporting/importing PKDS keys out of ICSF. I do have a ticket open with IBM on this, but they seem to be dragging their feet trying to put it back out on GITHUB. If anyone has a copy, I’d appreciate someone sending it to me? For the curious, here is the readme keyxfer A Key Transfer Tool Introduction The key transfer tool (KEYXFER) is a REXX exec that runs on MVS. KEYXFER facilitates the transfer of PKDS or CKDS key tokens between systems that use the Integrated Cryptographic Services Facility (ICSF). The KEYXFER tool assumes the following: 1. ICSF is running on the systems involved in the key transfer 2. ICSF has an active Key Data Set (CKDS/PKDS) For a PKA key token transfer the tool retrieves the token from the active PKDS and writes it to a data set (file). For a symmetric key token transfer the tool retrieves the token from the active CKDS and writes it to a data set (file). The data set can then be transmitted to any number of systems. On each system the tool can be used to read the key token from the transmitted file and store it into the active PKDS or CKDS. The tokens are referenced by label. The format of the command is illustrated below: Syntax KEYXFER OPER, LABEL, DSN, OPTION OPER = READ_PKDS reads from the transmitted data set WRITE_PKDS writes to the transmitted data set READ_CKDS reads from the transmitted data set WRITE_CKDS writes to the transmitted data set LABEL = label of PKDS or CKDS record to be retreived/stored DSN = name of data set holding the token OPTION= OVERWRITE a label in the PKDS or CKDS. If OVERWRITE is specified in the option field then an existing label will be overwritten with the token from the transmitted data set. DATA SET: A PS or PDS data set can be used. An LRECL=80 is recommended, but not required The information stored in the KEYXFER data set consists of the following: Date KDS label Length of token Token Notes External key tokens can be received on any ICSF system. If the key token is an internal key token (see ICSF Application Programmers Guide) then it is encrypted under the ICSF master key of the system. Transferring the key token requires that the receiving systems use the same ICSF master key. If ICSF services are RACF protected (CSFSERV) then access will be required by the user for the CSNDKRC, CSNDKRR, and CSNDKRW services for PKDS transfers or CSNBKRC, CSNBKRR and CSNBKRW for CKDS transfers. Samples • Write the key token stored in the active PKDS under the label PKDS.KEY.LABEL to the data set TEMP.MEM KEYXFER WRITE_PKDS, PKDS.KEY.LABEL, TEMP.MEM • Read the key token contained in the data set TEMP.MEM and write the token to the active PKDS under the label PKDS.KEY.LABEL. (If the label already exists in the PKDS the operation will fail.) KEYXFER READ_PKDS, PKDS.KEY.LABEL, TEMP.MEM • Read the key token contained in the data set TEMP.MEM and write the token to the active PKDS under the label PKDS.KEY.LABEL (If the label already exists in the PKDS the token for that label will be overwritten.) KEYXFER READ_PKDS, PKDS.KEY.LABEL, TEMP.MEM, OVERWRITE • Read the key token contained in the data set TEMP.MEM and write the token to the active PKDS. Since no PLABEL was specified the label Contained in the file is used as the label for the token on the new system. KEYXFER READ_PKDS, , TEMP.MEM • Write the key token stored in the active CKDS under the label CKDS.KEY.LABEL to the data set TEMP.MEM KEYXFER WRITE_CKDS, CPKDS.KEY.LABEL, TEMP.MEM -- 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: Checksum/Md5 file
Please note too that the CSNBOWH implementation requires ICSF to be active, but does not require any Crypto Express hardware, nor is it dependent on the CPACF. It is a software solution that executes within ICSF. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jousma, David Sent: 16 October 2020 20:07 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Checksum/Md5 file Yes. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1 .csfb400/csfb4za229.htm _ Dave Jousma AVP | Director, Technology Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sasso, Len Sent: Friday, October 16, 2020 2:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Checksum/Md5 file **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Anyone know if a Checksum/Md5 file can be created on a IBM Mainframe? If so, how? Thank You and Please Be Safe! Len Sasso Systems Administrator Senior CSRA, A General Dynamics Information Technology Company 327 Columbia TPKE Rensselaer, NY 12144 Office Hours: M-F 7 AM - 3:45 PM Out-Of-Office: Tue., Oct. 20th - 1:30 PM - Wed., Oct 21st @ 7 AM Phone: (518) 257-4209 Cell: (518) 894-0879 Fax: (518) 257-4300 len.sa...@gdit.com URL: www.gdit.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** 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 prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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: ISPF dsn sort
Many thanks to everyone who has contributed to this thread. My tests corroborate the fact that selecting the "Display Total Tracks" option affects the behaviour. Also the help for the panel (in particular for that option) explains the behaviour I am seeing. Ho hum. I live and learn. 46 years on mainframe and still going.. So as the OP I say, "Great job folks, thanks for the help". Lennie Lennie Dymoke-Bradshaw Consultant working on contract for BMC mainframe Services by RSM Partners ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: 15 October 2020 15:01 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: ISPF dsn sort That's not what is happening. A different poster nailed it earlier. If the "Display Total Tracks" is selected on the dataset list utility screen, the first time you hit PF10/11 to go right or left, ISPF needs to read the entire list in order to populate the "total tracks" line. Thus you get the progress bar. If you don't have that selected, ISPF only works with the screen's worth of data so no progress bar until you do a sort. Once the sort is requested, ISPF needs to read the entire list to be able to do the sort correctly. Once ISPF has all the information it needs, you can resort the data any way you want and it won't need to reread it. At least that's what I've seen with my testing of it. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bob Bridges Sent: Thursday, October 15, 2020 6:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: ISPF dsn sort I've never noticed the behavior, but now that the OP has pointed it out, the reading-the-list-again explanation doesn't satisfy me. If there's a delay and a progress bar when reading the list to do the sort, why is there no similar delay when scrolling right to see the data which (according to this explanation) has not yet been collected? I'm not buying it. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Our world is not divided by race, color, gender, or religion. Our world is divided into wise people and fools. And fools divide themselves by race, color, gender, or religion. -Mohamad Safa */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: Tuesday, October 13, 2020 13:12 This is one of those IIRC posts. I think this behavior goes back decades. The reason is as Kolusu states. Moreover--IIRC--the very appearance of the 'progress bar' was in response to what could be a long delay. Delay to the point that the user might suspect that the process was hung outright. I remember when the bar was introduced with that very explanation. Everything in those distant days was slower than today. As for the difference in processing, I could imagine an RFE asking for a 'quick sort' based only on the data previously collected and displayed. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sri h Kolusu Sent: Tuesday, October 13, 2020 9:47 AM 3.4 listing shows the list of datasets sorted on the Dataset name by default. Now when you issue SORT DSORG command , ISPF needs to read in the list once again and make DSORG as the primary key and then present you the list sorted on that order. You will -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lennie Dymoke-Bradshaw Sent: Tuesday, October 13, 2020 11:18 This is something that has puzzled me for years. I can use ISPF 3.4 to display a set of data sets. If I scroll right then I am shown the space usage figures. Scroll right again and I am shown the DSORG, RECFM, Lrecl and Blksize. If I now enter SORT DSORG I am presented with a progress bar and I am informed that information is being collected to perform the sort. Given that the DSORG was already displayed, why does ISPF go and collect the same information again? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-M
ISPF dsn sort
This is something that has puzzled me for years. Can anyone explain the following. I can use ISPF 3.4 to display a set of data sets. If I scroll right then I am shown the space usage figures. Scroll right again and I am shown the DSORG, RECFM, Lrecl and Blksize. If I now enter SORT DSORG I am presented with a progress bar and I am informed that information is being collected to perform the sort. Given that the DSORG was already displayed, why does ISPF go and collect the same information again? Lennie Dymoke-Bradshaw ‘Dance like no one is watching. Encrypt like everyone is.’ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SVC 99 unallocating a concatenated dataset
Long ago (actually 1989 I think) I wrote a CONCAT TSO command which can be used to add or remove data sets from a concatenated list. It can also perform a FREE. This loops round each entry in the concatenated set and frees each data set. It still works a treat. I still have the code should anyone want it. Lennie Dymoke-Bradshaw Consultant working on contract for BMC mainframe Services by RSM Partners ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: 01 October 2020 18:25 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SVC 99 unallocating a concatenated dataset I’m running the program under test After I do decocatenate verb 04 With the ddname text 01 I get a rc 0 from SVC 99 I then go to ISPF Do a ISRDDN And I have a number of files actually 100 Each with a ddname SYS7,SYS8 etc. This indicates to me that although they are decocatenated they are still allocated Thanks > On Oct 1, 2020, at 12:35 PM, Binyamin Dissen > wrote: > > On Thu, 1 Oct 2020 07:58:56 -0400 Joseph Reichman > > wrote: > > :>I allocate a number of datasets the last text unit being DALCLOSE > :>(unallocated on close) In my second step I concatenate the datasets. At > :>EOF I close them after wards Ideconcatenate them My question is > :>shouldn't the individual datasets be unallocated as well > > What happens when you, thru JCL, concat several datasets with FREE=CLOSE? > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. > > -- > 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: DFDSS support for ZFS files query
If you fork pax then I think this would mean DSS would be invoking access methods to perform the backup. DSS has used lower level processes to perform backups up to now. I mention this because it has a big impact on the way that data is processed when the data is encrypted. Currently DSS backs up encrypted data without invoking the access methods, thus never needing access to encryption keys. By working at block level, data sets can be moved, backed up, migrated, recalled without ever accessing the true data. Lennie Dymoke-Bradshaw Consultant working on contract for BMC mainframe Services by RSM Partners ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: 01 October 2020 14:28 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFDSS support for ZFS files query On Wed, 30 Sep 2020 09:44:52 -0500, Ernesto Figueroa wrote: >You are correct. For now, you must specify all the path names, but we >understand this is a capability that ought to be provided in DFSMSdss. As >others have mentioned, you may be able to use other tools to craft a list of >path names and use that to generate DFSMSdss SYSIN statements. There is an >existing RFE to provide the capability to dump an entire directory including >all the files and sub-directories, if you feel this is an important feature to >be included in the product please cast your vote here: >http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=14 >0801 > Is it proposed to support patterns in the fashion of "pax"? The best way to do this may be to fork pax itself and keep the dump in pax format. Don't reinvent the wheel. -- gil -- 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 EMAIL: How get a user to use his own catalog rather than master?
Dave, Sorry, but I actually disagree with Master catalog access being an integrity issue. I would classify it as a security issue rather than an integrity issue. The normal controls on the operating system are working correctly and are not being bypassed, so I don't see that as an integrity issue. Lennie Dymoke-Bradshaw Consultant working on contract for BMC mainframe Services by RSM Partners ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gibney, David Allen Sent: 17 September 2020 02:23 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: EXTERNAL EMAIL: How get a user to use his own catalog rather than master? A normal user with authority to update the master catalog is a potential system integrity concern. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of CM Poncelet > Sent: Wednesday, September 16, 2020 6:00 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: EXTERNAL EMAIL: How get a user to use his own catalog > rather than master? > > In short-speak, yes. A user can use his own catalog rather than the > master catalog, howbeit via the MCAT's then containing an entry > pointing at the user's logon ID as an hlq (or similar) in the user's UCAT. > Anything can be done with a bit of frigging around. But the question > is, why and is it worth it? > > BTW Yes, I agree that all system changes should always be done in > batch and not 'interactively'. > > Just my ha'penny. > > > > On 16/09/2020 04:37, Charles Mills wrote: > > Yeah, I am slowly learning that. :-/ > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM- > m...@listserv.ua.edu] On Behalf Of David Spiegel > > Sent: Tuesday, September 15, 2020 4:40 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: EXTERNAL EMAIL: How get a user to use his own catalog > > rather > than master? > > > > Hi Charles, > > I have a self-imposed rule: Always do it in Batch (rather than via > > TSO and/or ISPF). > > This has at least 2 benefits: > > 1) It's repeatable and a history is automatically kept (assuming > > that you save every Batch Job). > > 2) You get to learn the Utilities faster. > > > > > > -- 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: SHAREOPTIONS from a program?
Catalog search interface, IGGCSI00. Look at field ATTR2. Lennie Dymoke-Bradshaw ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Harminc Sent: 28 July 2020 00:39 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] SHAREOPTIONS from a program? Simple question - I think I should know the answer, but I don't. How can an application program using a VSAM dataset discover the SHAREOPTIONS that were specified when the cluster was DEFINEd/ALTERed? Can this be done easily before OPEN? After OPEN? There are two flag bits in ACBINFL2, but that would seem not enough to cover all the possibilities. Thanks. Tony H. -- 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: Started task stopping immediately. No error messages.
SDSF has supported JES3 since z/OS 1.10. Lennie Dymoke-Bradshaw 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: 27 July 2020 16:31 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Started task stopping immediately. No error messages. It looks like you're using JES3. I thought thad SDSF didn't support it. CC 0 would have been a useful datum in the original question. It looks like the FTP server doesn't issue an informational message when a copy is already running. RFE? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Skippy the Ancient [kkin...@email.com] Sent: Monday, July 27, 2020 8:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Started task stopping immediately. No error messages. Responding to all posters, not just Mr Metz. 1. I already tried calling the proc from JCL. It ran, stopped immediately and returned no error messages. 2. I started the proc with the MSGCLASS and did receive output. It was identical to the JCL call; immediate stop and no error messages. I will post this below. 3. The started task is a second FTP server supporting FTPS. To simplify, I copied the FTPD proc and renamed it FTPSD. In theory, it is running exactly as the original FTPD task with a different port. (990) 4. The PROFILE update reads like this - AUTOLOG FTPSD JOBNAME FTPSD ; FTPS SERVER ENDAUTOLOG PORT 989 TCP OMVS; FTPS SERVER 990 TCP FTPSD NOAUTOLOG ; FTPS SERVER Here is the output of running the started task - (system specifics changed for security reasons) 08:26:31 IAT6853 THE CURRENT DATE IS MONDAY,27 JUL 2020 08:26:31 IAT4401 LOCATE FOR STEP=FTPD DD=STEPLIB DSN=SYSX.TCPIP.SEZATCP 08:26:31 IAT4402 UNIT=3390,VOL(S)=XYZZY 08:26:31 IAT4401 LOCATE FOR STEP=FTPD DD=STEPLIB DSN=SYSX.TCPIP.XXLOAD 08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY 08:26:31 IAT4401 LOCATE FOR STEP=FTPD DD=SYSFTPD DSN=SYSX.TCPIP.PARMLIB 08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY 08:26:31 IAT4401 LOCATE FOR STEP=FTPD DD=SYSTCPD DSN=SYSX.TCPIP.PARMLIB 08:26:31 IAT4402 STORCLAS=XYZZY, MGMTCLAS=XYZZY 08:26:31 IEF695I START FTPSDWITH JOBNAME FTPSDIS ASSIGNED TO USER FTPSD , GROUP 08:26:31 ACF9CCCD USERID FTPSDIS ASSIGNED TO THIS JOB - FTPSD 08:26:31 IEF403I FTPSD - STARTED - TIME=08.26.31 08:26:31 IEF404I FTPSD - ENDED - TIME=08.26.31 //FTPSDJOB MSGCLASS=T, * // MSGLEVEL=1 //STARTING EXEC FTPSD 1 //FTPSDJOB MSGCLASS=T, * // MSGLEVEL=1 2 //STARTING EXEC FTPSD 3 XXFTPSD PROC MODULE='FTPD',PARMS='TRACE PORT 990' 4 XXFTPD EXEC PGM=,REGION=0M,TIME=NOLIMIT, XX PARM='POSIX(ON) ALL31(ON)/' IEFC653I SUBSTITUTION JCL - PGM=FTPD,REGION=0M,TIME=NOLIMIT,PARM='POSIX(ON) ALL31(ON)/TRACE PORT 990' 5 XXSTEPLIB DD DSN=SYSX.TCPIP.SEZATCP,DISP=SHR 6 XX DD DSN=SYSX.TCPIP.XXLOAD,DISP=SHR 7 XXCEEDUMP DD SYSOUT=* 8 XXSYSOUT DD SYSOUT=* 9 XXSYSFTPD DD DISP=SHR,DSN=SYSX.TCPIP.PARMLIB(FTPSSL) 10 XXSYSTCPD DD DISP=SHR,DSN=SYSX.TCPIP.PARMLIB(TCPDATA) STMT NO. MESSAGE 2 IEFC001I PROCEDURE FTPSD WAS EXPANDED USING SYSTEM LIBRARY SYSX.PROCLIB IEF695I START FTPSDWITH JOBNAME FTPSDIS ASSIGNED TO USER FTPSD , GROUP USSGRPX IEF043I Actions taken by SMFLIMxx parmlib policy for FTPSDFTPD Step MEMLIMIT set to ONOUDONT by policy - SMFLIM00 0002 IEF142I FTPSD FTPSD - STEP WAS EXECUTED - COND CODE IEF373I STEP/FTPD/START 2020209.0826 IEF032I STEP/FTPD/STOP 2020209.0826 CPU: 0 HR 00 MIN 00.08 SECSRB: 0 HR 00 MIN 00.00 SEC VIRT:80K SYS: 216K EXT: 2220K SYS: 9108K ATB- REAL:12K SLOTS: 0K VIRT- ALLOC: 7M SHRD: 0M IEF375I JOB/FTPSD /START 2020209.0826 IEF033I JOB/FTPSD /STOP 2020209.0826 CPU: 0 HR 00 MIN 00.08 SECSRB: 0 HR 00 MIN 00.00 SEC -- 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: ICSF -- initializing a PKDS
It only very recently that CPACF does any processing for asymmetric keys. Remember that if you initialise a CKDS using CPACF, you cannot subsequently convert the CKDS to a protected key CKDS. You could always look at the old Redbook for Crypto n the z9 SG24-7123-00. . Lennie Dymoke-Bradshaw Consultant working on contract for ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown Sent: 16 July 2020 18:45 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] ICSF -- initializing a PKDS This is for a very old z/OS 1.12 system running on a z9BC. CPACF is enabled in the machine. There are no cryptographic coprocessors installed. I can initialize the CKDS using the panel. But when I try to initialize the PKDS, the panel displays "OPTION NOT ACTIVE". PF1 displays 'THE SELECTED PANEL OPTION IS NOT AVAILABLE WITH YOUR CURRENT SYSTEM CONFIGURATION" Is this normal? Can I not use the PKDS on a system with only CPACF? Or do I need to enable some other option somewhere? Thanks. -- People in sleeping bags are the soft tacos of the bear world. 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
Re: AT-TLS ? Very Basic Questions
I have TLS 1.2 working in my TN3270 server without AT-TLS. This is on z/OS 2.3 Lennie Dymoke-Bradshaw Consultant working on contract for BMC Mainframe Services by RSM Partners ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jackson, Rob Sent: 30 June 2020 18:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] AT-TLS ? Very Basic Questions A note, without addressing your entire post (certainly not my area of expertise): AT-TLS is required for TN3270 (and others) if you want to use TLS 1.2 and higher. In your TELNETPARMS for the port, instead of using SECUREPORT, you use TTLSPORT, referencing a port specified in a TTLSRule in AT-TLS. First Horizon Bank Mainframe Technical Support -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Tuesday, June 30, 2020 12:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: AT-TLS ? Very Basic Questions [External Email. Exercise caution when clicking links or opening attachments.] I've tried to skim some of the AT-TLS doc, and even attended an IBM webinar last week, but I'm still missing what I imagine are important background points. Maybe someone here can explain things, but don't worry too much about it. Client and server programs like SSH/SSHD call programs such as OpenSSL to handle the encryption handshake and processing. So when you set those up, there is no AT-TLS needed for encryption. Same with the TN3270 server and client, as long as you set that up with keys and parameters on the host side, and settings on the client side. I'm thinking because of the name "Application Transparent" that AT-TLS was made for programs that DON'T have their own logic to call OpenSSL (or whatever) to do their own encryption. Let's use clear-text FTP as an example. So somehow, AT-TLS hooks into the processing and provides an encrypted "tunnel", kind of like VPN does, but only for that one application. Does that sound correct? If so, then the encryption is "transparent" to the FTP server code and FTP does not need to be changed, which I think is the whole idea here. Yet we now have an encrypted session. Does that sound correct? Then if so, what happens on the FTP client side? I certainly can't use the Windows FTP command, for example, because it's not setup for any kind of encryption. That's kind of my big question here. On 6/30/2020 1:44 AM, Lionel B Dyck wrote: > Sweet - thank you > > > Lionel B. Dyck < > Website: https://www.lbdsoftware.com > > "Worry more about your character than your reputation. Character is > what you are, reputation merely what others think you are." - John > Wooden > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of kekronbekron > Sent: Tuesday, June 30, 2020 2:34 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: AT-TLS ? > > Hi LBD!, > > Check these out- > > > http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS5416 > http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS5415 > http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS5414 > > - KB > > ‐‐‐ Original Message ‐‐‐ > On Monday, June 29, 2020 3:56 AM, Lionel B Dyck wrote: > >> Anyone have any pointers for configuring AT-TLS on z/OS? >> >> Lionel B. Dyck < >> Website: https://www.lbdsoftware.com https://www.lbdsoftware.com >> >> "Worry more about your character than your reputation. Character is >> what you are, reputation merely what others think you are." - John >> Wooden >> >> >> - >> - >> - >> - >> - >> >> 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 Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intend
Re: CL/ / Supersession
I am curious here. This isn't my field really. If the traffic is only encrypted to the end application (TN3270) then what happens when a user signs on to CL/SS itself. It appears to me that the password would be sent in the clear. Lennie Dymoke-Bradshaw Consultant 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Edgington, Jerry Sent: 24 June 2020 16:30 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] CL/ / Supersession Yes, if you want to secure the inbound TN3270 traffic, then update AT/TLS configuration for TN3270 port to use SSL. And you will need have the SSL signing CA root, on the client requesting the TN3270 connection. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Karl S Huf Sent: Wednesday, June 24, 2020 11:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CL/ / Supersession This message was sent from an external source outside of Western & Southern's network. Do not click links or open attachments unless you recognize the sender and know the contents are safe. NTAC:3NS-20 So piling onto this thread . . . we've recently been asked to secure out TN3270 traffic. We are a CL/Superssion user (1.47) running z/OS 2.2 with a 2.4 project underway. Having caught up on this thread, if I understand correctly, there's nothing in CL/SS that needs to be done but rather updating the TN3270 server and, of course, the settings on the desktop emulator. Does this sound right? TIA! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tim Hare Sent: Saturday, June 20, 2020 6:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXT] Re: CL/ / Supersession This email originated from outside the organization. Do not click links or open attachments unless you have verified this email is legitimate. TN3270 supports secure sockets. Just make your TN3270 terminals "auto logon" to CL/Supersession and you're good. -- 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: Mainframe user ID length
> As a side note, why won't JCL accept all legal e-mail address? I thought there was an IBM stated aim to get to this, but I cannot find it. Certainly the recently added (Z/OS 1.3 I think) email field (WAEMAIL) in the RACF WORKATTR segment has a requirement to be unique within the RACF database. So there is a one-to-one mapping between email addresses and RACF userids. Looks like this is paving the way to achieving what you suggest. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: 04 May 2020 17:05 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Mainframe user ID length Your claim was "You can specify pretty much anything you want in JCL." Regardless of why it is coded that way, the code is in the C/I and the error message comes from the C/I. The fact remains that you are limited in what you can specify in JCL. My first thought was that you meant that JECL had looser limits, but I couldn't find thoses paraemters in either JES2 JECL or JES3 JECL. As a side note, why won't JCL accept all legal e-mail address? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Timothy Sipples [sipp...@sg.ibm.com] Sent: Monday, May 4, 2020 1:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mainframe user ID length Shmuel Metz wrote: >According to MVS JCL Reference, SA23-1385-40, both USER=abcdefghi and >EMAIL=foo+...@patriot.net are illegal. That's not a JES issue. It is JES's issue. JCL is simply respecting JES limits there using that particular syntax. If you want to pass a longer user ID to something else using a different vocabulary, JCL isn't going to stop you. Example: Try using JCL to invoke z/OS's FTP client to transfer a file to an arbitrary FTP server, specifying a user ID longer than 8 characters. Can it be done? Of course it can; it's perfectly routine. You just don't use JES-related syntax, that's all. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other 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 -- 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: Here we go again;
How did you delete the files if you were not allowed to logon? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Wayne Bickerdike Sent: 22 April 2020 21:18 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Here we go again; We had constraints at IBM when I worked there in 1978. The TSO logon procedure checked your personal space allocation. If you had more then 150 tracks allocated you had to delete some files to log on. At the time we were limited to 30 minutes a session to allow other programmers to get some "time sharing". Space saving isn't wasted effort. I had to fit applications on Z80 kit onto 2 110k floppy disks. As a kid, we sliced up a MARS bar. On Thu, Apr 23, 2020, 06:00 scott Ford wrote: > David, > > I laugh at these comments/observations. Early days 70-80s System > Programmers like myself helped programmers determine blocksize and > dataset location, etc. and then DBAs were born or made and then the > system optimized. > > Evolution > > Scott > > On Wed, Apr 22, 2020 at 3:44 PM Seymour J Metz wrote: > > > My first computer had a 2,000 word drum, a 60 word core memory, a > > 600,000 word disk drive and two tape drives. I may have been a tad > > more > constrained > > than you were when you started. I agree with Mr. Adam; people would > > have saved far more DASD space with intelligent choice of block size > > than the miniscule amount they saved by truncating the year. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > > behalf of Joel C. Ewing [jcew...@acm.org] > > Sent: Wednesday, April 22, 2020 3:12 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Here we go again; > > > > Should we presume you didn't work on mainframes prior to the advent > > of cheap memory and cheap RAID DASD in TB chunks? > > > > Even after advent of 3380, 3390, and even native 3390-3, drives our > > company didn't lease DASD drives without doing cost analysis. In > > late 1970's and early 1980's we were on 3330's and later 3350's, > > where physical constraints were also an issue -- when I started as > > SysProg in 1978, the computer room was maxed out space-wise at 29 > > 3330 drives, or only 2.9GB total DASD space. We didn't have DASD > > sitting around that wasn't 95% or more utilized. Batch jobs > > typically got one dedicated > > 3330 DASD work volume that they could allocate only for the duration > > of the job stream, staging data from/to tape as necessary to fit and > > to preserve for next job-stream run. It wasn't until 1995 and > > beyond, that it finally made economic sense for us to acquire DASD > > capacity a year or two before we might actually be able to justify a need. > > > > Our company believed in investing more money in people to retain > > good IT personnel rather than throwing money at hardware. That > > mind-set was one of the reasons why of the 50 some-odd companies in > > that line of business in 1950, of the 3 still in business in 2000, one was > > ours. > > > > Saving one or two bytes per date field in that kind of environment > > was not "marketing nonsense". By performance tuning and efficient > > application design we consistently delayed the need for a DASD or > > processor upgrades, resulting in *considerable* monetary savings > > over decades. You don't "waste" DASD or memory space just because > > it's available at the time without first considering the long-term > > impact on future upgrades. A "good" programmer/analyst was trained > > to err on the side of conserving resources. > > > > You can't judge decisions of the past without first understanding > > the cost, physical space, memory, and I/O configuration constraints > > under which those decisions were made. Unlike now where where easy > > incremental upgrades are possible, back then every upgrade, assuming > > one was possible, involved a substantial cost increase. > > JC Ewing > > > > On 4/22/20 12:05 PM, Gerhard adam wrote: > > > > > > > > > > > > > > > The notion of “savings” was marketing nonsense. The DASD > > > was > paid > > for regardless of whether it held a production database or someone’s > > golf handicap. >
Re: JESSPOOL problem accessing SYSLOG
Lou, Sorry to harp on about this, but these systems do not share a spool do they? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lou Losee Sent: 21 April 2020 01:54 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] JESSPOOL problem accessing SYSLOG Lennie, The problem is occurring on a system running with a RACF database. This is the second LPAR that is bing converted from Top Secret. The first did not show this problem nor have any other systems we have converted. It really makes me wonder what the SECURITY.SYSLOG.USESAFRECVR SDSF property was created for, as it solves this specific problem. On Mon, Apr 20, 2020 at 5:21 PM Lennie Dymoke-Bradshaw < lenni...@rsmpartners.com> wrote: > From what you are saying it appears you have a system that uses > different security software at different times. > > I know somewhere between nothing and zero about TSS, but is it > possible that TSS creates SYSLOG with an owner of *BYPASS* and that > SDSF was attempting to access that SYSLOG spool file? > > The entry I referred to previously about *BYPASS* indicated an ACEE > for user *BYPASS* would be created deliberately (and manually) in > order to make use of a REQUEST=EXTRACT RACROUTE call. > > 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 Lou Losee > Sent: 20 April 2020 21:24 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] JESSPOOL problem accessing SYSLOG > > I can't answer this right now, as we have re-IPL'd the system with TSS. > The problem occurred during a test IPL with a RACF DB converted from TSS. > The other LPAR we converted has SYSLOG using a user id of +MASTER+. I > have to assume that when we had the problem SYSLOG was running with a > user id of > *BYPASS* since it is the user id that goes into the 2nd qualifier of > the resource being checked. > > My best guess at this point is that SYSLOG is getting created before > RACF is available so it gets a user id of *BYPASS*. > > Lou > -- > Artificial Intelligence is no match for Natural Stupidity > - Unknown > > > On Mon, Apr 20, 2020 at 2:38 PM Lennie Dymoke-Bradshaw < > lenni...@rsmpartners.com> wrote: > > > Interesting. > > > > Seems to raise 2 questions. > > 1. Why is the 2nd qualifier "*BYPASS*"? > > 2. Why can you not find a profile that will match it? > > > > When I look at all the output on my system (z/OS 2.3) by setting no > > prefix and using the O SDF primary command, I see that the SYSLOG > > task is using a userid of +MASTER+. > > What is yours using? > > > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > > > > Web: www.rsmpartners.com > > ‘Dance like no one is watching. Encrypt like everyone is.’ > > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Lou Losee > > Sent: 20 April 2020 20:29 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: [IBM-MAIN] JESSPOOL problem accessing SYSLOG > > > > I posted this to RACF-L earlier, but have not received a response to > > help solve the problem so I have decided to cross-post here. > > > > I have a problem accessing the SYSLOG from SDSF on one LPAR. The > > problem appears to be caused by the second qualifier in the RACHECK > > request being > > *BYPASS* when it usually (on other systems/LPARs) is +MASTER+. Here > > is the ICH408I message I receive: > > > > ICH408I USER(THEUSER) GROUP(THEGROUP ) NAME(JOHN SMITH ) > >TST1JES.*BYPASS*.SYSLOG.SYSTEM.TST1 CL(JESSPOOL) > >PROFILE NOT FOUND - REQUIRED FOR AUTHORITY CHECKING > >ACCESS INTENT(READ ) ACCESS ALLOWED(NONE ) > > > > I have tried creating the following JESSPOOL profiles yet still get > > the same error: > > TST1JES.** > > TST1JES.%BYPASS%.SYSLOG.SYSTEM.TST1 > > TST1JES.*.SYSLOG.SYSTEM.TST1 > > > > Has anyone run into this before and have a solution? > > > > Right now the only ways I have found to get around it are: > > 1) Deactivate JESSPOOL (i.e., SETR NOCLASSACT(JESSPOOL)) > > 2) Setting the SDSF property SECURITY.SYSLOG.USESAFRECVR to TRUE. > > > > Lou > > > > > > -
Re: JESSPOOL problem accessing SYSLOG
From what you are saying it appears you have a system that uses different security software at different times. I know somewhere between nothing and zero about TSS, but is it possible that TSS creates SYSLOG with an owner of *BYPASS* and that SDSF was attempting to access that SYSLOG spool file? The entry I referred to previously about *BYPASS* indicated an ACEE for user *BYPASS* would be created deliberately (and manually) in order to make use of a REQUEST=EXTRACT RACROUTE call. 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 Lou Losee Sent: 20 April 2020 21:24 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] JESSPOOL problem accessing SYSLOG I can't answer this right now, as we have re-IPL'd the system with TSS. The problem occurred during a test IPL with a RACF DB converted from TSS. The other LPAR we converted has SYSLOG using a user id of +MASTER+. I have to assume that when we had the problem SYSLOG was running with a user id of *BYPASS* since it is the user id that goes into the 2nd qualifier of the resource being checked. My best guess at this point is that SYSLOG is getting created before RACF is available so it gets a user id of *BYPASS*. Lou -- Artificial Intelligence is no match for Natural Stupidity - Unknown On Mon, Apr 20, 2020 at 2:38 PM Lennie Dymoke-Bradshaw < lenni...@rsmpartners.com> wrote: > Interesting. > > Seems to raise 2 questions. > 1. Why is the 2nd qualifier "*BYPASS*"? > 2. Why can you not find a profile that will match it? > > When I look at all the output on my system (z/OS 2.3) by setting no > prefix and using the O SDF primary command, I see that the SYSLOG task > is using a userid of +MASTER+. > What is yours using? > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > > Web: www.rsmpartners.com > ‘Dance like no one is watching. Encrypt like everyone is.’ > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Lou Losee > Sent: 20 April 2020 20:29 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [IBM-MAIN] JESSPOOL problem accessing SYSLOG > > I posted this to RACF-L earlier, but have not received a response to > help solve the problem so I have decided to cross-post here. > > I have a problem accessing the SYSLOG from SDSF on one LPAR. The > problem appears to be caused by the second qualifier in the RACHECK > request being > *BYPASS* when it usually (on other systems/LPARs) is +MASTER+. Here > is the ICH408I message I receive: > > ICH408I USER(THEUSER) GROUP(THEGROUP ) NAME(JOHN SMITH ) >TST1JES.*BYPASS*.SYSLOG.SYSTEM.TST1 CL(JESSPOOL) >PROFILE NOT FOUND - REQUIRED FOR AUTHORITY CHECKING >ACCESS INTENT(READ ) ACCESS ALLOWED(NONE ) > > I have tried creating the following JESSPOOL profiles yet still get > the same error: > TST1JES.** > TST1JES.%BYPASS%.SYSLOG.SYSTEM.TST1 > TST1JES.*.SYSLOG.SYSTEM.TST1 > > Has anyone run into this before and have a solution? > > Right now the only ways I have found to get around it are: > 1) Deactivate JESSPOOL (i.e., SETR NOCLASSACT(JESSPOOL)) > 2) Setting the SDSF property SECURITY.SYSLOG.USESAFRECVR to TRUE. > > Lou > > -- > 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: JESSPOOL problem accessing SYSLOG
I also see that a userid of *BYPASS* is supported in some circumstances. There are some notes under this in the RACROUTE manual under REQUEST=VERIFY. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lennie Dymoke-Bradshaw Sent: 20 April 2020 20:37 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] JESSPOOL problem accessing SYSLOG Interesting. Seems to raise 2 questions. 1. Why is the 2nd qualifier "*BYPASS*"? 2. Why can you not find a profile that will match it? When I look at all the output on my system (z/OS 2.3) by setting no prefix and using the O SDF primary command, I see that the SYSLOG task is using a userid of +MASTER+. What is yours using? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lou Losee Sent: 20 April 2020 20:29 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] JESSPOOL problem accessing SYSLOG I posted this to RACF-L earlier, but have not received a response to help solve the problem so I have decided to cross-post here. I have a problem accessing the SYSLOG from SDSF on one LPAR. The problem appears to be caused by the second qualifier in the RACHECK request being *BYPASS* when it usually (on other systems/LPARs) is +MASTER+. Here is the ICH408I message I receive: ICH408I USER(THEUSER) GROUP(THEGROUP ) NAME(JOHN SMITH ) TST1JES.*BYPASS*.SYSLOG.SYSTEM.TST1 CL(JESSPOOL) PROFILE NOT FOUND - REQUIRED FOR AUTHORITY CHECKING ACCESS INTENT(READ ) ACCESS ALLOWED(NONE ) I have tried creating the following JESSPOOL profiles yet still get the same error: TST1JES.** TST1JES.%BYPASS%.SYSLOG.SYSTEM.TST1 TST1JES.*.SYSLOG.SYSTEM.TST1 Has anyone run into this before and have a solution? Right now the only ways I have found to get around it are: 1) Deactivate JESSPOOL (i.e., SETR NOCLASSACT(JESSPOOL)) 2) Setting the SDSF property SECURITY.SYSLOG.USESAFRECVR to TRUE. Lou -- 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: JESSPOOL problem accessing SYSLOG
Interesting. Seems to raise 2 questions. 1. Why is the 2nd qualifier "*BYPASS*"? 2. Why can you not find a profile that will match it? When I look at all the output on my system (z/OS 2.3) by setting no prefix and using the O SDF primary command, I see that the SYSLOG task is using a userid of +MASTER+. What is yours using? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lou Losee Sent: 20 April 2020 20:29 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] JESSPOOL problem accessing SYSLOG I posted this to RACF-L earlier, but have not received a response to help solve the problem so I have decided to cross-post here. I have a problem accessing the SYSLOG from SDSF on one LPAR. The problem appears to be caused by the second qualifier in the RACHECK request being *BYPASS* when it usually (on other systems/LPARs) is +MASTER+. Here is the ICH408I message I receive: ICH408I USER(THEUSER) GROUP(THEGROUP ) NAME(JOHN SMITH ) TST1JES.*BYPASS*.SYSLOG.SYSTEM.TST1 CL(JESSPOOL) PROFILE NOT FOUND - REQUIRED FOR AUTHORITY CHECKING ACCESS INTENT(READ ) ACCESS ALLOWED(NONE ) I have tried creating the following JESSPOOL profiles yet still get the same error: TST1JES.** TST1JES.%BYPASS%.SYSLOG.SYSTEM.TST1 TST1JES.*.SYSLOG.SYSTEM.TST1 Has anyone run into this before and have a solution? Right now the only ways I have found to get around it are: 1) Deactivate JESSPOOL (i.e., SETR NOCLASSACT(JESSPOOL)) 2) Setting the SDSF property SECURITY.SYSLOG.USESAFRECVR to TRUE. Lou -- 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: Opinions/experience on sharing catalogs outside plex
Rob, The manual, "MVS Planning: Global Resource Serialization" SA23-1389-30 has information on sharing catalogs. SYSIGGV2 needs to use reserves. However, I think you also need to use reserves on SYSZVVDS and SYSVTOC. From memory (rather distant and not always reliable) there is also an IMS Qname that needs to be added to the list, but only if you use IMS. As for your ISPF question, I am unclear of the situation you describe. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Rob Schramm Sent: 09 April 2020 01:11 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] Opinions/experience on sharing catalogs outside plex I am considering sharing some usercats outside of a sysplex. What I can find is that sysiggv2 must be kept as a reserve to do so. Looking for others that have had to do this. One question I had was, what happens on a ispf 3.4 when the data set is part of the catalog but exists in another system? Ief238d? Thanks, Rob Schramm -- 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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
I think the reason that handling interrupts in ESPIE is faster than ESTAE is simply that ESPIE sets an exit to the FLIH, whereas ESTAE sets an exit to the SLIH. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: 02 April 2020 20:59 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) As Peter seems to imply, ESPIE interrupts are apparently noticeably lower overhead than ESTAE interrupts. If data or addressing exceptions were expected I definitely *would* use ESPIE. I would save ESTAE for unexpected (well, expected unexpected) conditions. My opinion: no benchmarks, no source code. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gord Tomlin Sent: Thursday, April 2, 2020 12:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks) On 2020-04-02 14:14, Charles Mills wrote: > I had the same observation. Sending every condition through the same handler > was advantageous for me. Same here. > > You would want to keep the SPIE if program checks were expected: perhaps a > report generator where you anticipated that users might declare fields to be > packed when they were not always valid. You can also recover program checks from ESTAE(X). "You would want" -> "You might want". -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- 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: IGGCSI00 and REXX
ITschak, Blue sky thinking.. What I am thinking of is something that potentially returns everything about each entry selected, whether the entry be a NONVSAM, CLUSTER, DATA, INDEX, PATH, AIX, USERCAT and so on. What would be nice is to have a set of variables populated for each attribute or value, much like IRRXUTIL does for RACF. But I am interested in anything else that I might be able to modify. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of ITschak Mugzach Sent: 17 March 2020 18:49 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] IGGCSI00 and REXX Lenni, What exactly you need? we have a modified copy of the rexx used in our product (IronSphere) that act like a rexx function and returns dataset list using push to the stack. so, what exactly do you need? ITschak ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM comming son * On Tue, Mar 17, 2020 at 6:49 PM Lennie Dymoke-Bradshaw < lenni...@rsmpartners.com> wrote: > Scott, > Thanks, > > As I live in the UK I don't get to Share. If anyone else has the name > of this REXX person (Ken something) I would be pleased. > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > Web: www.rsmpartners.com > ‘Dance like no one is watching. Encrypt like everyone is.’ > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of scott Ford > Sent: 17 March 2020 15:03 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] IGGCSI00 and REXX > > Gil, > > If memory serves me correctly Ken ( I dont remember his last name , > the rexx wiz from SHARE ) has a real nice piece of Rexx code for > IGGCSI00, just a idea for you sir. > > Scott > > On Tue, Mar 17, 2020 at 10:59 AM scott Ford wrote: > > > Steve, > > > > I have written in rexx,oorexx,assembler,cobol,bash,,,on and on. For > > a lot of system chores I love Rexx. > > The big reason is being interpreted is fairly easy to see output and > > work with it especially if the output is being used for another > > piece of code. Every programming language IMHO evolves. > > > > Scott > > > > On Tue, Mar 17, 2020 at 10:04 AM Lionel B Dyck wrote: > > > >> If you have PIPEs available the PIPE LISTCAT is an excellent tool > >> to use if you only want the dataset name, and optionally the > >> dataset type. > >> > >> > >> Lionel B. Dyck < > >> Website: http://www.lbdsoftware.com > >> > >> "Worry more about your character than your reputation. Character > >> is what you are, reputation merely what others think you are." - > >> John Wooden > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List On > >> Behalf Of Seymour J Metz > >> Sent: Tuesday, March 17, 2020 9:00 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: IGGCSI00 and REXX > >> > >> All languages have glitches, especially C. Certainly there are > >> things that could be cleaned up in REXX, but there are other things > >> that are eleant if not misused. > >> > >> > >> -- > >> Shmuel (Seymour J.) Metz > >> http://mason.gmu.edu/~smetz3 > >> > >> > >> > >> From: IBM Mainframe Discussion List on > >> behalf of Steve Smith > >> Sent: Tuesday, March 17, 2020 9:53 AM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: IGGCSI00 and REXX > >> > >> REXX is inherently kludgy (who needs structures? SUBSTR can do > >> anything!). > >> > >> That's not a big REXX exec. Just de-kludge to your taste, if possible. > >> IGGCSI00 is tricky to get started with, so you definitely want to > >> start with a working example. There are also a couple of assembler > >> samples provided. > >> There's also a C routine available at > >> > >> http://secure-web.cisco.com/1wOZihD3Fa5eFMrPjJLAHOb-MPTLnm9aUn42uRC > >> eI > >> xKUCIx- > >> > >> UR1tXB89h9436dtjipNwEdUx1mherLzMBxowcAECfcpp8w7R4LO6Hti_aRoGYAjj6Of > >> BL > >> BsQC_OU > >> <http://secure-web.cisco.com/1wOZihD3Fa5eFMrPjJLAHOb-MPTLnm9aUn42uR > >> Ce > >> IxKUCIx-UR1tXB89h9436dtjipNwEdUx1mherLzMBxowcAECfcpp8w7R4LO6Hti_aRo > >> GY > >> Ajj6OfBLBsQC_OU>
Re: IGGCSI00 and REXX
Scott, Thanks, As I live in the UK I don't get to Share. If anyone else has the name of this REXX person (Ken something) I would be pleased. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of scott Ford Sent: 17 March 2020 15:03 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] IGGCSI00 and REXX Gil, If memory serves me correctly Ken ( I dont remember his last name , the rexx wiz from SHARE ) has a real nice piece of Rexx code for IGGCSI00, just a idea for you sir. Scott On Tue, Mar 17, 2020 at 10:59 AM scott Ford wrote: > Steve, > > I have written in rexx,oorexx,assembler,cobol,bash,,,on and on. For a > lot of system chores I love Rexx. > The big reason is being interpreted is fairly easy to see output and > work with it especially if the output is being used for another piece > of code. Every programming language IMHO evolves. > > Scott > > On Tue, Mar 17, 2020 at 10:04 AM Lionel B Dyck wrote: > >> If you have PIPEs available the PIPE LISTCAT is an excellent tool to >> use if you only want the dataset name, and optionally the dataset >> type. >> >> >> Lionel B. Dyck < >> Website: http://www.lbdsoftware.com >> >> "Worry more about your character than your reputation. Character is >> what you are, reputation merely what others think you are." - John >> Wooden >> >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Seymour J Metz >> Sent: Tuesday, March 17, 2020 9:00 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: IGGCSI00 and REXX >> >> All languages have glitches, especially C. Certainly there are things >> that could be cleaned up in REXX, but there are other things that are >> eleant if not misused. >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> >> From: IBM Mainframe Discussion List on >> behalf of Steve Smith >> Sent: Tuesday, March 17, 2020 9:53 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: IGGCSI00 and REXX >> >> REXX is inherently kludgy (who needs structures? SUBSTR can do >> anything!). >> >> That's not a big REXX exec. Just de-kludge to your taste, if possible. >> IGGCSI00 is tricky to get started with, so you definitely want to >> start with a working example. There are also a couple of assembler >> samples provided. >> There's also a C routine available at >> >> http://secure-web.cisco.com/1wOZihD3Fa5eFMrPjJLAHOb-MPTLnm9aUn42uRCeI >> xKUCIx- >> >> UR1tXB89h9436dtjipNwEdUx1mherLzMBxowcAECfcpp8w7R4LO6Hti_aRoGYAjj6OfBL >> BsQC_OU >> <http://secure-web.cisco.com/1wOZihD3Fa5eFMrPjJLAHOb-MPTLnm9aUn42uRCe >> IxKUCIx-UR1tXB89h9436dtjipNwEdUx1mherLzMBxowcAECfcpp8w7R4LO6Hti_aRoGY >> Ajj6OfBLBsQC_OU> >> >> Lqfmj1R875N514gGXEhDzeyH3BGHLJ3QNTcHDotuMSz5-dBJbG-Z_L3NhZFbmfG4UOg14 >> 00CXcTL >> >> mSxv4f81RPgyxwOl_vJmC49J4xOzqCZIL583uE_gHt4DOgBZOKHxtjKkSikit4lxoregv >> aKEy4pK >> >> OhU_RY7MGWb55BeWUW7708RnbA44sKB9t7LABZ_59W5AZ6xdDRqRt_R-20StYBa0_libb >> OJUL4B7 >> >> XATr9Hk95dBswQepWTrkSsnvZBloN7KlVY3gI7V-jnOXOw6UPa9b5DYPhlS0BeUjq835x >> CEsF67I >> IYj0049zJ91nCvFie-fXq/http%3A%2F%2Fwww.longpelaexpertise.com.au >> called LPCSI. >> >> sas >> >> >> On Tue, Mar 17, 2020 at 9:17 AM Lennie Dymoke-Bradshaw < >> lenni...@rsmpartners.com> wrote: >> >> > I have a need to make use of IGGCSI00. >> > It would make my life a lot easier if I could work in REXX rather >> > than assembler. I see that IBM have supplied a sample routine >> > called IGGCSIRX showing how it can be used from REXX, though it >> > looks a little cludgy; not as elegant as the RACF interface to REXX, >> > IRRXUTIL. >> > >> > Has anyone done any work in this area that they can share? >> > For example a more general REXX interface either written in >> > assembler, or even in REXX? >> >> - >> - 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 l
IGGCSI00 and REXX
I have a need to make use of IGGCSI00. It would make my life a lot easier if I could work in REXX rather than assembler. I see that IBM have supplied a sample routine called IGGCSIRX showing how it can be used from REXX, though it looks a little cludgy; not as elegant as the RACF interface to REXX, IRRXUTIL. Has anyone done any work in this area that they can share? For example a more general REXX interface either written in assembler, or even in REXX? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com<http://www.rsmpartners.com/> 'Dance like no one is watching. Encrypt like everyone is.' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Finding and replying to outstanding reply
If your shutdown program allows you to issue commands and then parse the response you could issue a D R,R command and then find the reply number in message EZY0960I. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Thigpen Sent: 11 February 2020 13:31 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] Finding and replying to outstanding reply We have an in-house written automated shutdown program that does everything but shutdown NPF. That is because NPF leaves an open reply message during start-up to which I must replay xx,STOP to make it shutdown. Within our shutdown program, I would like it to programmatically find the outstanding reply number so that it can issue the correct response. Can someone point me to any doc or examples that will help me get started on this? Some items: The shutdown program is assembler. I have SysREXX running with a valid MPF exit to call it. I would prefer to do it all within the assembler program instead of using MPF/SysREXX. Thoughts? -- Tony Thigpen -- 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: Creating VSAM data sets with DSNTYPE=EXTREQ
Cameron, Sadly I have no dataclas with extended specified and I do not want to have to produce more dataclas specifications at the moment. When you say " We have seen some issues with XCOM, SYNCSORT, FILEAID and ISPW" could you be more specific please? Thanks, Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd 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: 16 January 2020 16:00 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Creating VSAM data sets with DSNTYPE=EXTREQ For IDCAMS DEFINE I added DATACLAS(extended dataclas name) For JCL and PROCs I added DATACLAS(...) as well If DATACLAS was already specified I just changed the name to an extended format name Don’t get me wrong. You can change the members but you still need to test and promote. We have seen some issues with XCOM, SYNCSORT, FILEAID and ISPW. Sent from my iPhone > On Jan 16, 2020, at 9:48 AM, Lennie Dymoke-Bradshaw > wrote: > > I am doing planning for the encryption of application data. I have a need to > encrypt some fairly large numbers of VSAM datasets. > > I am trying to develop some tooling to help with the allocation and > encryption of the VSAM data sets. I need to define replacement data > sets which are extended format (DSNTYPE=EXTREQ in JCL terms). I can > allocate new data sets using the following methods, > > > 1. IDCAMS: DEFINE CLUSTER with MODEL pointing at existing cluster. Using > this method I can specify the names of the VSAM index and data components. > However, I cannot see how to specify that I want extended format. > 2. IDCAMS: ALLOCATE with LIKE specifying the original cluster name. Using > this method I can specify DSNTYPE(EXTREQ), but I cannot specify the names of > the data and index components. > 3. IKJEFT01: ALLOCATE with LIKE specifying the original cluster name. This > is identical to option 2 as IDCAMS will be invoking IKJEFT01 to do the > allocation. > 4. JCL: With this method I can again specify DSNTYPE=EXTREQ, but I cannot > specify the names of the index and data components. > > At this stage I do not want to alter the existing SMS ACS routines. Is there > any way I can specify both the data and index component names and EXTREQ? > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > Web: www.rsmpartners.com<http://www.rsmpartners.com/> > 'Dance like no one is watching. Encrypt like everyone is.' > > > -- > 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
Creating VSAM data sets with DSNTYPE=EXTREQ
I am doing planning for the encryption of application data. I have a need to encrypt some fairly large numbers of VSAM datasets. I am trying to develop some tooling to help with the allocation and encryption of the VSAM data sets. I need to define replacement data sets which are extended format (DSNTYPE=EXTREQ in JCL terms). I can allocate new data sets using the following methods, 1. IDCAMS: DEFINE CLUSTER with MODEL pointing at existing cluster. Using this method I can specify the names of the VSAM index and data components. However, I cannot see how to specify that I want extended format. 2. IDCAMS: ALLOCATE with LIKE specifying the original cluster name. Using this method I can specify DSNTYPE(EXTREQ), but I cannot specify the names of the data and index components. 3. IKJEFT01: ALLOCATE with LIKE specifying the original cluster name. This is identical to option 2 as IDCAMS will be invoking IKJEFT01 to do the allocation. 4. JCL: With this method I can again specify DSNTYPE=EXTREQ, but I cannot specify the names of the index and data components. At this stage I do not want to alter the existing SMS ACS routines. Is there any way I can specify both the data and index component names and EXTREQ? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com<http://www.rsmpartners.com/> 'Dance like no one is watching. Encrypt like everyone is.' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SVC 26
SVC26 existed long before the Catalog address space did. I feel sure there are some paths that will not require access to the Catalog address space. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Apoorva Sent: 08 January 2020 16:09 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] SVC 26 Hello, When SVC 26 is invoked, I believe it communicates with the CATALOG address space to either read from Catalog or write into Catalog? If this is true, I would like to understand how SVC 26 communicates with CATALOG address space? Is it either through POST/WAIT logic or through PC interface (or some other way)? In order to understand this I took a SLIP dump right after SVC 26 invocation, in one of my test programs, and tried to read the SYSTRACE entries, in the dump, in between "SVC 1A" and "SVCR 1A" but I didn't get a clue on how communication may happen (if at all it happens). Thanks, Apoorva -- 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: it was 20 years ago today
I think the most secure answer to the first question is to turn the power off. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: 05 January 2020 18:25 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] it was 20 years ago today I think we should stick with this list for as long as possible. 1) What is the absolute best way to clear a register? 2) Exactly how many cycles does it take to do an LA instruction? 3) Is EBCDIC really that bad? 4) Funky late-night experiences with data cells, optical readers and long-gone software 5) Why IBM's implementation of Posix time zones is flawed 6) Is JCL really that bad? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Brennan Sent: Friday, January 3, 2020 12:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: it was 20 years ago today We probably should change the subject. Some suggestions: . . 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 Don Leahy Sent: Saturday, January 4, 2020 10:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: it was 20 years ago today I was working on contract with a major bank during the run up to Y2K. The bank was so confident that they had the issue licked that they laid off all of the contractors in November. I found another contract immediately, but my new shop also had things well in hand, so I ended up partying that night. Neither shop had any significant issues during the century change. On Fri, Jan 3, 2020 at 13:23 Gabe Goldberg wrote: > Just came across: ‘Here We Go. The Chaos Is Starting’: An Oral > History of Y2K > > https://www.popularmechanics.com/technology/security/a30338692/y2k-pan > ic/ > > I still have about half the Y2K books I bought, figure they'll go with > the next Great Purge. Circa 1995 I thought of doing "The Y2K Handbook" > (like "The REXX Handbook" and two VM/ESA handbooks co-edited with Phil > Smith) but never got around to it. Likely for the best, considering > the tsunami of books published. > > -- > Gabriel Goldberg, Computers and Publishing, Inc. g...@gabegold.com > 3401 Silver Maple Place, Falls Church, VA 22042 > <https://www.google.com/maps/search/3401+Silver+Maple+Place,+Falls+Church,+VA+22042?entry=gmail=g> > (703) 204-0433 > LinkedIn: http://www.linkedin.com/in/gabegoldTwitter: GabeG0 -- 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: Strange Migration behaviour DFHSM
Is it possible you have a tape device which is stuck in some allocation failure? I encountered one of these many years back. Device management had issued a message for a failed allocation and the message had been DOMed. Net result was that tape allocations hung behind the first failure. I my case they hung for several weeks. All tape used in this installation was for DFHSM, so it looked like a DFHSM error. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jake Anderson Sent: 30 December 2019 03:50 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] Strange Migration behaviour DFHSM Hi Our DFHSM is a single host based . Strange behaviour an noticing with it as when i manually try to HMIGRATE to ML2(Virtual tape) and it's still in DFHSM request queue for more than a 1 day. I scanned through HSM log and i dont see any error related to the dataset am trying to migrate. The MCDS is at 90% and it's threshold is at 95%. Can this be a real issue? Jake -- 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: Looking for a utility to create a master listing of all PDS members on a system
Radoslaw, Have you mistyped there? I really don't think PDSE is 40 years old. That would mean it was around in 1979. In 1979 we were still working on a 16MB system. We did not even have cross memory services, that came in with MVS/SP 1.2. I joined IBM in 1996 and worked in the support centre for a while. We were dealing with early problems with PDSE then. So I think PDSE may be older than 25 years. Or have I misunderstood? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: 12 December 2019 17:14 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Looking for a utility to create a master listing of all PDS members on a system W dniu 2019-12-11 o 17:01, Paul Gilmartin pisze: > On Wed, 11 Dec 2019 10:40:33 -0500, Don Leahy wrote: > >> I have a rexx program that reads in a list of data set names and / or >> masks and creates a “master” member list consisting of all of the PDS/E >> members >> found in the data sets. The output is a file containing the member name, >> the DSN, last update date (from ISPF stats, if available) and the >> number of lines in the member. >> > Grrr... > FAMS keeps timestamps for PDSE members with microsecond precision. > The interface spec is available for a price, perhaps NDA. > > It boggles the mind that a vendor would keep customers' file > timestamps secret. It's both: funny and annoying. PDSE is almost 40 years old, AFAIK and many features of it is still secret, not in use, etc. Note, it's not discussion about source code, it is about really basic features. I can't imagine any reason to keep it secret. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2019 r. wynosi 169.347.928 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.347.928 as at 1 January 2019. -- 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: Misuse of the word hexadecimnal (Was RE: COPYING PDS TO PDS ...)
Whatever.. But. I think the word in the title should be 'hexadecimal' rather than 'hexadecimnal' . Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: 05 December 2019 18:42 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Misuse of the word hexadecimnal (Was RE: COPYING PDS TO PDS ...) Or 12. or 9. Bring back Stretch. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Wednesday, December 4, 2019 4:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Misuse of the word hexadecimnal (Was RE: COPYING PDS TO PDS ...) I pretty much stuck to the term byte for that reason. A byte is eight 1/0 bits. A character starts to get off into cultural issues. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gord Tomlin Sent: Wednesday, December 4, 2019 11:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Misuse of the word hexadecimnal (Was RE: COPYING PDS TO PDS ...) On 2019-12-04 13:52, Tom Marchant wrote: > The point of using a term like "any hexadecimal character" is to > indicate that all 256 possible values in the byte are acceptable. Even that breaks down if you choose to let wide characters (e.g., UTF-16 or UTF-32) into the conversation. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://secure-web.cisco.com/1H6HvE9GVW8CUjGXUxBZBz9a9SP4KAnqHUyKZ8PN8Op7WhWKsa1_qr2Jyl5D_wCXzWFOD-jAHJnosAtPisXXQh5BBogiAki8_SXy5_Q65RhtIVA98W-TZAEGOjLsY9NDOZ573RJdq-XrcLvqihZHRQaryBbAYlecG_3WB27bGV4t9ZcYh6lVq0LUZyPQ0uopoHp17fNVuErKhc5xEdlbo6flitqMndh62o6hc5bmuyULzxyEeRLBoYr7tcnByMaWI7cx7VEccvlcSX5cwR1OM3zYnXa3lUYrOW3D_3O6VAx4cvjMxUOqT8j2TjKQvF-CxO1kXUy9KaDKghiyXKlFKRIxbPus28beK43o15YfJJq3vXNHUiZb8OS3OdNN7jo5E7tw8_TjC4zM_UvV4UnPn8mTuelJHl9Nyo7v-e2FtmV7b3snc2fgT1G-QldcgsTQh/https%3A%2F%2Factionsoftware.com%2Fsupport%2F -- 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: A minimum of 8 GB of real memory is required to IPL
I have successfully IPLed z/OS 2.3 in a 4GB region using zPDT. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Richards, Robert B. Sent: 05 December 2019 14:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] A minimum of 8 GB of real memory is required to IPL * For z/OS V2R3 with the IBM z14(tm) (z14) server, a minimum of 8 GB of real memory is required to IPL. Does this statement only apply only to the z14 or all models *after* it? For example, the z14_ZR1 and the z15? -- 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: AUTHPGM in IKJTSOxx
Yes. My mistake. I should have said AUTHTSF. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Walt Farrell Sent: 04 December 2019 21:38 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] AUTHPGM in IKJTSOxx On Wed, 4 Dec 2019 01:28:39 +, Lennie Dymoke-Bradshaw wrote: >Jesse / Skip, > >This is actually defined as being a requirement in "DFSMS Access Method >Services Commands" SC23-6846-30. See Page 6, or just search for AUTHCMD >and you will quickly find it. It states the following, > >"To use IDCAMS and some of its parameters from TSO/E, your system programmer >must update the system by one of these means: >. Update the IKJTSOxx member of SYS1.PARMLIB. This is the method that IBM >recommends. Add IDCAMS to the list of authorized programs (AUTHPGM). If you >want to use SHCDS, SETCACHE, LISTDATA, DEFINE or IMPORT from TSO/E, add them >(and abbreviations) to the authorized command list(AUTHCMD). >. Update the IKJEGSCU CSECT instead of IKJTSOxx, see z/OS TSO/E Customization >for more information." > >This does not introduce the exposure that placing IDCAMS into AUTHPGM does. >Several forms of DEFINE require APF authorisation. There is no exposure, today, with having IDCAMS in the AUTHPGM list. There was, I believe, in the distant past before the AUTHTSF list was created. There would be an exposure putting IDCAMS in the AUTHTSF list. For more: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikjb700/ikjb700_Program_Authorization_and_Isolation.htm -- Walt -- 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: AUTHPGM in IKJTSOxx
Jesse / Skip, This is actually defined as being a requirement in "DFSMS Access Method Services Commands" SC23-6846-30. See Page 6, or just search for AUTHCMD and you will quickly find it. It states the following, "To use IDCAMS and some of its parameters from TSO/E, your system programmer must update the system by one of these means: . Update the IKJTSOxx member of SYS1.PARMLIB. This is the method that IBM recommends. Add IDCAMS to the list of authorized programs (AUTHPGM). If you want to use SHCDS, SETCACHE, LISTDATA, DEFINE or IMPORT from TSO/E, add them (and abbreviations) to the authorized command list(AUTHCMD). . Update the IKJEGSCU CSECT instead of IKJTSOxx, see z/OS TSO/E Customization for more information." This does not introduce the exposure that placing IDCAMS into AUTHPGM does. Several forms of DEFINE require APF authorisation. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: 04 December 2019 00:40 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] AUTHPGM in IKJTSOxx I thought I was done with this thread, but today a new gotcha popped up. On one system, we ran out of local page space. We could log on (TSO) but could not start any task or submit any job. To avoid IPL, we needed to create another local page data set. Back in the halcyon days, if you're old enough to remember--and young enough to remember--we could use STEPCAT or JOBCAT to create page space on an adjacent system. Both of those options are long gone. Since we could logon to the depleted system, we tried using TSO DEF PAGESPACE. On the problem system, we got S338 abend. On another system, however, the command worked just fine. The actual solution was long and tortuous and not to be undertaken lightly. Afterwards, we looked in IKJTSO00. On the system where DEFINE worked, we found AUTHCMD NAMES( /* AUTHORIZED COMMANDS */ + DEFINE/* FOR AUTH AMS SVCS */ + Looks like an oversight, but in neither system did CPAC parmlib contain that line. So it may not be safe after all, but the solution undertaken is hardly safe either. It was do that or IPL. Advice? . . 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 Seymour J Metz Sent: Wednesday, November 27, 2019 9:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: AUTHPGM in IKJTSOxx Well, IBM ha documented a lot of the rules for authorized code. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Michael Stein Sent: Wednesday, November 27, 2019 12:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: AUTHPGM in IKJTSOxx On Tue, Nov 26, 2019 at 07:13:47PM +, Seymour J Metz wrote: > If you have update access to APF authorized libraries then you could > certainly write such a program, although a competent auditor would > read you the riot act if he found out. Exploiting a program that > follows the rules is harder. Figuring out the "rules" is hard. Following them is harder. It's very easy to get an authorized function to usually work. Writing the code so that it works and fails correctly and is secure is much harder.. For security it's usually best to let the hardware provide the security boundaries whereever possible (address space and protect keys). Write access to an APF library on a personal test system is really useful for education, development, and trying out system services. A non-shared test system doesn't have system stability or security issues to be concerned about. But be very careful NEVER to run that type of code on shared systems. I once traced instruction counts for a path of "hit enter once" type action. This involved turning on instruction fetch PER and disabled DAT off code to update a counter for each asid/instruction address. -- 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: COPYING PDS TO PDS ...
Well I have tried all sorts of settings for that but I cannot get it to work. If you place the entire DSNAME and member including brackets, then the system looks for a DSCB matching it. If you just place the member in quotes then you get a JCL error. So I don't think JCL will support it. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Vernooij, Kees (ITOP NM) - KLM Sent: 03 December 2019 11:16 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] COPYING PDS TO PDS ... In JCL you can put any hexadecimal character in a dsname if you enter it between quotes. Never tried it for PDS membernames, but I suppose it will work too. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lennie Dymoke-Bradshaw Sent: 03 December 2019 12:11 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COPYING PDS TO PDS ... You can store non-standard member names in PDS datasets using STOW macros. IBM used to do this in the forerunner of SMP/E called SMP. They used large PDSs with member names that were unprintable hex characters. I have not found a way to reference member names that are not upper-case printable characters in JCL. But maybe someone knows better! Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lionel B Dyck Sent: 03 December 2019 10:48 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] COPYING PDS TO PDS ... I'm not aware standard services allow mixed case member names - but as far as I know PDS only works with IBM standard and I was not able, using PDS to create a member name with lower case. Get it and try it - it's free. So kick the tires and see if it does what you want. Lionel B. Dyck < Website: http://www.lbdsoftware.com "Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are." - John Wooden -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Monday, December 2, 2019 7:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COPYING PDS TO PDS ... On Mon, 2 Dec 2019 18:57:08 -0600, Lionel B Dyck wrote: >The pds command is case insensitive in this area - dataset names and member >names are all converted to upper case as is standard for z/OS. The commands as >well are case insensitive. > >Try it - you'll love it. > So if I have two members whose names differ only in the case of some character, I can't distinguish between them with the pds command. I don't think I'd love that. Are the commands case insensitive with respect to names in the PDS directory, or only in commands? That is, suppose I have carelessly created a member name containing a lower case character, can I use the pds command to rename it to something more conventional? -- gil -- 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 information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signof
Re: COPYING PDS TO PDS ...
You can store non-standard member names in PDS datasets using STOW macros. IBM used to do this in the forerunner of SMP/E called SMP. They used large PDSs with member names that were unprintable hex characters. I have not found a way to reference member names that are not upper-case printable characters in JCL. But maybe someone knows better! Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lionel B Dyck Sent: 03 December 2019 10:48 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] COPYING PDS TO PDS ... I'm not aware standard services allow mixed case member names - but as far as I know PDS only works with IBM standard and I was not able, using PDS to create a member name with lower case. Get it and try it - it's free. So kick the tires and see if it does what you want. Lionel B. Dyck < Website: http://www.lbdsoftware.com "Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are." - John Wooden -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Monday, December 2, 2019 7:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COPYING PDS TO PDS ... On Mon, 2 Dec 2019 18:57:08 -0600, Lionel B Dyck wrote: >The pds command is case insensitive in this area - dataset names and member >names are all converted to upper case as is standard for z/OS. The commands as >well are case insensitive. > >Try it - you'll love it. > So if I have two members whose names differ only in the case of some character, I can't distinguish between them with the pds command. I don't think I'd love that. Are the commands case insensitive with respect to names in the PDS directory, or only in commands? That is, suppose I have carelessly created a member name containing a lower case character, can I use the pds command to rename it to something more conventional? -- gil -- 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: WTO
I seem to recall there was another such pointer in the SMF structures and I thought the Nasty Wet Monster Bank used that. But maybe I am mixing things up. Could have been some other bank. These fields were great for local mods and I made extensive use of the CVTUSER field in the 1980s to hold flags, settings and values (even whole tables) used by various exits which were used by multiple MVS installations I supported. I had code (and a change protocol) that could modify these in flight, thus altering the flow of control in exits and so on. The fields that Peter has described (Thank you Peter) are for vendors. If, in time passed, any Vendor made use of the CVTUSER field he could be sure he would upset many customers. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Rupert Reynolds Sent: 30 November 2019 16:40 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] WTO ahem! I meant to say CVTUSER, a very different field from CVTUSR :-) On Sat, 30 Nov 2019, 15:17 Rupert Reynolds, wrote: > Whatever happened to CVTUSR? Back in the 1990s we used to have (from > memory) a started task that came up briefly during IPL and it > allocated storage (I forget what key, but read only in the general > case) for a vector table, pointed CVTUSR at that, and then it stopped itself. > > So if I was (say) at Nasty Wet Monster Bank, it would point CVTUSR at > the NMVT, which we could use for anything within reason. > > Ruz > > On Sat, 30 Nov 2019, 13:56 Peter Relson, wrote: > >> Lennie wrote: >> >> Is this intended to be undocumented? >> Is there a published list of the existing assignments of those slots? >> >> >> To the first: it is documented. To the extent appropriate, that being >> commentary in the data area book and showing the fields as "PI". >> To the second: no. >> >> It is up to each ISV whether they want to make known what slot they >> are using (and up to them to document whatever they feel appropriate >> about such use). >> >> 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 >> > -- 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: WTO
Thanks Peter. That makes sense. Given that you have not replied regarding the existing slot assignments, I will assume they are not published until I find differently. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: 29 November 2019 02:28 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] WTO Sigh. Sorry. I meant ECVTCTBL as the pointer to the 4-byte slots (not CVTCTBL) and ECVTCTB2 as the pointer to the 8-byte slots (not ECVTCTBL). <> 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WTO
Peter, On my z/OS 2.3 system I can find the field ECVTCTBL documented on the Data Areas manuals in the ECVT and I can find the field in the IHAECVT macro on the system. I can find no reference to the CVTCTBL in the Data Areas or in the CVT macro. Is this intended to be undocumented? Is there a published list of the existing assignments of those slots? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: 28 November 2019 14:29 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] WTO If you really need speed, check if IBM has any user vector table entries specifically assigned for customer use. 4 load instructions instead of searching thru a chain. IBM assigns each entry (e.g. product vendor request). I vaguely recall it being called CSRCTABL but I could be wrong. Upon request (to me), IBM assigns to an ISV a slot in the anchor tables pointed to by CVTCTBL and, starting in z/OS 2.3, ECVTCTBL. Slots 1009 - 1024 are reserved for customer usage (i.e., the owner of the system) for whatever they see fit. Slots 1009 - 1024 should be used only for uses of which the customer approves. The slots are 1-origin, so slot 1 is at offset 0. Each slot is 4 bytes wide via CVTCTBL, 8 bytes wide via ECVTCTBL. The slots are in key 0 page-fixed common storage. 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AUTHPGM in IKJTSOxx
The point is to pass an address to an authorised program so that it can call back the unauthorised program (at a different entry point in (for example) supervisor state. So you are saying you can design code which bypasses system integrity. If you had a program which took that characterised hex address and then passed control to it in supervisor state, then that is NOT a suitable program for AUTHPGM or AUTHCMD or AUTHTSF. There are many ways to design programs to subvert z/OS integrity. The more difficult and worthwhile thing to do, is achieving what you need without bypassing z/OS integrity. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: 26 November 2019 00:20 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] AUTHPGM in IKJTSOxx I'm having trouble imagining a scenario where an EBCDIC representation of an address would be useful. The problem is, in a job step situation, how would you figure out an address to pass? //STEP1 EXEC PGM=my-pgm,PARM=??? How would I figure out what address to pass? If instead my-pgm is called from another program, then I would not use the JCL parm format being discussed. In that case, I would pass the address directly without the EBCDIC conversion game. . . 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 Paul Gilmartin Sent: Monday, November 25, 2019 3:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: AUTHPGM in IKJTSOxx On Mon, 25 Nov 2019 23:26:32 +, Jeremy Nicoll wrote: >On Mon, 18 Nov 2019, at 19:35, Seymour J Metz wrote: >> A program designed to run as a jobstep expects a parameter list whose >> first word points to a halfword length field followed by a character >> string of that length. The Initiator will always flag the first word >> with an end-of-list bit. So if the program follows normal rules, you >> can't pass it an address that way. > >Why can't the character string contain eg the eight character hex >representation of a 4-byte address, which the program converts back to >binary and tries to pass control to? > In fact, that character string could be any four octets comprising a legitimate AMODE 31 address. -- gil -- 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: AUTHPGM in IKJTSOxx
With respect to the part about making other parts of TSO non-dispatchable, I think this is achieved through some parameters on a STATUS macro. TSO runs two TMP TCBs. The first executes commands which do not require APF authorisation. The second executes those requested to run with APF authorisation (i.e. in the AUTHPGM, AUTHCMD or AUTHTSF lists) or any program invoked by TSOEXEC. ISPF runs without authorisation but examines the AUTHxxx lists to determine whether to invoke the program via TSOEXEC. TSOEXEC passes the program to the APF-authorised TCB which stops other TCBS in the address space so that they cannot alter the environment while the authorised program is running. The bit TCBAREQ in byte TCBNDSP3 is set by the STATUS macro. I vaguely remember that there is an undocumented parameter of STATSU for this, but I am not on a z/OS system at the moment so I cannot check. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: 16 November 2019 19:30 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] AUTHPGM in IKJTSOxx On Sat, 16 Nov 2019 17:20:31 +, Leonardo Vaz wrote: >Thanks for the input. Peter said something about making sure non authorized >units of work are non dispatchable while the authorized program runs, is this >something the authorized program added to AUTHPGM has to do or something that >TSO does? If it is something that TSO already does, then why limit TSO to only >run authorized programs on the AUTHPGM list? What is the harm of allowing any >authorized programs as long as they don’t violate system integrity. > >I’m still curious. > Me, too. (The scope of the quantifier "only" is confusing.) >> On Nov 16, 2019, at 11:43 AM, retired mainframer wrote: >> .. >> If it is in an authorized library, it needs to take the exact same >> precautions any other homegrown program that runs authorized would need to >> take. When you authorize any program, you are trusting it not to violate >> your system's integrity. How it earns that trust varies from site to site >> but I expect most have additional requirements above and beyond normal >> release procedures. >> Do those precautions exceed those required for JCL //STEP EXEC PGM=HOMEGROWN? >>> -Original Message- >>> From: Leonardo Vaz >>> Sent: Saturday, November 16, 2019 7:30 AM >>> >>> I am curious now, does a custom homegrown program have to take extra >>> precautions to be placed under AUTHPGM? What would those be? >>> At one point, wanting to invoke GIMSMP via ssh with: /* Rexx exec1*/ address TSO "exec exec2" ... /* Rexx exec2 */ "ALLOCATE ..." ... "call *(GIMSMP) ..." ... I needed to have my sysprog add GIMSMP to AUTHPGM. He did so. Did this create a hazard? Which? (After circa 2010, I needed also to be added to a RACF profile to avoid some ineffable hazard. IBM representatives have provided no further guidance beyond "Be careful!". I take that to mean, "If something breaks, it's on you, and we still won't tell you what you did wrong.") -- gil -- 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: Mainframe environment on AWS
Bill, Is there a support forum for zPDT and/or zD? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Ogden Sent: 10 October 2019 15:15 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Mainframe environment on AWS > I'm new to z/OS in X86. What's the difference between zPDT and ZD? > The documentation I could find is not clear. > Looks like something that might be useful in the shop where I'm currently See IBM publication SG24-8205-04 for a detailed discussion. In short, the terms and conditions (and sales plans) are completely different, but the actual emulation program and functions are the same, with very slight differences. zPDT (for ISVs) includes z/VM and z/VSE, whereas z/VM is an extra feature for zD They use different tokens (IBM types 1090 and 1091); software-only licenses are only for zD Very minor differences. Unless you are an ISV, a member of the IBM Partnerworld, and eligible for the z Systems developer discount program, your path would be to zD Bill Ogden -- 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: SMF exit IEFU086 work area size
David, I guess you will use a mapping for your work area in your program. So you can always have code which compares the length needed with the length available. I just don't know what you do when your needs are greater than they supply! Issue a message? Yes, but how many messages will you get? (Ans: Millions!) Give up without a message? Not very useful at all. Assuming this is a dynamic exit, you could issue a message and then deactivate the exit. None of these is very satisfactory. I suspect the length is always the same, but IBM reserve the right to increase it. Come on IBM. Give us the answer! Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Crayford Sent: 08 October 2019 14:22 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] SMF exit IEFU086 work area size Thank you Lennie, You make some very good observations. I think the salient point of the work area is so the exit routine doesn't need to allocate any storage for obvious reasons (performance). I'm leery of using an exit with a work area without knowing it's length! On 2019-10-08 9:13 PM, Lennie Dymoke-Bradshaw wrote: > When I look in the System Exits manual I see a structure passed as a > parameter list which has an offset to the work area, and a length specified > for it. Assuming the length is specified in bytes it must fit in a halfword. > So max would be 65536 bytes. > > I agree it would be sensible for IBM to give an indication of how much there > is. Without that one could be reduced to getting ones own work area . > > Can you dump out the parameter list to see what is passed? Can we have any > indication from IBM of a minimum size? > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd -- 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: SMF exit IEFU086 work area size
When I look in the System Exits manual I see a structure passed as a parameter list which has an offset to the work area, and a length specified for it. Assuming the length is specified in bytes it must fit in a halfword. So max would be 65536 bytes. I agree it would be sensible for IBM to give an indication of how much there is. Without that one could be reduced to getting ones own work area . Can you dump out the parameter list to see what is passed? Can we have any indication from IBM of a minimum size? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Crayford Sent: 08 October 2019 13:52 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] SMF exit IEFU086 work area size z/OS 2.3 introduced the new IEFU086 SMF exit which is passed a work area which is great. I can't find any documentation in KC on how to customize the size of the workarea in SMPRMxx or what the minimum size of the area is. Can anybody shed any light on this? -- 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: IBM SSI Function Codes 16 and 17
Have you looked at exit IFG0EX0B ? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: 05 October 2019 01:38 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] IBM SSI Function Codes 16 and 17 SSI will not do it. SMF 14/15 is indeed CLOSE time only. SMF 62 will give you the OPEN for a VSAM dataset. SMF 92/10 will give you the OPEN for a UNIX file. You could consider RACF auditing and SMF 80 (230 for ACF2). (All of the "SMF" answers assume the use IEFU8x exits.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lionel B Dyck Sent: Friday, October 4, 2019 12:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IBM SSI Function Codes 16 and 17 Thank you but subsystem datasets are not what I was looking for - my goal is to capture the date/time a data set is opened and the date/time a data set is closed. SMF will give the close time but I've found nothing that will give me the open time. -- 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: LPA - IPL or dynamic
Peter, I think it depends entirely on how the product is installed. The various methods required might include, 1. LPA modules 2. Nucleus extensions 3. SVC(s) 4. New APF libraries 5. New linklist libraries 6. PPT modifications 7. Front-ending of existing SVCs 8. Console definition modifictions 9. Sub-system defintions ...and many other types of changes to system libraries or definitions. Each site will have standards about whether they allow such changes in-flight, or require an IPL. There are benefits with the IPL method. One is that you prove the system configuration. You might also wish to consider that installing on one system is fine, but then the product may need to be activated on another LPAR in the Sysplex. Often however, the system initialisation changes can be mode for the first install and then library updates can be performed for an update. Hope that helps. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Sent: 16 September 2019 18:54 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] LPA - IPL or dynamic Hi I have seen few vendors suggesting an IPL as requisite if you are doing the product install for first time and If it's upgrade then it's not required. I am ignorant here. How does this makes a difference ? Why a dynamic update won't work if it's a first install ? Programmatically how does it work from zOS perspective. Apology if this question was already discussed here if so please point me to the discussion link . Regards Peter -- 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: Submitting batch if you don't have TSO
If users are able to specify userid and password in the JCL built by a CICS transaction you can still use JESJOBS profiles to selectively allow or disallow them based on the userid and/or the jobname. RDEFINE JESJOBS SUBMIT.nodename.jobname.userid UACC(NONE) So to disallow jobs on all userids (even if the password is included) build, SUBMIT.nodename.*.* Then to allow job JOBNAME1 to be submitted under USER1 construct, SUBMIT.nodename.JOBNAME1.USER1 And grant access to your CICS region userid. You can also define a SURROGAT profile to allow submission without a password. Use of PROPCNTL is a hard rule. It stops ALL security propagation, but not all job submission. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: 10 September 2019 22:05 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Submitting batch if you don't have TSO That's the same as any other address space. If you don't have a userid on the job, or specify *, then the job inherits from the submitting address space. If you have a userid and password, the password must be valid. If you have proxy authority, you don't need a password on the JOB statement. If you have a CICS transaction that let's the user submit a job without a userid, then that job will run with the full authority of the CICS userid. Your kindly security auditor may not be pleased. The same applies to any other multi-user address space; if you let your users submit jobs, put in appropriate controls. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of ITschak Mugzach Sent: Tuesday, September 10, 2019 3:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Submitting batch if you don't have TSO Seymour, The exception is CICS. If you write to the internal read you don't need to specify user in the jobcard. This cics attribute is controlled by propcntl class. ITschak בתאריך יום ג׳, 10 בספט׳ 2019, 20:08, מאת Seymour J Metz : > Any user who can submit a job can submit a job with USER=. For that > job to run he needs to either include the password for that userid of > have surrogate authority to it. > > I he is submitting jobs with a password than there is a risk that he > will compromise that password; surrogate authority is a much safer way > to enable the submissions. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Discussion List on > behalf of Jantje. > Sent: Tuesday, September 10, 2019 7:04 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Submitting batch if you don't have TSO > > On Wed, 4 Sep 2019 14:06:21 -0400, Bob Bridges > wrote: > > >Not sure where to ask this, > Here is fine... > > > So, I've read the whole thread and unless I am missing something, I > don't think you run any more risk than what you would have if none of > your users have a TSO segment. > > As others have pointed out, the USER= is superfluous, because, > by default, when CICS submits the job it is with that userID anyway. > > Then, yes, there are tons of ways to get a job into the system, but > submitting JCL from TSO in se will not allow any user to submit that > job as the CICS region userID. Unless of course your security set-up > allows uncontrolled usage of the USER= clause on the job card. > > For any mere mortal to submit a job with a USER= on the job card, your > security package (TSS in your case, RACF in mine) will have to be > instructed to allow that particular mortal to do so. SURROGAT does > indeed cover your fear. Set a (very) generic profile that forbids any > surrogate user and then set specific profiles to grant the access to > only those that actually need it. > > Apart from that, I would recommend to use the USER= clause on the job > card of the jobs that are submitted by your CICS regions, but then to > specify a DIFFERENT user ID than that of the region. Give the CICS > region user ID (and nobody else) SURROGATE on this other user ID. > > O, and, yes, I would worry about what JCL can be submitted from CICS, > but I understand that is under control in your installation (the > assembler program, you spoke about). > > > Very best regards, > > Jantje. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -
Re: APAR OA56180 / RUCSA
Tom, Please examine, http://publibz.boulder.ibm.com/zoslib/pdf/OA56180.pdf The above document states that the SAF access is required both to obtain and to access the storage. I suspect some tricky work around the segment and paging tables has been used to achieve this. Hence the 1M granularity. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: 10 September 2019 15:27 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] APAR OA56180 / RUCSA On Tue, 10 Sep 2019 09:54:43 +0200, Martin Packer wrote: >If you are enabled to use User-Key CSA via RUCSA I believe you "have a >ticket to THE party", the ONE AND ONLY party. Meaning you can access >other users' allocations of User Key CSA. If I understand it correctly, anyone can access RUCSA storage once someone obtains it. The limitation is on who can issue GETMAIN (or STORAGE OBTAIN) for user key CSA. -- Tom Marchant -- 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: Submitting batch if you don't have TSO
Bob, I think ITschak's words are good advice. However, I am concerned at your statement, "The problem, of course, is that if I'm authorized to submit jobs with USER= on the JOB card then I can submit ~any~ such job, to do anything I want that the region can do." The CICS transaction runs under the security context of the region userid. Are the CICS users explicitly authorised to do job submission? Are security checks made against the requester of the CICS transaction? Is the CICS user involved at all? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of ITschak Mugzach Sent: 04 September 2019 19:33 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Submitting batch if you don't have TSO Bob, few comments: 1. You don't need to specify user= in the job card. any job submitted under CICS without propagation control, will be assigned the CICS userid. 2. can cics end users manipulate the jcl they are submitting or it is just submitted by the transaction? I hope they can't! 3. You can control this facility with the PROPCNTL resource class class (all esms). 4. If STIG framework is of relevant to you organization, submitting jobs under the CICS user-id is a medium level risk. 5. management forgot to mention "currently". what happens when a CICS user will be assigned a TSO segment? 6. FTP is a potential security risk, however, the end-user must have an OMVS segment. go guess who has one and why. 7. You don't leave open doors. Someone may use it to enter in. (see the swiss cheese model). ITschak On Wed, Sep 4, 2019 at 9:06 PM Bob Bridges wrote: > Not sure where to ask this, but I've wondered about it off and on for > a while and it's past time I asked. I'm responsible for security at a > mainframe shop where they use a lot of CICS. There are CICS > transactions that fire off batch jobs; the way this place handles it > is to submit the job under the authority of the CICS region ID > (USER= on the JOB card), and give each user of such a transaction the > necessary authority. > > This gives me the screaming heeby-jeebies, but when I complain about > it I get little support back. The problem, of course, is that if I'm > authorized to submit jobs with USER= on the JOB card then I > can submit ~any~ such job, to do anything I want that the region can > do. (And of course any installation that's careless about letting > folks have that authority is even more careless about what their CICS > regions can do.) > > One argument management offers in mitigation is that most of these > CICS users don't have TSO, so they haven't the ability to submit batch jobs. > Off-hand I can't contradict them, but I'm skeptical. I'm thinking > there's probably a way and I just don't know about it. Can anyone > confirm? If I were a CICS user without the ability to log on to TSO, > could I still submit a batch job somehow? > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* You know you've had too much coffee when > Juan Valdez names his donkey after you. > You've worn out the handle on your favorite coffee mug. > Your eyes stay open when you sneeze. */ > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for Legacy **| * -- 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] zOS GENCERT
Exporting the private key is only possible if the keys is NOT stored in the PKDS. So the certificate would have been defined without using the PKDS, ICSF and PCICC options in RACDCERT. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Sankaranarayanan, Vignesh Sent: 28 August 2019 19:45 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] [EXTERNAL] zOS GENCERT Hi Joel, Yes, by exporting it to a dataset, PKCS12DER or PKCS12B64. Make sure you set a password when you export. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.icha400/le-export.htm – Vignesh Mainframe Infrastructure -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joel M Ivey Sent: 28 August 2019 17:32 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] zOS GENCERT In zOS, is it possible to extract a private key, making it viewable by a human, generated by the RACF RACDCERT GENCERT command? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN MARKSANDSPENCER.COM Unless otherwise stated above: Marks and Spencer plc Registered Office: Waterside House 35 North Wharf Road London W2 1NW Registered No. 214436 in England and Wales. Telephone (020) 7935 4422 Facsimile (020) 7487 2670 www.marksandspencer.com Please note that electronic mail may be monitored. This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful. -- 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: Mainframes testing
Timothy, I don't particularly want to get into any argument about this. I was asked for an opinion on the paper and replied with my immediate reactions. I see no reason to change those statements. As another ex-IBMer suggested to me, the paper appears to be a marketing paper and not aimed at technicians. The author also made some statements that I did not understand (and which I think others do not understand). Those statements indicated a lack of knowledge of the subject matter. I am well aware that mainframes run Linux and that z/OS includes USS. When I was employed by IBM I saw several marketing papers on various subjects that contained errors or inaccuracies. (A recent example is that I have seen statements that z/OS can encrypt ALL the data on z/OS systems.) IBM marketing makes claims from time to time that are either untrue or "stretch the truth". I have rarely succeeded in getting such documents changed. Sadly, this paper taught me nothing. That is not to say it has no value. I accept it was probably not intended for me or other z/OS technicians. Maybe I should have stated that in my first post on the paper. (Opinions expressed are my own and do not represent RSM). Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Timothy Sipples Sent: 15 August 2019 04:35 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Mainframes testing Lennie Dymoke-Bradshaw wrote: >The IBM paper reads as if it has been written by someone with >relatively little System z knowledge. You seem to be assuming that mainframes don't run Linux and aren't UNIX(TM) servers. If so, that's not a reasonable assumption. I agree with Charles Mills. As an analogy, it's still possible to find useful, basic (at least) information about cancer without reading a dozen peer reviewed articles published in the New England Journal of Medicine, The Lancet, and The Journal of the American Medical Association. 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframes testing
It would nice to think that IBM could comment on their own platform with a little more authority and accuracy. After all System z income has sustained IBM over the last 25 years. Without the enormous annuity income from their System z customers IBM would have gone down the tubes years ago. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Aled Hughes Sent: 13 August 2019 13:54 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Mainframes testing You and me both Lennie "Abby is a seasoned marketing and public relations professional." Reminds me that a journalist called Ruth Sunderland was on the radio the other day stating that the airline British Airways (after a failure) "is riddled with old systems that have been in place for many years and have become creaky and inefficient. Replacing them without major disruptions is a Herculean job." She even stated that 'mainframes' were to blame for the 2018 TSB fiasco. As someone recently said, "We have a dearth of experts commenting on the mainframe world, without knowing anything about mainframes." ALH -----Original Message- From: Lennie Dymoke-Bradshaw To: IBM-MAIN Sent: Tue, 13 Aug 2019 10:29 Subject: Re: Mainframes testing Filip, The IBM paper reads as if it has been written by someone with relatively little System z knowledge. " There can also be security flaws created during the set-up of permissions for libraries. Libraries are modules for coding. They call into the code and should only be accessed by people who have the highest level of permission." I am not even sure what the above means. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Filip Palian Sent: 13 August 2019 02:17 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] Mainframes testing Hey List, This can be of interest to some: - https://securityintelligence.com/posts/top-five-security-focus-areas-for-mainframes/ - https://www.ibm.com/downloads/cas/A9NKZ8WE Any thoughts/comments? Thanks, Filip -- 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: Mainframes testing
Filip, The IBM paper reads as if it has been written by someone with relatively little System z knowledge. " There can also be security flaws created during the set-up of permissions for libraries. Libraries are modules for coding. They call into the code and should only be accessed by people who have the highest level of permission." I am not even sure what the above means. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Filip Palian Sent: 13 August 2019 02:17 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] Mainframes testing Hey List, This can be of interest to some: - https://securityintelligence.com/posts/top-five-security-focus-areas-for-mainframes/ - https://www.ibm.com/downloads/cas/A9NKZ8WE Any thoughts/comments? Thanks, Filip -- 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: ISPF Question - browsing variable length records
I am trying to imagine what a variable length punched card looks like. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: 09 August 2019 18:59 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] ISPF Question - browsing variable length records Il va sans dire. The point remains that for file types with no wird-in restrictions on line length, F is an abomination and only VB is user friendly. IBM's decision to not distributed CLIST and REXX routines in VB is unfortunate. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Mike Schwab Sent: Friday, August 9, 2019 1:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Question - browsing variable length records Well, the editor saves changes in progress to a temporary file every time you press enter. When you exit and save the changes, the temporary file is copied over the existing PS VB file or STOWed at the end of the PDS or somewhere inside the PDSe. On Fri, Aug 9, 2019 at 11:21 AM Seymour J Metz wrote: > > And I thought that the Devil invented FB for storing, e.g., CLIST, PLI, > REXX, SCRIPT. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on > behalf of Paul Gilmartin > <000433f07816-dmarc-requ...@listserv.ua.edu> > Sent: Thursday, August 8, 2019 3:56 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: ISPF Question - browsing variable length records > > On Thu, 8 Aug 2019 15:08:09 -0400, Tom Conley wrote: > > > >PRESERVE ON/OFF controls what the editor does with trailing blanks in > >a VB record. PRESERVE ON will preserve any REAL trailing blanks > >(based on RDW), PRESERVE OFF will truncate any trailing blanks. I'm > >good with PRESERVE OFF. Isn't that why God invented VB? > > > I thought the Devil invented VB. > > OK, but how can I append trailing blanks to a record in an existing > file, as I can with any good desktop editor, or even a poor one such as > Notepad? > > And with PRESERVE ON, if I insert characters in a line containing > trailing blanks it truncates trailing blanks equal to the characters I > inserted. > PRESERVE ON doesn't "preserve any REAL trailing blanks"; rather, it > attempts to preserve the RDW. > > I wonder what the RFE resulting in PRESERVE asked for? > > I know neither the history nor the internals, but I suspect that an > early predecessor of ISPF Edit supported only RECFM=FB, and when the > RFE for VB support appeared, indolent developers chose to pad records > to fixed length on input to avoid most changes to existing code, and > assume they could repair the damage by stripping trailing blanks on output. > > -- gil > > -- > 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 -- 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 -- 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: CPU time cost of dynamic allocation
Which simply means that if UNIT and VOLUME are not supplied then it looks in the catalog, where it detects a MIGRAT value if the data set is migrated. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: 07 August 2019 21:15 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] CPU time cost of dynamic allocation On Wed, 7 Aug 2019 16:25:52 +, Seymour J Metz wrote: >The Initiator does not check that the data set exists; ... > ... and yet it checks for whether it's migrated. -- gil -- 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: CPU time cost of dynamic allocation
Greg, I think you'll find that whether SVC 99 checks that a data set exists on disk or not depends on the text units used. If I want the 'does data set exist' check made I usually include the text unit to return data set organisation (DALRTORG). This ensures that the DSCB for the data set is read, thus generating an error if it does not exist. However, if I leave this text unit off the dynamic allocation then I can allocate the equivalent of the DD statement you quoted, and subsequently generate a 213-04 abend at OPEN time. However, I think standard TSO ALLOCATE does perform that check, so perhaps it too uses that same text unit. In my understanding step allocation performs the same checks, based on the DD statement keywords you specify. However, some of the text units used in dynamic allocation have no equivalent in the DD statement. See Table 87 on page 692 in MVS Programming: Authorized Assembler Services Guide - SA23-1371-30 for the z/OS 2.3 version. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Greg Price Sent: 07 August 2019 03:00 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] CPU time cost of dynamic allocation On 2019-08-07 5:08 AM, Carmen Vitullo wrote: > I suspect dynamic allocation may be doing more that the IEFBR14 possibly? Well, DYNALLOC is certainly doing more that the job step initiation when it comes to allocation. Device allocation at step-start time is a largely CPU-bound affair with the only I/O usually being for catalog look-ups. That is why something like //MY DD DD DSN=FRED,DISP=OLD,UNIT=3390,VOL=SER=MYVOL1 will get a S213-04 at OPEN time when FRED does not exist. DYNALLOC will check that FRED exists on the volume - yes! it does "lots" of I/O to the data set's volume which batch device allocation does not perform. Data set name enqueue is done before device allocation, and most of it is done at job start time for data sets mentioned in JCL. DYNALLOC has to do the ENQ when it is called before looking at devices. Cheers, Greg -- 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?
Andrew, Yes, from that same z/OS LPAR (or another in the same Sysplex), access to the keys via a RACF resource is also needed. In order to access those keys one would need to use ICSF and the Crypto Express devices that hold the master keys for that domain/LPAR. So if another operating system (such as Linux) can work the interfaces to the Crypto Express and access the VSAM CKDS then they could gain access to the same services that ICSF uses. It would need to be IPLed into the exact same configuration as the z/OS system. It would need some work, but I guess it is possible in theory. Access to the ICSF CKDS would not be enough, as the keys held there are encrypted (wrapped) using the master key. The master key is held in the Crypto Express domain corresponding to the LPAR in question. There is no interface to extract the master key from the Crypto Express device. The Crypto Express device is a FIPS 140-2 level 4 device so it will resist all sorts of attempts to get at the master keys. It will destroy those keys before you can get them out. So the only thing that can be done is to use the interfaces the Crypto Express supplies to perform decryption of the data. The simplest way to achieve all this is to have another z/OS system which can be IPLed into that LPAR which has a rather more open set of RACF controls. So I think physical access to the z processor would be required. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Andrew Rowley Sent: 06 August 2019 12:11 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Pervasive Encryption - why? On 5/08/2019 3:08 pm, Timothy Sipples wrote: > 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. Isn't RACF also required to protect the keys? What stops something else IPLed on the system from accessing the keys using the same interfaces z/OS uses? Andrew Rowley -- 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?
Phil Smith said, " It's also platform-specific, so when data has to be moved across platforms, it must be decrypted and (hopefully!) re-encrypted, which is both expensive and risky: those egress points provide huge attack surface." Why do you think this is platform specific? The AES encryption keys involved can be managed by an external key manager, (such as EKMF) and so those keys can be securely deployed to other (secured) platforms. The encrypted data can be read and then be sent to another platform and decrypted using the original encryption keys. Maybe I have misunderstood what you mean by "platform-specific". Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Phil Smith III Sent: 05 August 2019 17:07 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Pervasive Encryption - why? Cameron Conacher asked about the value of PE, and various folks provided good answers. (Note that I'm using the "Pervasive Encryption" term in the sense that IBM did when it was first introduced: the whole-data set encryption on z/OS. More recently they've expanded it to mean the entire IBM encryption strategy, which is still developing and not particularly integrated yet; Cameron's question seemed to be entirely about the former, as were the replies.) I'd add to those replies that this kind of "transparent" encryption is obviously appealing because of its ease of implementation and low overhead, but that beyond the specific use cases cited, it provides very little protection. While the SAF-level control provides a semblance of role-based access, it doesn't really, because it's not granular: there's no control within a data set. And that also means there's no real opportunity to alert on or throttle access based on usage patterns (UBA/UEBA <https://en.wikipedia.org/wiki/User_behavior_analytics/> ). It's also platform-specific, so when data has to be moved across platforms, it must be decrypted and (hopefully!) re-encrypted, which is both expensive and risky: those egress points provide huge attack surface. GDPR and friends are all nascent in their interpretation. I find it very difficult to believe that one/three/five/whatever years from now, any of them will accept transparent encryption as an acceptable means of data protection, for the reasons above. PCI DSS (which is far more mature) has made it clear that transparent encryption is not the answer, and the security community agrees. Note that I'm not suggesting that PE is useless, just that it's at best a partial solution. "We encrypted something" is not the same as "We're securing stuff". The strongest encryption is field-level, application-level encryption. If it's also format-preserving, then you can also have cross-platform protection without having to decrypt/re-encrypt at the boundary. That's a pretty big win, for a number of reasons. Disclosure: I've spent the last 11½ years on such a product, at Voltage and then HP/HPE/Micro Focus after acquisition. So I'm not exactly un-biased. When considering encryption, the question I'd ask myself is, "Do I feel lucky?" no, wait, that's wrong. I mean, "What are the real threats I'm concerned about?" Is it someone stealing a backup? Stealing a disk from an array? Sniffing the data on the wire between the array and the CEC? A rogue storage admin? Yay, PE will solve those. An actual breach? A rogue employee besides a storage admin? Data that gets copied to the distributed world without proper protection? PE won't help with any of those, I'm afraid. Cameron also noted: >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? This is a trenchant observation. If you look at any attack scenarios besides the ones cited (backups [who doesn't have encrypting tape already??], physical media theft [again, who doesn't have encrypting arrays?], sniffing the data on the wire [the original goal of PE], or a rogue storage admin [another real benefit, albeit one I doubt many folks were losing sleep over]), the encryption really isn't adding anything beyond a second SAF resource protecting the data. In other words, in those scenarios, the encryption is basically irrelevant: either you can read the data set (in which case you get it unencrypted) or you cannot. Same as any other SAF use case. My biggest concern about PE is that folks hear "encryption" and go "yay, we do this and we're protected AND compliant". And the reality is that you mostly aren't. -- ...phsiii Phil Sm
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: Dataset encryption question
Using RACF multi-level security will enable you to do this. See Chapter 5 of the RACF Security Administrators manual, SA23-2289-30. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Jacobs Sent: 28 June 2019 12:39 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] Dataset encryption question Outside of using dataset conditional access rules is there anyway to prevent someone from copying encrypted dataset HLQ1.data to HLQ2.data? They have access rights to both HLQ's and the encryption key. Mark Jacobs Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.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: WTO for message that will require explicit deletion?
Charles, In addition to reading about WTO, I would recommend reading the manual, SA38-0666-30 MVS System Commands, Chapter 3. This tells you about how MVS consoles can be configured. See Chapter 3. Also look at the CONTROL command in chapter 4. Some clues, . Consoles can be in different modes, e.g. Roll or Roll-deletable. . Consoles screens can be divided into different areas. . The MVS command CONTROL (or K) controls all these functions. . If you enter K commands without parameters on a console the current values are reflected into the command area, so they can be modified. (Not sure if this is true for all K commands, but works for K A for areas, and K S which controls the mode of operation. I agree with the suggestion of getting access to an SMCS console to improve your understanding. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: 27 June 2019 00:07 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] WTO for message that will require explicit deletion? Okay, anyone have any clues as to how to align the stars? My "console" experience is with SDSF LOG, not a real console, so my perception of where messages hang is a little skewed I guess. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Wednesday, June 26, 2019 3:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WTO for message that will require explicit deletion? Non-rolling (no delete) messages do not hang 'at the bottom'. They hang as high as they can based on any other non-rolling messages that preceded them. A non-rolling message that stays toward the bottom is there only because a lot of other non-rolling messages are preventing it from rolling higher. Getting the attributes right for a non-rolling message can be tricky, including the status of the task that issued it. If the stars are aligned, a message can 'stay on the screen' indefinitely as long as console mode is RD and the task that issued it is still active. -- 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: VTOC reading
Rather than do BSAM reads I think it is better to make use of the CVAF macros. These make use of the VTOC Index to assist processing. This will present you the data set names in alphabetical order. If you are processing each DSN within the VTOC, you may need to make direct reads of records due to the pointers from one DSCB to another. CVAFSEQ reads records sequentially. CVAFDIR reads records directly. CVAFDSM maps the VTOC and gives you various statistics. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of svet...@ameritech.net Sent: 13 June 2019 17:40 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] VTOC reading Are used to do it in programs a while ago. First do a dynamic allocate Specifying a DS name of 44 characters of hex 04 for 44 characters and specify the valves there that you want. There is a mapping macro that describes each record that you can use. Do an open a read or a get as appropriate. Then your normal close. I can find an example late tonight if you care. Sent from my iPhone > On Jun 13, 2019, at 11:44, Bill Ogden wrote: > > My old memory is failing in too many areas. Long ago, I seem to > recall, there was an easy way to read a VTOC with simple JCL using a "magic" > DSNAME - obviously not 040404... for JCL, but some other name. Is > my memory correct? What is the DSNAME? While playing with google I > cannot find anything, but I might be using the wrong search words. > > Bill Ogden > > > -- > 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: Just how secure are mainframes? | Trevor Eddolls
Just maybe, they are the ones who understand the problems, as they spend time focussed on them. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: 04 June 2019 14:09 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls It’s a little more than coincidence that 3 of the most vociferous posters who claim the mainframe is not secure, all sell mainframe security services. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 8:59 AM, ITschak Mugzach wrote: Lennie, You are inviting 'he tries to sell his product / services' ... ITschak On Tue, Jun 4, 2019 at 3:45 PM Lennie Dymoke-Bradshaw < lenni...@rsmpartners.com> wrote: > Bill, > > It is very difficult to prove the negative. Hence, your claim that > your system has never been hacked is difficult to prove. I think it is > possible that your system has been "hacked" and your data has been > exfiltrated. > There is no reason for the hacker to call attention to that fact that > you have been hacked. > > However, by maintaining that you have not been hacked, and also > maintaining that it is very unlikely that you would ever be hacked, I > fear you are doing your employers a disservice. > > Actually, I work through RSM partners as an independent contractor. > Yes, they sell security services. Yes, I am sometimes called upon to > deliver such services. Nothing to hide here. Most people have to work for a > living. > I imagine you do too. Just because one works in an industry does not > mean one's opinion of the industry is invalid; in fact, the opposite > is frequently true. > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > Web: www.rsmpartners.com > ‘Dance like no one is watching. Encrypt like everyone is.’ > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Bill Johnson > Sent: 04 June 2019 12:37 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor > Eddolls > > How do you demonstrate something that hasn’t happened? LOL I see your > company sells security services too. > > > Sent from Yahoo Mail for iPhone > > > On Tuesday, June 4, 2019, 5:59 AM, Lennie Dymoke-Bradshaw < > lenni...@rsmpartners.com> wrote: > > How do you demonstrate that you have never been hacked? > > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd > Web: www.rsmpartners.com > ‘Dance like no one is watching. Encrypt like everyone is.’ > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Bill Johnson > Sent: 04 June 2019 01:04 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor > Eddolls > > 40 years on numerous mainframes at more than a dozen companies and > we’ve never been hacked and never had any need for penetration testing. > > > Sent from Yahoo Mail for iPhone > > > On Monday, June 3, 2019, 11:54 AM, Clark Morris > wrote: > > [Default] On 2 Jun 2019 19:11:41 -0700, in bit.listserv.ibm-main > 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > > >He’s selling plain and simple. So is Mugzak. Some laboratory bs that > >he > will even show you in application code. Then no doubt analyze your > application code for a small (large) fee. Nobody is saying the > mainframe is fool proof. But, it is inherently (by design) more secure > than any other platform. And, a major reason why almost every bank, > insurance company, and major retailers still have them. > >Sent from Yahoo Mail for iPhone > > > As a retired systems programmer whose only computer related > investments are Microsoft, IBM and HPE my belief is that if your > organization's computer system is connected to the Internet (including > from PC's using > TN3270 emulation), your organization is subject to attack. If it does > not have a group or outside organization such as IBM, Trevor's > organization or ITschak's organization doing periodic ongoing > penetration testing, your organization won't know what vulnerabilities > exist. Since I don't know enough about the Unisys mainframes to > comment on how well they can be secured, I can't comment on how secure > they can be made but I do know it is a major effort to take advantage > of all the tools on any system in making it secure and keeping it that > way. If I knew of any major mainframe user that does not continually > check their systems for vulnerabiliti
Re: Just how secure are mainframes? | Trevor Eddolls
Bill, So you have not seen these things. Others have. Please accept their word for this. If you were as rich as Warren Buffet then you could afford to employ others to work out if you need a haircut. Maybe you could teach yourself those skills. Your logic takes us down a path of only taking advice from those who have no experience. Your choice. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: 04 June 2019 13:52 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls In 40 years, I’ve never seen any company I’ve worked for have their mainframe hacked or compromised. Including a bank and multiple insurance companies. Plus, I was in positions to know. I have seen numerous hacks and compromises of non mainframe platforms at those companies. As Warren Buffett says: Never ask your barber if you need a haircut. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 8:44 AM, Lennie Dymoke-Bradshaw wrote: Bill, It is very difficult to prove the negative. Hence, your claim that your system has never been hacked is difficult to prove. I think it is possible that your system has been "hacked" and your data has been exfiltrated. There is no reason for the hacker to call attention to that fact that you have been hacked. However, by maintaining that you have not been hacked, and also maintaining that it is very unlikely that you would ever be hacked, I fear you are doing your employers a disservice. Actually, I work through RSM partners as an independent contractor. Yes, they sell security services. Yes, I am sometimes called upon to deliver such services. Nothing to hide here. Most people have to work for a living. I imagine you do too. Just because one works in an industry does not mean one's opinion of the industry is invalid; in fact, the opposite is frequently true. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: 04 June 2019 12:37 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls How do you demonstrate something that hasn’t happened? LOL I see your company sells security services too. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 5:59 AM, Lennie Dymoke-Bradshaw wrote: How do you demonstrate that you have never been hacked? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: 04 June 2019 01:04 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls 40 years on numerous mainframes at more than a dozen companies and we’ve never been hacked and never had any need for penetration testing. Sent from Yahoo Mail for iPhone On Monday, June 3, 2019, 11:54 AM, Clark Morris wrote: [Default] On 2 Jun 2019 19:11:41 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >He’s selling plain and simple. So is Mugzak. Some laboratory bs that he will >even show you in application code. Then no doubt analyze your application code >for a small (large) fee. Nobody is saying the mainframe is fool proof. But, it >is inherently (by design) more secure than any other platform. And, a major >reason why almost every bank, insurance company, and major retailers still >have them. >Sent from Yahoo Mail for iPhone > As a retired systems programmer whose only computer related investments are Microsoft, IBM and HPE my belief is that if your organization's computer system is connected to the Internet (including from PC's using TN3270 emulation), your organization is subject to attack. If it does not have a group or outside organization such as IBM, Trevor's organization or ITschak's organization doing periodic ongoing penetration testing, your organization won't know what vulnerabilities exist. Since I don't know enough about the Unisys mainframes to comment on how well they can be secured, I can't comment on how secure they can be made but I do know it is a major effort to take advantage of all the tools on any system in making it secure and keeping it that way. If I knew of any major mainframe user that does not continually check their systems for vulnerabilities, I would be tempted to short sell their stock because they probably either have been breached or will be in the near future. Clark Morris > >On Sunday, June 2, 2019, 9
Re: Just how secure are mainframes? | Trevor Eddolls
Bill, It is very difficult to prove the negative. Hence, your claim that your system has never been hacked is difficult to prove. I think it is possible that your system has been "hacked" and your data has been exfiltrated. There is no reason for the hacker to call attention to that fact that you have been hacked. However, by maintaining that you have not been hacked, and also maintaining that it is very unlikely that you would ever be hacked, I fear you are doing your employers a disservice. Actually, I work through RSM partners as an independent contractor. Yes, they sell security services. Yes, I am sometimes called upon to deliver such services. Nothing to hide here. Most people have to work for a living. I imagine you do too. Just because one works in an industry does not mean one's opinion of the industry is invalid; in fact, the opposite is frequently true. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: 04 June 2019 12:37 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls How do you demonstrate something that hasn’t happened? LOL I see your company sells security services too. Sent from Yahoo Mail for iPhone On Tuesday, June 4, 2019, 5:59 AM, Lennie Dymoke-Bradshaw wrote: How do you demonstrate that you have never been hacked? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: 04 June 2019 01:04 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls 40 years on numerous mainframes at more than a dozen companies and we’ve never been hacked and never had any need for penetration testing. Sent from Yahoo Mail for iPhone On Monday, June 3, 2019, 11:54 AM, Clark Morris wrote: [Default] On 2 Jun 2019 19:11:41 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >He’s selling plain and simple. So is Mugzak. Some laboratory bs that he will >even show you in application code. Then no doubt analyze your application code >for a small (large) fee. Nobody is saying the mainframe is fool proof. But, it >is inherently (by design) more secure than any other platform. And, a major >reason why almost every bank, insurance company, and major retailers still >have them. >Sent from Yahoo Mail for iPhone > As a retired systems programmer whose only computer related investments are Microsoft, IBM and HPE my belief is that if your organization's computer system is connected to the Internet (including from PC's using TN3270 emulation), your organization is subject to attack. If it does not have a group or outside organization such as IBM, Trevor's organization or ITschak's organization doing periodic ongoing penetration testing, your organization won't know what vulnerabilities exist. Since I don't know enough about the Unisys mainframes to comment on how well they can be secured, I can't comment on how secure they can be made but I do know it is a major effort to take advantage of all the tools on any system in making it secure and keeping it that way. If I knew of any major mainframe user that does not continually check their systems for vulnerabilities, I would be tempted to short sell their stock because they probably either have been breached or will be in the near future. Clark Morris > >On Sunday, June 2, 2019, 9:57 PM, Clark Morris wrote: > >[Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main >0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > >>He’s trying to sell his company’s security services. Something I thought was >>not allowed on this list. >> >Whether or not he is selling something and I don't read his posts that >way, he is making some valid points. As a retired MVS (I was back in >applications by the time z/OS was available) systems programmer, I am >far more skeptical about the invulnerability of z/OS. It is too easy >to have decades old stuff still in a system in part because people >don't know why it is there or are unaware of its existence. How much >effort is required for an installation to achieve even 95 percent of >the invulnerability that is theoretically possible and keep that up. >How many holes are left in the average shop because people don't >understand the implications of all of both IBM and vendor defaults >where I will almost guarantee that there are at some defaults that >leave a system open to hacking. I think that it is d
Re: Just how secure are mainframes? | Trevor Eddolls
How do you demonstrate that you have never been hacked? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: 04 June 2019 01:04 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Just how secure are mainframes? | Trevor Eddolls 40 years on numerous mainframes at more than a dozen companies and we’ve never been hacked and never had any need for penetration testing. Sent from Yahoo Mail for iPhone On Monday, June 3, 2019, 11:54 AM, Clark Morris wrote: [Default] On 2 Jun 2019 19:11:41 -0700, in bit.listserv.ibm-main 0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: >He’s selling plain and simple. So is Mugzak. Some laboratory bs that he will >even show you in application code. Then no doubt analyze your application code >for a small (large) fee. Nobody is saying the mainframe is fool proof. But, it >is inherently (by design) more secure than any other platform. And, a major >reason why almost every bank, insurance company, and major retailers still >have them. >Sent from Yahoo Mail for iPhone > As a retired systems programmer whose only computer related investments are Microsoft, IBM and HPE my belief is that if your organization's computer system is connected to the Internet (including from PC's using TN3270 emulation), your organization is subject to attack. If it does not have a group or outside organization such as IBM, Trevor's organization or ITschak's organization doing periodic ongoing penetration testing, your organization won't know what vulnerabilities exist. Since I don't know enough about the Unisys mainframes to comment on how well they can be secured, I can't comment on how secure they can be made but I do know it is a major effort to take advantage of all the tools on any system in making it secure and keeping it that way. If I knew of any major mainframe user that does not continually check their systems for vulnerabilities, I would be tempted to short sell their stock because they probably either have been breached or will be in the near future. Clark Morris > >On Sunday, June 2, 2019, 9:57 PM, Clark Morris wrote: > >[Default] On 2 Jun 2019 14:46:41 -0700, in bit.listserv.ibm-main >0047540adefe-dmarc-requ...@listserv.ua.edu (Bill Johnson) wrote: > >>He’s trying to sell his company’s security services. Something I thought was >>not allowed on this list. >> >Whether or not he is selling something and I don't read his posts that >way, he is making some valid points. As a retired MVS (I was back in >applications by the time z/OS was available) systems programmer, I am >far more skeptical about the invulnerability of z/OS. It is too easy >to have decades old stuff still in a system in part because people >don't know why it is there or are unaware of its existence. How much >effort is required for an installation to achieve even 95 percent of >the invulnerability that is theoretically possible and keep that up. >How many holes are left in the average shop because people don't >understand the implications of all of both IBM and vendor defaults >where I will almost guarantee that there are at some defaults that >leave a system open to hacking. I think that it is difficult to >understand all of the implications of an action. Many shops may be >running exits or other systems modifications that have worked for >decades and because they work, no one has checked them to see if they >have an unintended vulnerability. I hope that none of my code that is >on file 432 of the CBT Tape (Philips light mods) has any vulnerability >but the thing that scares me is that I might not be smart enough to >find it even if I was looking for it. Good security isn't cheap. Z/OS >may be the most secure starting base but it requires real effort to >actually implement it with both good security and good usability. How >much vulnerability is there in the test systems? How much are the >systems programmer sandboxes exposed to the outside world? What >uncertainties exist in systems vendor code? Are organizations willing >or able to periodically test their systems' vulnerabilities? Can be >secure does not mean is secure? > >Clark Morris >> >>Sent from Yahoo Mail for iPhone >> >> >>On Sunday, June 2, 2019, 4:04 PM, Seymour J Metz wrote: >> >>> * As part of a APF authorized product there is a SVC or PC routine >>> that when called will turn on the JSBCAUTH bit >> >>Ouch! >> >>If it's APF authorized then why does it need to do that? And why would you >>allow such a vendor in the door? >> >>Di
Re: Fwd: Just how secure are mainframes? | Trevor Eddolls
In addition to defining what is "security" we need to define what we mean by "hacking". In my previous career at IBM I was asked this many times. At that time I preferred to talk of an "attack" on the mainframe, and then determine the susceptibility of the system to that attack. However, I came up with some situations which could be examined to try and get people to define what they mean by "hacking" in this context. The questions I asked were the following. I suspect different folks will come up with different answers for some of these questions. You will soon see, as well where the fault/blame/responsibility for security lies for each of these situations. Anyway, here are the questions I used. 1. If I use a colleague's userid and password without his knowledge, is this hacking? Have I hacked the mainframe? 2. If I trick a mainframe user into divulging his password, and then use this to access data, is this hacking? Have I hacked the mainframe? 3. If I use access I have been given in a manner which it was not designed to be used for (e.g. access to a break-glass userid for recovery), and so gain access to private data, am I hacking? Have I hacked the mainframe? 4. If I am a systems programmer and have legitimate UPDATE access to an APF authorised library, and use it to gain RACF SPECIAL, is this hacking? Have I hacked the mainframe? 5. If I have a basic userid on a z/OS system, and then discover that I can make use of unprotected CSA storage created by a badly coded 3rd party product which uses it for inter-address space communications, and I use this to gain access to data I would not normally have access to, is this hacking? Have I hacked the mainframe? 6. If I discover a bad z/OS configuration option has been used (e.g. IDCAMS in AUTHTSF), and I exploit it to gain access in key zero and then grant my userid RACF SPECIAL, am I hacking? Have I hacked the mainframe? 7. If I gain access to a DB2 userid because its password is hard-coded on a distributed server, and then use it to gain access to DB2 on z/OS, am I hacking? Have I hacked the mainframe? 8. If I discover a z/OS integrity exposure, which should be covered by the z/OS Statement of Integrity, and then make use of it, instead of reporting it to IBM to be resolved, am I hacking? Have I hacked the mainframe? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Vernooij, Kees (ITOP NM) - KLM Sent: 28 May 2019 08:13 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Fwd: Just how secure are mainframes? | Trevor Eddolls Well, it seems 'security' needs to be defined here. Probably like in my answer to Bill: difficulty * result. You are secure enough if you can prevent a hacker to steal $100,= by delaying him for 1 hour. You are not if you can delay him for only one hour to steal a million. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of R.S. > Sent: 28 May, 2019 9:00 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls > > W dniu 2019-05-27 o 17:45, Chad Rikansrud pisze: > > At the risk of re-kicking the already dead horse: Bill, you're > comparing apples and spiders. > > > > Are there fewer mainframe 'hacks'? Yep. There are also > > exponentially > fewer mainframes than Windows / Android / Mac / IOS / Linux. Like - a > few thousand mainframes compared to 2.5 BILLION users of > Windows/Linux/Mac/Android & IOS combined. That is somewhere between > 250,000 - 500,000x more installs of those OS's. And they are freely > available for literally anyone to poke at. > > > > What you're arguing "Because Windows gets hacked daily, and > > mainframes > are never in the news as have being hacked - means that mainframes are > more secure .. more 'hack-proof'" Is like saying that: > > > > -- Homes in Toronto are more hurricane-proof because fewer of them > > are > destroyed than in Key West. > > OR > > -- Babies are better drivers than their parents, because their > > parents > get in accidents every day. > > OR > > -- People in Greenland are less susceptible to cancer because fewer > people die of it than do in the US. > > > > For years people thought Macs were less susceptible to viruses than > their Windows counterparts... because? They never read about Mac hacks. > The reality? There were way fewer Macs. Now? Still much less > marketshare than Windows, but lots of Mac hacks/malware out there > because they have more than doubled their market share in 6-8 years. > > You
Re: PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E
I think my memory is running out now ☹. The experience I had with this was several decades ago. I know that I had a TSO command processor (CP) with STAX protection around a particular piece of code. However, when running under a CLIST I found that the CLIST attention facility gained control instead of getting control passed to the STAX routine in the program. Maybe the behaviour has since changed. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: 21 May 2019 21:41 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E There is a queue for each task, but more than one task can issue STAX. The exit for a subtask get control before the exit for the parent task. Are you thinking of CLSTATTN (sp?) and TOPLEVEL? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw Sent: Tuesday, May 21, 2019 2:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E Yes I did mean at the READY prompt. I think that STAX acts at the TCB level. The CLIST will be running on different TCB from any program that it invokes, as each command is invoked using an ATTACH macro. I have seen situations where the CLIST flushes the stack after the interrupt and so the TCB running the program or command is wiped out. I think there are parameters that are needed on the CLIST to protect against this I think. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: http://secure-web.cisco.com/1I2vgDyDq8crO7fF_Z1a6IDTn6qUZVMPJaFCBAgQytvoOMcN22fc106zIRsjze0QGpC7KMNNGEc7i2yeUG6mAvDZ1ha0YFNn69j-59BhOaiRRbzEQUnAq0Y6_-cwb0DLcR9j8ysUl4jpFiFCzGwIq7P_-eIe5YcwbTePo0cxgLDvokTJ6raAb4W_w7XYxV-D_WgG2mWnnBzEzrotzP9pHAJZ1XTwAQy9FDA7lGTqgFYfw_kfByeF24ve4LBSqEg66JNEbPmuYyJLjCMyvy0mvr4JG2iApjhCBQgdnY5wrDMbCnFooHtfddit1f95zsBDnz0qj9ShN50usZvYkF5qyLFaXEQwiVgTyZthOpKr5l8SZIm6i9fjaVgGLylCUUmu9UhhWV1ZXpGrIZvjb7ot1TysYlVxOXOlTMzYqB8-SNNk/http%3A%2F%2Fwww.rsmpartners.com 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: 21 May 2019 17:27 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E By "native TSO" do you mean the READY prompt? The CLIST processor uses STAX; the override rules are the same as for any other user of STAX. REXX doesn't support attention handling code, but the REXX interpreter does do a STAX and writes a prompt for attention. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw Sent: Tuesday, May 21, 2019 12:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E You may get different results when running the program in a CLIST as opposed to running it from native TSO. I don't know what other mysteries REXX brings to the table. CLIST processing has ATTN handling, which (from memory) overrides the use of STAX (assembler TSO interrupt handling macro) from within a program. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Email:lenni...@rsmpartners.com Web: http://secure-web.cisco.com/1TP7I7bSJ0ibf2dNo3OyTavPh2FXX8KRFSQDk_7sE8ZUtm9-4NfLDadbpNKsXBSwz0hAIF-vGCHbAmhy3jV0wlj9aGRnQw_8EXDpKu7PCLUrGH-Av80gDpRRj4n-xvHNwBOsSKtS09VQh0otEj-GRfej4ivoGKUyf5pLSpPAxbvjkkvTMI8QHeLEstSYbZuytlUBX-1BNqNhXDXs-7ER0u__qEMhUc4b4Ai0FZOPg1r5G4ZpXmVv5Sf_6z_u98MyPbTGqDIm4gbhmgER6qulcl8QumK6HAJZuZ9FX8F9IX5mNuC5_f_40FguhQfCbi7kkpGGLRjnFEccpGZZCLTtdrT-w8B1F0iw9VtwaWZgwMPRxgYb-OlmRi9TLn6DEE3SdpkvkRlFmohV9fTdT9ZdFEqHaMlLC8pgCE3xH8S6q_rtPKPQxhCaELhg2v2WvGK0U/http%3A%2F%2Fwww.rsmpartners.com 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: 20 May 2019 21:17 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E I'd say that the first step is to run a trace and find out what your terminal simulator is actually sending when you click on ATTENTION. Ideally, it will be the aid for PA1, exactly one time, but life is full of surprises. Does your ATTENTION key work as expected with other applications? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Mike Stramba Sent: Monday, May 20, 2019 12:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject
Re: PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E
Yes I did mean at the READY prompt. I think that STAX acts at the TCB level. The CLIST will be running on different TCB from any program that it invokes, as each command is invoked using an ATTACH macro. I have seen situations where the CLIST flushes the stack after the interrupt and so the TCB running the program or command is wiped out. I think there are parameters that are needed on the CLIST to protect against this I think. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: 21 May 2019 17:27 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E By "native TSO" do you mean the READY prompt? The CLIST processor uses STAX; the override rules are the same as for any other user of STAX. REXX doesn't support attention handling code, but the REXX interpreter does do a STAX and writes a prompt for attention. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw Sent: Tuesday, May 21, 2019 12:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E You may get different results when running the program in a CLIST as opposed to running it from native TSO. I don't know what other mysteries REXX brings to the table. CLIST processing has ATTN handling, which (from memory) overrides the use of STAX (assembler TSO interrupt handling macro) from within a program. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Email:lenni...@rsmpartners.com Web: http://secure-web.cisco.com/1TP7I7bSJ0ibf2dNo3OyTavPh2FXX8KRFSQDk_7sE8ZUtm9-4NfLDadbpNKsXBSwz0hAIF-vGCHbAmhy3jV0wlj9aGRnQw_8EXDpKu7PCLUrGH-Av80gDpRRj4n-xvHNwBOsSKtS09VQh0otEj-GRfej4ivoGKUyf5pLSpPAxbvjkkvTMI8QHeLEstSYbZuytlUBX-1BNqNhXDXs-7ER0u__qEMhUc4b4Ai0FZOPg1r5G4ZpXmVv5Sf_6z_u98MyPbTGqDIm4gbhmgER6qulcl8QumK6HAJZuZ9FX8F9IX5mNuC5_f_40FguhQfCbi7kkpGGLRjnFEccpGZZCLTtdrT-w8B1F0iw9VtwaWZgwMPRxgYb-OlmRi9TLn6DEE3SdpkvkRlFmohV9fTdT9ZdFEqHaMlLC8pgCE3xH8S6q_rtPKPQxhCaELhg2v2WvGK0U/http%3A%2F%2Fwww.rsmpartners.com 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: 20 May 2019 21:17 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E I'd say that the first step is to run a trace and find out what your terminal simulator is actually sending when you click on ATTENTION. Ideally, it will be the aid for PA1, exactly one time, but life is full of surprises. Does your ATTENTION key work as expected with other applications? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Mike Stramba Sent: Monday, May 20, 2019 12:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E I'm trying to compile and run the PL/I ON ATTENTION interrupt example from the PLI prog guide ver 4 r4 (pg 542 / GI11-9145-03) The code contains an ON ATTENTION handler with a simple message and prompt : and the main line is a simple endless loop. The goal was just to write an extremely primitive counter-tester, which the user can interrupt after X seconds to see what counting-performance had been achieved. When I run the program and then press my 3270 emulator attention key, the program just ends instead of the attention handler gaining control. The console log shows a SLIP TRAP X33E and X13E were matched. MVS system codes SA38-0665-30 says for 33E : "During processing of a DETACH macro that specified a STAE=YES operand, the system found that the specified subtask had not completed processing" code 13E is : "The task that created a subtask issued a DETACH macro for that subtask, specifying STAE=NO before the subtask ended. I ASSume the "subtask" is my test program ?? And the "task" is TSO ?? Or maybe not :/ How do I just get the ON ATTENTION handler to work ? Mike -- 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...@li
Re: PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E
You may get different results when running the program in a CLIST as opposed to running it from native TSO. I don't know what other mysteries REXX brings to the table. CLIST processing has ATTN handling, which (from memory) overrides the use of STAX (assembler TSO interrupt handling macro) from within a program. 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 Seymour J Metz Sent: 20 May 2019 21:17 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E I'd say that the first step is to run a trace and find out what your terminal simulator is actually sending when you click on ATTENTION. Ideally, it will be the aid for PA1, exactly one time, but life is full of surprises. Does your ATTENTION key work as expected with other applications? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Mike Stramba Sent: Monday, May 20, 2019 12:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E I'm trying to compile and run the PL/I ON ATTENTION interrupt example from the PLI prog guide ver 4 r4 (pg 542 / GI11-9145-03) The code contains an ON ATTENTION handler with a simple message and prompt : and the main line is a simple endless loop. The goal was just to write an extremely primitive counter-tester, which the user can interrupt after X seconds to see what counting-performance had been achieved. When I run the program and then press my 3270 emulator attention key, the program just ends instead of the attention handler gaining control. The console log shows a SLIP TRAP X33E and X13E were matched. MVS system codes SA38-0665-30 says for 33E : "During processing of a DETACH macro that specified a STAE=YES operand, the system found that the specified subtask had not completed processing" code 13E is : "The task that created a subtask issued a DETACH macro for that subtask, specifying STAE=NO before the subtask ended. I ASSume the "subtask" is my test program ?? And the "task" is TSO ?? Or maybe not :/ How do I just get the ON ATTENTION handler to work ? Mike -- 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: Processing Partition organization type record
Fair point. Answer is, I learnt this stuff before they invented DESERV. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: 29 April 2019 23:05 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Processing Partition organization type record > First you open the directory and read and decode the blocks to get the member > names. Why not just us DESERV? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Lennie Dymoke-Bradshaw Sent: Monday, April 29, 2019 5:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Processing Partition organization type record I think one option to tackle this is to have two DD statements. One will be used to read the directory. The other can specify QSAM and can read and process the member using GET and PUTX. (If a member is to be written that is longer than its previous version then you may wish to use a third QSAM DD to use PUT.) First you open the directory and read and decode the blocks to get the member names. This can be done using QSAM. You then use RDJFCB on the second DD to obtain the JFCB and then modify that JFCB to specify each member in turn. Then use OPEN TYPE=J to specify the modified JFCB. Then read and process the member. So processing each member will require an OPENJ and a CLOSE. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: http://secure-web.cisco.com/1PdzwE63lXd_PKHb2WKUtgwEQUeSTsrN-JcCoUAM_eE-8DMuTfEjrdorXZlGxrChAl99A58h7BoN1S4nFJAL5X_Ss-wMOyTDHNsv-dDFcwOCWMvmME6KQS6-ECl5EzeYoNMKLNjuqneKpBsJLtlLpBz50_oHx6zzP1iW0hT_Qcx1E-pQVaXbywskTOIuN6RartAs6DBWzk4MFSoh5fUkBRDZljxg5szo-Xxf1FHrKKlrOW7uy11XyX7jDWeHWpD2smrTxxpeeq77_C6l3OC7xsYEIBTsdxPIy8B8qsaG3XuB70HKVU5d6lQZ3NdI4vJ0o8iEo-ZoLQ5085Z-pgClBwVGeb0egruddKqOl4bXNhZAwC5WmZxgEai7h6NSguCRO8d4XQgxmuetU5UtH9glsNbZjgkWkj6nvlEJOD7ZD7Rxs1V-yJIoEtkD43KRni6TA/http%3A%2F%2Fwww.rsmpartners.com 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: 29 April 2019 13:28 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] Processing Partition organization type record Hi I have to process a DSORG type dataset processing each member I initially do a FIND and go through Each member Seems lime with this access method I have to use READ instead of GET And thus do my own deb locking processing In Rexx I would do the allocate and unallocate and this would use QSAM In Assembler this more difficult with SVC 99 If anybody has any ideas they are willing to share I would appreciate it Thanks -- 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: Processing Partition organization type record
I think one option to tackle this is to have two DD statements. One will be used to read the directory. The other can specify QSAM and can read and process the member using GET and PUTX. (If a member is to be written that is longer than its previous version then you may wish to use a third QSAM DD to use PUT.) First you open the directory and read and decode the blocks to get the member names. This can be done using QSAM. You then use RDJFCB on the second DD to obtain the JFCB and then modify that JFCB to specify each member in turn. Then use OPEN TYPE=J to specify the modified JFCB. Then read and process the member. So processing each member will require an OPENJ and a CLOSE. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com 'Dance like no one is watching. Encrypt like everyone is.' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: 29 April 2019 13:28 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] Processing Partition organization type record Hi I have to process a DSORG type dataset processing each member I initially do a FIND and go through Each member Seems lime with this access method I have to use READ instead of GET And thus do my own deb locking processing In Rexx I would do the allocate and unallocate and this would use QSAM In Assembler this more difficult with SVC 99 If anybody has any ideas they are willing to share I would appreciate it Thanks -- 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: AMODE 32
Another reason for separating CICS workloads is security. CICS transaction separation can only really be achieved through separate address spaces. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: 07 April 2019 07:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] AMODE 32 I dodged the “why multiple CICS regions?” aspect as this thread has already got complex enough. The “CICS topology” topic is wonderfully complex, of course, and it’s one of the things my workshops with customers delve into. I would say “QR TCB Constraint” is still a live issue, but less of one. Certainly lots of things got offloaded to other TCBs, but lots didn’t. I also think Threadsafe plays into this quite a bit. But, to try to bring it back to the OP’s line of thinking a little, I would not consider 31-bit or 42-bit virtual storage to be a frequent issue in CICS estate design. It’s the sort of thing you check for, of course. Your point - “QR TCB Constraint” - is more prevalent. Cheers, Martin Sent from my iPad > On 6 Apr 2019, at 21:19, Joel C. Ewing wrote: > > It used to be, most of a single CICS region other than some > DB2-related work was single threaded. Don't know if that has improved > in the last five years, but am sure there must still be significant parts of > CICS > that are single thread. The only way to give more CPU to a CICS that > was CPU-constrained, required splitting the load to multiple CICS Regions. > > Over the years, the main reasons we used multiple CICS regions under > MVS was for application isolation, downtime isolation, and increased > CPU resources -- not merely because of virtual memory constraints. > > I know some of our application code relies on the VL bit to detect end > of parameter lists. You cannot depend on existing code being trivial > to convert. Like Y2K, it is not that individual fixes are > complicated, but there can be massive amounts of code to review to find where > the fixes > are required. There would inevitably be bugs introduced in both > application code and the OS. Not worth the effort and risk for a > measly doubling of virtual address space. > Joel C. Ewing > >> On 4/5/19 11:43 PM, Mike Schwab wrote: >> Actually, they started under MVS with 8MiB user memory or so. Plus >> splitting different applications into their own regions to isolate, >> close certain partition at specified times for batch and backup >> processing, etc. >> >>> On Fri, Apr 5, 2019 at 11:55 AM Paul Edwards wrote: >>> Hi Mike. >>> >>> I'm trying to understand why some sites are running multiple CICS >>> regions because >>> 2 GiB is not enough. Yet they haven't gone to AM64. I want to know >>> if they would be interested in going to AM32 instead, if it were >>> available. Can you elaborate? If AM32 was more practical for them, >>> they would be able to halve the number of CICS regions they have. >>> >>> BTW, Rob Prins recently updated his >>> 47,000-line RPF assembler program to make it AM32-clean, and it >>> required very little effort. He was using "VL" in a variety of >>> places, but the things he was calling were not actually variable >>> parameter functions, so he just needed to delete the VL. No rewrite >>> was necessary, as would be required if moving to AM64. >>> >>> Thanks. Paul. >>> >>> >>> >>> >>>> On Fri, 5 Apr 2019 02:41:15 -0500, Mike Schwab wrote: >>>> >>>> If you are wanting to run in AM64 and use 32 bit constants, that is >>>> certainly possible. You will then be limited to incrementing >>>> registers by 4GiB or less. Just establishing addressability will >>>> need to set all 64 bits. >>>> >>>>> On Thu, Apr 4, 2019 at 2:40 PM Paul Edwards wrote: >>>>>> On Thu, 4 Apr 2019 19:32:01 +, Martin Packer wrote: >>>>>> >>>>>> They will be (running 64-bit). However, apart from Db2*, much of their >>>>>> virtual storage components can't tolerate being above the bar. >>>>> Which virtual storage components can't tolerate being above the >>>>> bar, and why is that and what would need to change? >>>>> >>>>> Thanks. Paul. >>>>> >>>>> ... >>>>> >>>>> -- >>>>> Mike A Schwab, Springfield IL USA >>>>> Where do Forest Ranger
Re: Extended format datasets
Tom, Thanks. I found this summary only. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/coefsds.htm I am trying to understand what is going on under the covers. I am also trying to understand what programming changes might be needed if a customer is using EXCP rather than a standard access method. I would also like to know what is the difference between the type 1 and type 2 extended data sets. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: 03 April 2019 15:40 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Extended format datasets On Wed, 3 Apr 2019 07:49:31 -0500, Lennie Dymoke-Bradshaw wrote: >Can anyone point me to documentation showing the internal differences between >basic format and extended format datasets? Did you look in DFSMS: Using Data Sets? -- Tom Marchant -- 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
Extended format datasets
Can anyone point me to documentation showing the internal differences between basic format and extended format datasets? Thanks, Lennie Dymoke-Bradshaw -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
