Re: Request for help with removing sequence numbers from PDS members

2021-01-11 Thread Lennie Dymoke-Bradshaw
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

2021-01-11 Thread Lennie Dymoke-Bradshaw
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

2020-12-29 Thread Lennie Dymoke-Bradshaw
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

2020-12-29 Thread Lennie Dymoke-Bradshaw
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?

2020-12-09 Thread Lennie Dymoke-Bradshaw
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?

2020-12-09 Thread Lennie Dymoke-Bradshaw
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]

2020-12-08 Thread Lennie Dymoke-Bradshaw
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

2020-12-03 Thread Lennie Dymoke-Bradshaw
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

2020-12-03 Thread Lennie Dymoke-Bradshaw
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

2020-11-24 Thread Lennie Dymoke-Bradshaw
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

2020-11-20 Thread Lennie Dymoke-Bradshaw
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

2020-11-18 Thread Lennie Dymoke-Bradshaw
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

2020-11-18 Thread Lennie Dymoke-Bradshaw
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?

2020-11-06 Thread Lennie Dymoke-Bradshaw
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

2020-10-26 Thread Lennie Dymoke-Bradshaw
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

2020-10-19 Thread Lennie Dymoke-Bradshaw
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

2020-10-16 Thread Lennie Dymoke-Bradshaw
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

2020-10-16 Thread Lennie Dymoke-Bradshaw
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

2020-10-13 Thread Lennie Dymoke-Bradshaw
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

2020-10-01 Thread Lennie Dymoke-Bradshaw
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

2020-10-01 Thread Lennie Dymoke-Bradshaw
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?

2020-09-17 Thread Lennie Dymoke-Bradshaw
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?

2020-07-28 Thread Lennie Dymoke-Bradshaw
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.

2020-07-27 Thread Lennie Dymoke-Bradshaw
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

2020-07-16 Thread Lennie Dymoke-Bradshaw
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

2020-06-30 Thread Lennie Dymoke-Bradshaw
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

2020-06-25 Thread Lennie Dymoke-Bradshaw
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

2020-05-04 Thread Lennie Dymoke-Bradshaw
> 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;

2020-04-22 Thread Lennie Dymoke-Bradshaw
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

2020-04-21 Thread Lennie Dymoke-Bradshaw
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

2020-04-20 Thread Lennie Dymoke-Bradshaw
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

2020-04-20 Thread Lennie Dymoke-Bradshaw
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

2020-04-20 Thread Lennie Dymoke-Bradshaw
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

2020-04-09 Thread Lennie Dymoke-Bradshaw
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)

2020-04-02 Thread Lennie Dymoke-Bradshaw
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

2020-03-17 Thread Lennie Dymoke-Bradshaw
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

2020-03-17 Thread Lennie Dymoke-Bradshaw
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

2020-03-17 Thread Lennie Dymoke-Bradshaw
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

2020-02-11 Thread Lennie Dymoke-Bradshaw
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

2020-01-16 Thread Lennie Dymoke-Bradshaw
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

2020-01-16 Thread Lennie Dymoke-Bradshaw
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

2020-01-08 Thread Lennie Dymoke-Bradshaw
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

2020-01-05 Thread Lennie Dymoke-Bradshaw
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

2019-12-31 Thread Lennie Dymoke-Bradshaw
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

2019-12-12 Thread Lennie Dymoke-Bradshaw
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 ...)

2019-12-05 Thread Lennie Dymoke-Bradshaw
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

2019-12-05 Thread Lennie Dymoke-Bradshaw
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

2019-12-05 Thread Lennie Dymoke-Bradshaw
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

2019-12-03 Thread Lennie Dymoke-Bradshaw
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 ...

2019-12-03 Thread Lennie Dymoke-Bradshaw
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 ...

2019-12-03 Thread Lennie Dymoke-Bradshaw
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

2019-12-01 Thread Lennie Dymoke-Bradshaw
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

2019-11-29 Thread Lennie Dymoke-Bradshaw
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

2019-11-28 Thread Lennie Dymoke-Bradshaw
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

2019-11-25 Thread Lennie Dymoke-Bradshaw
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

2019-11-17 Thread Lennie Dymoke-Bradshaw
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

2019-10-10 Thread Lennie Dymoke-Bradshaw
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

2019-10-08 Thread Lennie Dymoke-Bradshaw
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

2019-10-08 Thread Lennie Dymoke-Bradshaw
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

2019-10-05 Thread Lennie Dymoke-Bradshaw
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

2019-09-16 Thread Lennie Dymoke-Bradshaw
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

2019-09-10 Thread Lennie Dymoke-Bradshaw
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

2019-09-10 Thread Lennie Dymoke-Bradshaw
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

2019-09-05 Thread Lennie Dymoke-Bradshaw
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

2019-08-28 Thread Lennie Dymoke-Bradshaw
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

2019-08-15 Thread Lennie Dymoke-Bradshaw
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

2019-08-13 Thread Lennie Dymoke-Bradshaw
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

2019-08-13 Thread Lennie Dymoke-Bradshaw
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

2019-08-09 Thread Lennie Dymoke-Bradshaw
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

2019-08-07 Thread Lennie Dymoke-Bradshaw
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

2019-08-07 Thread Lennie Dymoke-Bradshaw
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?

2019-08-06 Thread Lennie Dymoke-Bradshaw
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?

2019-08-05 Thread Lennie Dymoke-Bradshaw
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?

2019-08-04 Thread Lennie Dymoke-Bradshaw
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

2019-06-28 Thread Lennie Dymoke-Bradshaw
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?

2019-06-27 Thread Lennie Dymoke-Bradshaw
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

2019-06-13 Thread Lennie Dymoke-Bradshaw
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

2019-06-04 Thread Lennie Dymoke-Bradshaw
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

2019-06-04 Thread Lennie Dymoke-Bradshaw
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

2019-06-04 Thread Lennie Dymoke-Bradshaw
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

2019-06-04 Thread Lennie Dymoke-Bradshaw
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

2019-05-28 Thread Lennie Dymoke-Bradshaw
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

2019-05-22 Thread Lennie Dymoke-Bradshaw
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

2019-05-21 Thread Lennie Dymoke-Bradshaw
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

2019-05-21 Thread Lennie Dymoke-Bradshaw
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

2019-04-29 Thread Lennie Dymoke-Bradshaw
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

2019-04-29 Thread Lennie Dymoke-Bradshaw
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

2019-04-07 Thread Lennie Dymoke-Bradshaw
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

2019-04-03 Thread Lennie Dymoke-Bradshaw
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

2019-04-03 Thread Lennie Dymoke-Bradshaw
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