Re: ./ ADD - which utility?

2024-04-14 Thread Lennie Bradshaw
Paul Gilmartin said,
>> And no DLM is safe to use with instream XMIT output. <<

True. However, for any given stream there is ahigh likelihood of finding a 2 
char symbols that would work for that stream. I wrote a program to scan files 
to find a suitable delimiter string to use some years back. I've lost it now of 
course!

Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: 14 April 2024 14:04
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ./ ADD - which utility?

On Sat, 13 Apr 2024 20:01:50 -0500, Mike Schwab wrote:

>You can set it up for a //SYSIN DD DATA,DLM='??' and add the
>'??'
>Card at the end.
> 
That's not enough.  If the input PDS contains a member with a line beginning 
with "./", which is likely in JCL with instream data, IEBUPDTE will improperly 
treat it as a command, not data.

A similar problem arises if a data line begins with "??".

And no DLM is safe to use with instream XMIT output.



>On Sat, Apr 13, 2024 at 6:52 PM Paul Gilmartin wrote:
>>
>> On Sun, 14 Apr 2024 08:34:30 +1000, Wayne Bickerdike wrote:
>>
>> >I have some REXX code that extracts all members of a PDS and writes 
>> >it to a sequential file. Each member extracted is prefixed with the 
>> >./ADD card with the original member name. Handy for moving a PDS to another 
>> >system.
>> >IEBUPDTE was the utility of choice when all we had was a card punch 
>> >and card reader. (1975).
>> >
>> Have you just rediscovered IEBPTPCH?
>>
>> How does this work if your input PDS is a JCL library containing some 
>> jobs with IEBUPDTE steps with instream commands?

--
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: ./ ADD - which utility?

2024-04-13 Thread Lennie Bradshaw
Or even (dare I suggest it), by RTFM.
https://www.ibm.com/docs/en/zos/3.1.0?topic=utilities-iebupdte-update-data-set-program
 

Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
ITschak Mugzach
Sent: 13 April 2024 15:40
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ./ ADD - which utility?

IEBUPDTE. JCL can be found in google

ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring for 
z/OS, x/Linux & IBM I **| z/VM coming soon  *




On Sat, Apr 13, 2024 at 5:30 PM   < 
0619bfe39560-dmarc-requ...@listserv.ua.edu> wrote:

> Which utility do you use for control statement/input:
> ./ ADD
>
> A jcl for that would be nice too.
>
> ...Embarassed by my lack of memory after 8 years out of this 
> envirinment...
>
> --
> 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: Not getting IBM-MAIN Email

2024-04-10 Thread Lennie Bradshaw
Hope is not a strategy .
Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Schuster
Sent: 10 April 2024 17:59
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Not getting IBM-MAIN Email

My digest also automagically showed up today.  Hopefully issue is resolved.

--
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: DFsort error message

2024-03-28 Thread Lennie Bradshaw
As for many abend codes, the numbers relate to SVC number.

Open SVC is 19, which is x'13' hence many OPEN issues are 213 or 913 and so on.
EOV SVC is 55, which is x'37', hence many out of space issues are D37, E37 and 
so on.

This informal rule applies to many other SVCs as well.

Lennie Dymoke-Bradshaw
https: //rsclweb.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
T Roller
Sent: 27 March 2024 17:04
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFsort error message

One of the most important things I learned 45 years ago was 37 is always a 
space issue. 13 was an open issue and 14 a close issue.

Sent from [Proton Mail](https://proton.me/mail/home) for iOS

On Tue, Mar 26, 2024 at 1:24 PM, Ron Thomas 
<[0600304cab5d-dmarc-requ...@listserv.ua.edu](mailto:On Tue, Mar 26, 2024 
at 1:24 PM, Ron Thomas < wrote:

> Hi All -
>
> We are getting a sort error on a huge file . Below are the details 
> from log
>
> Parm cards used
> SORT FIELDS=COPY
>
> Error Log details
>
> ICE193I 0 ICEAM1 INVOCATION ENVIRONMENT IN EFFECT - ICEAM1 ENVIRONMENT 
> SELECTED ICE252I 1 PARMLIB OPTIONS WERE MERGED WITH INSTALLATION 
> MODULE DEFAULTS ICE088I 0 ITGB9059.STEP02 .SORT , INPUT LRECL = 317, 
> BLKSIZE = 27896, TYPE = ICE093I 0 MAIN STORAGE = 
> (MAX,33554432,33554432) ICE156I 0 MAIN STORAGE ABOVE 16MB = 
> (33497072,33497072) ICE127I 0 OPTIONS: OVFLO=RC0 ,PAD=RC0 ,TRUNC=RC0 
> ,SPANINC=RC16,VLSCMP=N,SZERO=Y, ICE128I 0 OPTIONS: 
> SIZE=33554432,MAXLIM=1048576,MINLIM=450560,EQUALS=N,LIST=Y,ER
> ICE129I 0 OPTIONS: VIO=N,RESDNT=ALL ,SMF=FULL 
> ,WRKSEC=Y,OUTSEC=Y,VERIFY=N,CHALT=
> ICE130I 0 OPTIONS: RESALL=8192,RESINV=0,SVC=109 
> ,CHECK=Y,WRKREL=Y,OUTREL=Y,CKPT= ICE131I 0 OPTIONS: 
> TMAXLIM=33554432,ARESALL=0,ARESINV=0,OVERRGN=65536,CINV=Y,CFW
> ICE132I 0 OPTIONS: VLSHRT=N,ZDPRINT=Y,IEXIT=N,TEXIT=N,LISTX=N,EFS=NONE 
> ,EXITC ICE133I 0 OPTIONS: HIPRMAX=0 
> ,DSPSIZE=2000,ODMAXBF=2097152,SOLRF=N,VLLONG=N
> ICE235I 0 OPTIONS: NULLOUT=RC0
> ICE236I 0 OPTIONS: DYNAPCT=10 ,MOWRK=Y,TUNE=STOR,EXPMAX=2000 
> ,EXPOLD=MAX ,E ICE084I 0 EXCP ACCESS METHOD USED FOR SORTIN ICE889I 0 
> CT=MAX , SB=3, L=0, D=, CCW=1MAM ICE902I 0 O I PP11 ICE906I 1 
> ST=ABOVE,SR=33497072,RC=0 ICE907I 1 
> ST=ABOVE,SA=33497056,NF=1,LF=33497056,SF=33497056
> ICE906I 1 ST=BELOW,SR=98320,RC=0
> ICE907I 1 ST=BELOW,SA=49152,NF=1,LF=49152,SF=49152
> ICE231I 0 STORAGE USED FOR OUTFIL : BELOW 16M = 20480, ABOVE 16M = 
> 2119680 ICE231I 0 STORAGE USED FOR OUTFIL : BELOW 16M = 20480, ABOVE 
> 16M = 2119680 ICE855I 0 SORTOUT : TX=N, R=J, L=J, B=D, BL=0, BR=0, 
> DCT=37, VS=N, RU=X, SB=8 ICE210I 0 SORTOUT : EXCP USED, LRECL = 317, 
> BLKSIZE = 27896, TYPE = FB ICE751I 2 EF-I80638 CB-NONE F0-NONE 
> DA-I76950 ICE185A 0 AN SE37 ABEND WAS ISSUED BY DFSORT, ANOTHER 
> PROGRAM OR AN EXIT (PHASE
>
> Job Step work file details . Allocated SORTWK50 files
>
> XXSORTWK09 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,())
> IEFC653I SUBSTITUTION JCL - DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(200))
> XXSORTWK10 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,())
> IEFC653I SUBSTITUTION JCL - DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(200))
> XXSORTWK11 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,())
> IEFC653I SUBSTITUTION JCL - DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(200))
> XXSORTWK12 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,())
> IEFC653I SUBSTITUTION JCL - DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(200))
> XXSORTWK13 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,())
> IEFC653I SUBSTITUTION JCL - DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(200))
> XXSORTWK14 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,())
> IEFC653I SUBSTITUTION JCL - DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(200))
> XXSORTWK15 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,())
> IEFC653I SUBSTITUTION JCL - DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(200))
> XXSORTWK16 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,())
> IEFC653I SUBSTITUTION JCL - DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(200))
> XXSORTWK17 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,())
> IEFC653I SUBSTITUTION JCL - DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(200))
> XXSORTWK18 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,())
> IEFC653I SUBSTITUTION JCL - DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(200))
> XXSORTWK19 DD DISP=(NEW,DELETE,DELETE),SPACE=(CYL,())
> IEFC653I SUBSTITUTION JCL - DISP=(NEW,DELETE,DELETE),SPACE=(CYL,(200))
>
> //SORTOUT DD DSN=KGN01.PS.RPCFIL.AMT.ACTV.UNLD.FINAL1.HDR,
> // SPACE=(CYL,(1200,500),RLSE),VOL=(,,,99),
> // RECFM=FB,DSORG=PS,
> // DISP=(NEW,CATLG,DELETE),LRECL=317,BLKSIZE=0
> //SYSIN DD DSN=MK.PS.PROD.PARMLIB(PSJH06P),DISP=SHR
>
> Could someone please let us know what needs to be done here?
>
> Regards
> Ron T
>
> --
> 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 

Re: How can I determine MVS FQDSN from DD Name in Batch COBOL Program?

2024-03-26 Thread Lennie Bradshaw
I have not followed all your pointers logic here, but I suspect this may fail 
when presented with a site where the SWA (Scheduler Work Area) is placed above 
the 16M line. 

Lennie Dymoke-Bradshaw
https: //rsclweb.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Cameron Conacher
Sent: 25 March 2024 23:46
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How can I determine MVS FQDSN from DD Name in Batch COBOL Program?

Hello,
In case anyone needs this….. it seems to work so far.
I did not really need the FQDSN. All I needed to know was whether or not SYSOUT 
was assign to SPOOL.

*
* Work area for the MVS Control Block variables.
*
 01  WS-CONTROL-BLOCK-VARIABLES.
 05  WS-CBV-JOB-NUMBER   PIC X(08).
 05  WS-CBV-JOB-NAME PIC X(08).
 05  WS-CBV-PROGRAM-NAME PIC X(08).
 05  WS-CBV-PROC-STEP-NAME   PIC X(08).
 05  WS-CBV-JOB-STEP-NAMEPIC X(08).
 05  WS-CBV-USER-ID  PIC X(08).
 05  WS-CBV-USER-NAMEPIC X(20).
 05  WS-CBV-PROGRAMMER-NAME  PIC X(20).
 05  WS-CBV-GROUP-NAME   PIC X(20).
 05  WS-CBV-FOUR-BYTES.
 10  WS-CBV-FULL-WORDPIC S9(08) COMP.
 10  WS-CBV-PTR-UNAM REDEFINES WS-CBV-FULL-WORD
 POINTER.
 05  WS-CBV-SUB  PIC S9(04) COMP.
 05  WS-CBV-TIOELINK PIC X(01).
 88  WS-CBV-DDNAME-FOR-DSN  VALUE X'00'.
 88  WS-CBV-DDNAME-FOR-SPOOLVALUE X'02'.


*
* USED WHEN PARSING MVS CONTROL BLOCK DATA.
*
  01  LS-CB-POINTER-AREA-1. *> PSA
  05  LS-CB-POINTER POINTER OCCURS 512 TIMES.
*
* USED WHEN PARSING MVS CONTROL BLOCK DATA.
*
  01  LS-CB-POINTER-AREA-2.
  05  LS-CB-POINTER2 POINTER OCCURS 512 TIMES.
*
*



*
* Get Job Name, Job Step Name and Proc Step Name from
* TIOT Control Blocks.
* See Volume #4 of the MVS Data Areas Page #855.
*
 SET ADDRESS OF LS-CB-POINTER-AREA-1
  TO LS-CB-POINTER (136) *> TCB
 SET ADDRESS OF LS-CB-POINTER-AREA-2
  TO LS-CB-POINTER (004) *> TIOT
 MOVE LS-CB-POINTER-AREA-2 (1:8)
  TO WS-CBV-JOB-NAME   *> JOBNAME

 MOVE LS-CB-POINTER-AREA-2 (9:8)
  TO WS-CBV-PROC-STEP-NAME

 MOVE LS-CB-POINTER-AREA-2 (17:8)
  TO WS-CBV-JOB-STEP-NAME


*
* Iterate over all the DDNAME entries looking for SYSOUT.
* We want to know if it is assigned to SPOOL or not.
*
* In Production DISPLAYs are ignored, so if we are in
* Production and SYSOUT is being sent to the SPOOL, we want
* to be able to disable Tracing.
* On the other hand if SYSOUT is being sent to a DataSet,
* we want to honor the JOB Tracing Parameter for Production.
*
 PERFORM
 VARYING WS-CBV-SUB
FROM +25  *> Start of DDNAME Table
  BY +20  *> Size of DDNAME Table Entry
   UNTIL WS-CBV-SUB > 1120
  OR LS-CB-POINTER-AREA-2 (WS-CBV-SUB + 4:08) =
   LOW-VALUES  *> End of Table
  IF LS-CB-POINTER-AREA-2 (WS-CBV-SUB + 4:08) =
   'SYSOUT  '
 MOVE LS-CB-POINTER-AREA-2 (WS-CBV-SUB + 3:01)
  TO WS-CBV-TIOELINK *> Spool?
 MOVE +1120   TO WS-CBV-SUB  *> Stop Loop
  END-IF
 END-PERFORM

*
* Get Program Name and Job Number from JSCB Control Blocks.
*
 SET ADDRESS OF LS-CB-POINTER-AREA-2
  TO LS-CB-POINTER (46) *> JSCB
 MOVE LS-CB-POINTER-AREA-2 (361:8)
  TO WS-CBV-PROGRAM-NAME

 SET ADDRESS OF LS-CB-POINTER-AREA-2
  TO LS-CB-POINTER2 (80) *> SSIB
 MOVE LS-CB-POINTER-AREA-2 (13:8)
  TO WS-CBV-JOB-NUMBER *> JOBNUM

*
* Get RACF ID from ASCB Control Blocks.
*
 SET ADDRESS OF LS-CB-POINTER-AREA-1
  TO NULL
 SET ADDRESS OF LS-CB-POINTER-AREA-1
  TO LS-CB-POINTER (138) *> ASCB

 SET ADDRESS OF LS-CB-POINTER-AREA-2
  TO LS-CB-POINTER (28)  *> ASXB
 MOVE LS-CB-POINTER-AREA-2 (193:8)
  TO WS-CBV-USER-ID*> RACF ID

*
* Get RACF Group from ACEE Control Blocks.
*
 SET ADDRESS OF LS-CB-POINTER-AREA-2
  TO LS-CB-POINTER2 (51) *> ACEE
 MOVE LS-CB-POINTER-AREA-2 (31:8)
  TO WS-CBV-GROUP-NAME *> GROUP

*
* Get Long Name from UNAM Control Blocks.
*
 SET ADDRESS OF LS-CB-POINTER-AREA-1
  TO LS-CB-POINTER2 (26) *> UNAM
 MOVE ZEROTO WS-CBV-FULL-WORD
 MOVE LS-CB-POINTER-AREA-1 (1:1)
  TO WS-CBV-FOUR-BYTES (4:1)
 MOVE LS-CB-POINTER-AREA-1 

Re: TSO ALLOC with/wo unit

2024-03-20 Thread Lennie Bradshaw
For TSO allocations I think it depends what is specified in the UNIT parameter 
in your TSO RACF segment. If you have SYSALLDA specified then this will accept 
any DASD device. With a specification of SYSDA however, this will depend on the 
Eligible Device Table entries at the site.

Lennie Dymoke-Bradshaw
https: //rsclweb.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
ITschak Mugzach
Sent: 20 March 2024 06:57
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TSO ALLOC with/wo unit

I have a program in Rexx that allocates a dataset using dsname and volume 
serial (1) . it works well in my shop but requires a unit type (2) in another 
shop. Actually the error is msg "IKJ56241I SPECIFIED UNIT IS UNDEFINED".
Why does 1 work here and fails in another shop?

   1. ALLOC F(XXX) DA('dsname') VOLUME(volser)
   2. ALLOC F(XXX) DA('dsname') VOLUME(volser) UNIT(390)

ITschak

ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring for 
z/OS, x/Linux & IBM I **| z/VM coming soon  *

--
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: Changes to user's TSO PROFILE

2024-03-04 Thread Lennie Bradshaw
Yes, you're right Seymour, mea culpa.
Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: 04 March 2024 20:24
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Changes to user's TSO PROFILE

UPT. Some vendors feel entitled to change it without a "by your leave".

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Lennie Bradshaw 
Sent: Monday, March 4, 2024 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Changes to user's TSO PROFILE

The TSO prefix is stored in an unprotected control block (the ECT I think). As 
such, almost any program running in the TSO session can change it. I don't 
think that any of RACF, ACF2 or TSS can protect you against that.

Lennie
-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: 04 March 2024 15:09
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Changes to user's TSO PROFILE

Is there anything that tracks changes to a TSO user's PREFIX? I have a user who 
says her PREFIX keeps getting changed to NOPREFIX.

RACF, ACF2, TSS

Regards,


Steve




This electronic mail (including any attachments) may contain information that 
is privileged, confidential, and/or otherwise protected from disclosure to 
anyone other than its intended recipient(s). Any dissemination or use of this 
electronic email or its contents (including any attachments) by persons other 
than the intended recipient(s) is strictly prohibited. If you have received 
this message in error, please notify us immediately by reply email so that we 
may correct our internal records. Please then delete the original message 
(including any attachments) in its entirety. Thank you

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Monday, March 4, 2024 8:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Changes to user's TSO PROFILE

Is she logging off cleanly?  Or is she letting her session 522 off.  If the 
latter profile changes don’t get written out and would explain the behavior.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu>
Date: Monday, March 4, 2024 at 9:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Changes to user's TSO PROFILE
Is there anything that tracks changes to a TSO user's PREFIX? I have a user who 
says her PREFIX keeps getting changed to NOPREFIX. Sent with [Proton 
Mail](https: //urldefense. com/v3/__https: //proton. 
me/__;!!MwwqYLOC6b6whF7V!navz9IU9urj6-WD1bs70v0jirVugGM3fVsmTgIhtPtaDd2ydFFBLTQtu_EI2_Zl_JqzVn7SpnLGTzHWtjx_XvDxZXMXTL0lVDJg$)


Is there anything that tracks changes to a TSO user's PREFIX? I have a user who 
says her PREFIX keeps getting changed to NOPREFIX.



Sent with [Proton 
Mail](https://urldefense.com/v3/__https://proton.me/__;!!MwwqYLOC6b6whF7V!navz9IU9urj6-WD1bs70v0jirVugGM3fVsmTgIhtPtaDd2ydFFBLTQtu_EI2_Zl_JqzVn7SpnLGTzHWtjx_XvDxZXMXTL0lVDJg$<https://urldefense.com/v3/__https:/proton.me/__;!!MwwqYLOC6b6whF7V!navz9IU9urj6-WD1bs70v0jirVugGM3fVsmTgIhtPtaDd2ydFFBLTQtu_EI2_Zl_JqzVn7SpnLGTzHWtjx_XvDxZXMXTL0lVDJg$>)
 secure email.



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

--
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 / si

Re: Changes to user's TSO PROFILE

2024-03-04 Thread Lennie Bradshaw
I think the prefix is remembered across TSO sessions, and it is stored in the 
TSO segment of RACF. However, it is stored at LOGOFF time, so interim changes 
are not recorded.
Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: 04 March 2024 19:36
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Changes to user's TSO PROFILE

(Although come to think of it I guess PREFIX/NOPREFIX isn't one of the fields 
recorded in TSS.  I don't remember about ACF2 or RACF.)

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* If you have a problem with me, text me.  And if you don’t have my number, 
you don’t know me well enough to have a problem with me.  -Christian Bale */

-Original Message-
From: robhbrid...@gmail.com 
Sent: Monday, March 4, 2024 14:34

Protect, no, but since many of the fields in the TSO profile are recorded in 
the security ID, mightn't they at least track the changes when they occur?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lennie Bradshaw
Sent: Monday, March 4, 2024 10:22

The TSO prefix is stored in an unprotected control block (the ECT I think). As 
such, almost any program running in the TSO session can change it. I don't 
think that any of RACF, ACF2 or TSS can protect you against that.

--
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: Changes to user's TSO PROFILE

2024-03-04 Thread Lennie Bradshaw
The TSO prefix is stored in an unprotected control block (the ECT I think). As 
such, almost any program running in the TSO session can change it. I don't 
think that any of RACF, ACF2 or TSS can protect you against that.

Lennie
-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: 04 March 2024 15:09
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Changes to user's TSO PROFILE

Is there anything that tracks changes to a TSO user's PREFIX? I have a user who 
says her PREFIX keeps getting changed to NOPREFIX.

RACF, ACF2, TSS

Regards,


Steve 




This electronic mail (including any attachments) may contain information that 
is privileged, confidential, and/or otherwise protected from disclosure to 
anyone other than its intended recipient(s). Any dissemination or use of this 
electronic email or its contents (including any attachments) by persons other 
than the intended recipient(s) is strictly prohibited. If you have received 
this message in error, please notify us immediately by reply email so that we 
may correct our internal records. Please then delete the original message 
(including any attachments) in its entirety. Thank you

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Monday, March 4, 2024 8:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Changes to user's TSO PROFILE

Is she logging off cleanly?  Or is she letting her session 522 off.  If the 
latter profile changes don’t get written out and would explain the behavior.

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu>
Date: Monday, March 4, 2024 at 9:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Changes to user's TSO PROFILE
Is there anything that tracks changes to a TSO user's PREFIX? I have a user who 
says her PREFIX keeps getting changed to NOPREFIX. Sent with [Proton 
Mail](https: //urldefense. com/v3/__https: //proton. 
me/__;!!MwwqYLOC6b6whF7V!navz9IU9urj6-WD1bs70v0jirVugGM3fVsmTgIhtPtaDd2ydFFBLTQtu_EI2_Zl_JqzVn7SpnLGTzHWtjx_XvDxZXMXTL0lVDJg$)


Is there anything that tracks changes to a TSO user's PREFIX? I have a user who 
says her PREFIX keeps getting changed to NOPREFIX.



Sent with [Proton 
Mail](https://urldefense.com/v3/__https://proton.me/__;!!MwwqYLOC6b6whF7V!navz9IU9urj6-WD1bs70v0jirVugGM3fVsmTgIhtPtaDd2ydFFBLTQtu_EI2_Zl_JqzVn7SpnLGTzHWtjx_XvDxZXMXTL0lVDJg$)
 secure email.



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: PDS compression needs a new name - defoam? unfoam? degas? I hope someone has a better idea!

2022-12-23 Thread Lennie Bradshaw
Agree.
Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: 24 December 2022 07:21
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PDS compression needs a new name - defoam? unfoam? degas? I hope 
someone has a better idea!

On 12/21/2022 3:16 AM, David Cole wrote:
> The notion of "PDS compression" has a long and time honored history... 
> But then along came... well, actual compression!
>
> As we all know, PDS compression has nothing to do with data 
> compression. All it does is rearrange the physical location of members 
> so as to eliminate the holes (foam? gas?) that has arisen between them.
>
> Historically, we have called that "compression", but in this day and 
> age continuing to call it that no longer is an option.
>
> Has anyone come up with a better term that I missed while not looking?

I like REORG.

It's a time-honored (often database) term used to describe various processes 
similar to what is done to a PDS during "compression"...


-- 
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


zPDT Learner's Edition

2021-09-23 Thread Lennie Bradshaw
Has anyone else any information on the zD Learner's Edition that was
recently shown on the IBM zZ pages?
https://www.ibm.com/products/z-development-test-environment/pricing 

It appears that IBM has removed some references to it now, although the FAQs
on that page (need to scroll down) still show a question with a price of
$120 per annum once a person is "Qualified".

Any comments from IBM would be useful.

Lennie Dymoke-Bradshaw
https://rsclweb.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: RENT binder option - note of thanks!

2021-09-06 Thread Lennie Bradshaw
Like count = Link count + 1

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Brennan
Sent: 06 September 2021 22:02
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RENT binder option - note of thanks!

Like count=1

On 9/6/2021 1:15 PM, Mike Hochee wrote:
> Just a word of thanks to the IBM heavyweights (Jim, Peter, Sri, et. al.) to 
> whom a debt of gratitude is owed for their deep-water expertise, patience, 
> and willingness to share knowledge when they undoubtedly have many other 
> things to work on.
> 
> I suspect there are many subscriber motivations for posting on this forum, 
> some obvious and simple: wrestling with a problem for days and pulling hair 
> out, making known a potentially serious 'gotcha', or 'Hey, that happened to 
> me!' and therefore sharing the love. There are undoubtedly other motivations 
> for posting that are not so obvious, and disappointingly some of these often 
> muddy the waters and result in very large waste-of-time threads for the vast 
> majority of subscribers, but might however serve to satisfy the personal and 
> non-technical needs of a few folks.
> 
> Charles' suggestion of a 'Like' button hit the nail on the head. A mechanism 
> for informing personally needy folks that they are no longer enlightening, 
> but instead engaging in an unwelcome behavior. Yes, they did play well with 
> others for a while, but eventually felt a  compelling need to make love to 
> their egos in a public forum, a forum designed to assist folks with deeper 
> technical issues.
> 
> The downside is often evidenced by a dozens of emails rather than 5 or 10.  A 
> much more serious downside is that the patience of our excellent IBM 
> resources might eventually wear thin, I know mine would.
> 
> HTH,
> 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: FTP problem

2021-08-19 Thread Lennie Bradshaw
Gadi,

I think the userid is not checked until the password is available. You can
confirm this by entering a userid that is not valid. You will still get a
password prompt.

So it looks to me that once the pair are available they are sent to RACF;
where you are getting a wait. You need to understand why RACF/ACF2/TSS is
taking so long with the authentication.

Lennie Dymoke-Bradshaw
https://rsclweb.com
"Dance like no one is watching. Encrypt like everyone is"

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Gadi Ben-Avi
Sent: 19 August 2021 11:22
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: FTP problem

Hi,
We are in the midst of a DR test.
A user is complaining that they are have problems using ftp.

When the issue the ftp command from the command line in windows, they get
the prompt for the user name almost immediately.
Once the user enters the password and presses enter, it takes over a minute
to get the prompt for the password.

Has anyone encountered this problem.

We do not have a similar problem on our production system.

The production system is a z15-t02. The LPAR has 92 GB of storage.
The DR system is a z13s. The LPAR has 16GB of storage.

Both are running z/OS 2.3.

Any help would be appreciated.

Thanks

Gadi


--
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: Log of CICS transactions

2021-08-02 Thread Lennie Bradshaw
Tom,

Another aside
Quick and Dirty way of changing the RECFM *without* an authorised command.

//MAKEVB  EXEC PGM=IEBGENER 
//SYSPRINT DD  SYSOUT=* 
//SYSINDD  *
//SYSUT1   DD  DUMMY,   
//  DCB=(LRECL=32756,RECFM=VB,BLKSIZE=32760)
//SYSUT2   DD  DSN=SMF.SAVE.GDG.G0719V00,DISP=MOD,  
//  DCB=(LRECL=32756,RECFM=VB,BLKSIZE=32760)

Lennie Dymoke-Bradshaw
https://rsclweb.com
“Dance like no one is watching. Encrypt like everyone is”

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Brennan
Sent: 02 August 2021 21:03
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Log of CICS transactions

Not a real answer - but more of a side question for others.  Whenever I wanted 
a quick look at SMF records I would dump what I was interested in to my own 
dataset, which was VBS of course.  Then I used an auth command we had called 
DSCBMOD (maybe from CBT?) to change VBS to VB and I was off and browsing or 
rexx'ing or whatever.

My assumption (note first 3 letters of assumption) was that I never cared about 
the far right-hand side of the records - so I wasn't missing anything 
important.  Or was I really missing entire records?

On 8/2/2021 12:40 PM, Bob Bridges wrote:
> I've worked at a number of mainframe installations, and at many of them I've 
> encountered a dataset that logs usage of CICS transactions.  Usually it's a 
> GDG, either weekly or monthly, wherein each record contains a transaction, a 
> user ID and a count.  I'm not a CICS support guru -- in fact  in my 15 years 
> of COBOL development, before I got into security, somehow I managed to avoid 
> CICS even on the coding side -- so I'm ignorant of how it was done, but I 
> surmise CICS can produce this log periodically.  Can anyone tell me how it's 
> invoked?
> 
> Or if you're about to tell me it's not CICS but SMF, then a different 
> question:  Last I heard, SMF records are VBS and REXX won't read VBS records. 
>  How does one cross that bridge?  Is there an SMF utility that can be 
> persuaded to write out selected records in some other RECFM?
> 
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> 
> /* Advertising copy.  Where sentences are replaced by participle 
> phrases.  Noun phrases.  And dangling conjunctions.  -K */
> 
> --
> 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: Request for help with removing sequence numbers from PDS members

2021-01-11 Thread Lennie Bradshaw
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 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: CSNBHMG - ICSF

2020-10-23 Thread Lennie Bradshaw
Pierre,

I believe you are mistaken.

CSNB* calls are for symmetric keys.
CSND* calls are for asymmetric keys.
This was true long before support for AES keys was introduced.

Lennie Dymoke-Bradshaw

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pierre Fichaud
Sent: 23 October 2020 17:17
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSNBHMG - ICSF

Hi,
CSNB* calls are DES
CSND* calls are AES.
If you are using CSNBHMG you need the DES master key to be set.
And the label used in the call needs to be in the CKDS.
And you need permissions defined in RACF.
Regards, Pierre.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: EXTERNAL EMAIL: How get a user to use his own catalog rather than master?

2020-09-17 Thread Lennie Bradshaw
I did not intend to start a storm of messages here.
I was simply using the IBM definition of system integrity which they document 
here,
https://www.ibm.com/it-infrastructure/z/capabilities/system-integrity

Yes, maybe it is semantics. But many working in IBM mainframe security 
community would distinguish security and integrity issues from one another. 

Lennie Dymoke-Bradshaw


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: 17 September 2020 17:16
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL EMAIL: How get a user to use his own catalog rather than 
master?

Classification: HCL Internal

Would you allow random updates of the ROOT directory on a *NIX system?. This is 
definitely both a integrity and an operational exposure

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Smith
Sent: Thursday, September 17, 2020 11:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL EMAIL: How get a user to use his own catalog rather than 
master?

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

There's not much benefit to debating the semantics of "integrity".  Nobody who 
doesn't thoroughly understand catalog management should be able to update the 
master catalog, because you can easily destroy the system by removing critical 
dataset entries.  Much more typically, it just fills up with junk.

sas


On Thu, Sep 17, 2020 at 11:58 AM Gibney, David Allen  wrote:

> I could damage the catalog, perhaps as easily as adding datasets until 
> I overflow it. Perhaps not integrity as in ability to upgrade my 
> authority, but certainly a potential DOS and a threat to system stability.
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


--
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: Architectural Level Sets

2020-09-09 Thread Lennie Bradshaw
I think this happened with the move to MVS/XA as XA does not recognise a BC 
mode PSW.
So I guess it was the first machine which did not support architectures earlier 
than MVS/XA. 
I suspect that was the 3081.

All my conjecture of course. Let's see what the IBM oracles tell us.

Lennie Dymoke-Bradshaw

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark S Waterbury
Sent: 09 September 2020 18:35
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Architectural Level Sets

To add to this thread ...

I would like to know at what point during the evolution from S/370 to S/370-XA 
to S/390 to zSeries, did the architecture stop supporting IPL of any OS that 
runs in "BC mode" or that starts out in BC mode, before setting up page and 
segment tables and control registers and then enabling DAT?

In other words, what processor family(s) and specific models in that family, if 
need be, can no longer IPL and run any of the "public domain" operating systems 
from the 1970s to early 1980s?  (DOS/360, OS/360, DOS/VS, OS/VS1, OS/VS2, 
VM/370, TSS/370, etc.)

Thanks in advance.

Mark S. Waterbury

--
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