Re: 2.5 Heads Up

[Ed Jaffe]

On 2/22/2022 3:33 PM, Seymour J Metz wrote:

Are you sure that it doesn't change the timing?


We have seen no observable difference in execution timing.

We run it constantly...


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

FYI: Linux developers patch security holes faster than anyone else, says Google Project Zero | ZDNet

[Mark Regan]

Just FYI…

https://www.zdnet.com/article/google-project-zero-finds-linux-developers-patch-security-holes-faster-than-anyone-else/
 

 

​Regards,

Mark Regan, K8MTR General, EN80tg
CTO1 USNR-Retired (1969-1991)
Nationwide Insurance, Retired, 1986-2017
z/OS Network Software Consultant (z NetView, z/OS Communications Server)
Contractor, Checks & Balances, Inc.
Email: marktre...@gmail.com  
LinkedIn:  https://www.linkedin.com/in/mark-t-regan

 

 


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

Re: 2.5 Heads Up

[Seymour J Metz]

For ESA it's real (not absolute) addresses 0-511; for Z architecture the firs 
512 bytes of the second page fram are also protected.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Tuesday, February 22, 2022 1:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

Right ...

Is there a control register bit or something like that for authority to
store in the PSA (+ Key 0 of course).

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lennie Dymoke-Bradshaw
Sent: Tuesday, February 22, 2022 9:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

There will be multiple versions of that address for PSA for each active
processor in the LPAR.
I don't think that KEY 0 is adequate authority to store there either. Could
be done from a hardware console though.

--
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: 2.5 Heads Up

[Seymour J Metz]

Are you sure that it doesn't change the timing?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Ed 
Jaffe [edja...@phoenixsoftware.com]
Sent: Tuesday, February 22, 2022 4:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

On 2/22/2022 1:22 PM, Seymour J Metz wrote:
>> ZAD SLIP tracing can catch these issues without changing the outcomes.
> ?

https://www.ibm.com/docs/en/zos/2.5.0?topic=traps-slip-zero-address-detection-zad


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://secure-web.cisco.com/1d309o_nymYI4NN81SNQkROySA789myax_FNmDF4wdekHkf5qOcDYvHGuOQ7rhaurezAWcbUIXhzufzfx4Ik4pzYwwmZoerhyOzoei6FF1aXvaBtPUdtuaj1V-0X5Yuaj0WwAW64h_V5x2fYyLqeeCgwz3ltssPfeOc4aqG9y_3iR0ynUt-IpA3FzP_DHoQZoun6N-o7NYfWR0p5KciVNgvrXmwmJ7JPoo4bOnt9QSsMFKd-yqQLwF_awcR3MLqiKorP-wvicETOyvBn4pG5UThfApMD3SAaQpSLhaljsr0hgKxFFlrfpWk-tjYyLYeYjHI81jUnnZDcwP1NRa-Eh0RuP6BL_nTZp64mE64R42R9Td_uLJSTTaT2Xw_RkL4gnSip2HK5Z2LXD6McT84Cq8htuAMRIzPLoRUUlfcz7c7eCVHg6lIixALmuOYZvuIof/https%3A%2F%2Fwww.phoenixsoftware.com%2F



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

Re: 2.5 Heads Up

[Ed Jaffe]

On 2/22/2022 1:22 PM, Seymour J Metz wrote:

ZAD SLIP tracing can catch these issues without changing the outcomes.

?


https://www.ibm.com/docs/en/zos/2.5.0?topic=traps-slip-zero-address-detection-zad


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

Re: 2.5 Heads Up

[Seymour J Metz]

>ZAD SLIP tracing can catch these issues without changing the outcomes.

?


From: IBM Mainframe Discussion List  on behalf of Ed 
Jaffe 
Sent: Tuesday, February 22, 2022 3:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

On 2/22/2022 12:28 PM, Seymour J Metz wrote:
> I also hate problems that disappear when I turn tracing or other diagnostics 
> on.

ZAD SLIP tracing can catch these issues without changing the outcomes.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://secure-web.cisco.com/1zz7JwFcR3Dnf7eDnDTj6-08C9oMw4zDXReedtZjlpNl583efQ7OBHthtoa5VC1fZhrL-rdSjU6ALJaRzDWN2swwzRleBh3TnIfKifyHSBKi2qi1bZ479PTpkk1Q0dVCcLmDWluhoTWFUgVf57-j4NpgNGlas5KwZIe5y5gNljIU5D8tgyK8TToRe2P7SdxT8VO-LPwFt6zZ2372L6YGmLslfbl3vOisDqcEDuDIlsPkv0_Mn8UKJ73KiHY4yi_vjUiufxtZw4MLyD_eHqGhxVWWFav90zDsT7fDFq8X-xZPFtUny-JhL1d-O71xAGgy4k9E4kn8YEK7pLx7Ms5XvIMKF69WPEftfvUZu6tBODdlz8FRp3Jzxqx8EGuG8DY1wAAbb4A-n6mOxmKW6_Znjb6xhnwf6L7uEET_UBV0LQTE72ErB-aRmLeHtBIcRxFTE/https%3A%2F%2Fwww.phoenixsoftware.com%2F



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

Re: 2.5 Heads Up

[Charles Mills]

> expose latent defects in code that happens to seem to work when reserved
fields contain zeroes

Need to test the other side of that coin: code that only works when a
reserved field contains non-zeroes.



Obviously there is no limit to the possible conditions. What about code that
erroneously tests one bit of some reserved field, or does an erroneous TM/BM
on some reserved field?

Software testing, as all of us know too well, is a fraught exercise. Finding
bugs is not too bad; it's the finding of the *absence* of bugs that is
tough.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Mulder
Sent: Tuesday, February 22, 2022 11:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

  Yes, the undocumented (but disclosed to ISVs) IGVDGNPP test tool will
modify all of the reserved fields in every CPU's PSA in order to expose 
latent defects in code that happens to seem to work when reserved fields 
contain zeroes.  But since that may expose latent defects in other code
(IBM, ISV, or customer), it's not the kind of thing you would want to 
use on a production system.

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

Re: 2.5 Heads Up

[Ed Jaffe]

On 2/22/2022 12:28 PM, Seymour J Metz wrote:

I also hate problems that disappear when I turn tracing or other diagnostics on.


ZAD SLIP tracing can catch these issues without changing the outcomes.


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

Re: 2.5 Heads Up

[Seymour J Metz]

I also hate problems that disappear when I turn tracing or other diagnostics on.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, February 22, 2022 3:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

On Tue, 22 Feb 2022 15:37:51 -0400, Jim Mulder wrote:
>..
>  We of course use that tool on our test systems, so that we tend to
>not have zeros at PSA+4 on our z/OS 2.5 test systems, which may
>have contributed to the bug escaping our notice
>until it got into the field.
>
Tsk. Tsk.  At times I have requested various tools on our systems, declined
because their presence might invalidate our tests.

And I recall a piece of vendor software that abended in production mode but
gave the result I intended in test mode.  SR.  "User error: RTFM.  You're
using something documented as 'unpredictable'."  Correct, but too
unpredictable for my taste.

--
gi

--
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: 2.5 Heads Up

[Paul Gilmartin]

On Tue, 22 Feb 2022 15:37:51 -0400, Jim Mulder wrote:
>..
>  We of course use that tool on our test systems, so that we tend to
>not have zeros at PSA+4 on our z/OS 2.5 test systems, which may
>have contributed to the bug escaping our notice 
>until it got into the field. 
>
Tsk. Tsk.  At times I have requested various tools on our systems, declined
because their presence might invalidate our tests.

And I recall a piece of vendor software that abended in production mode but
gave the result I intended in test mode.  SR.  "User error: RTFM.  You're
using something documented as 'unpredictable'."  Correct, but too
unpredictable for my taste.

-- 
gi

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

Re: 2.5 Heads Up

[Steve Thompson]

Be nice to have a tool like that to run on our Sand Box 
systems Might catch some old ALC code doing something not too 
bright in the z/OS world that was OK at MVS 3.8 Yes, some of 
us do have code that old.


Just say'n'

Steve Thompson

On 2/22/22 14:37, Jim Mulder wrote:

   Yes, the undocumented (but disclosed to ISVs) IGVDGNPP test tool will
modify all of the reserved fields in every CPU's PSA in order to expose
latent defects in code that happens to seem to work when reserved fields
contain zeroes.  But since that may expose latent defects in other code
(IBM, ISV, or customer), it's not the kind of thing you would want to
use on a production system.

   We of course use that tool on our test systems, so that we tend to
not have zeros at PSA+4 on our z/OS 2.5 test systems, which may
have contributed to the bug escaping our notice
until it got into the field.

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
Poughkeepsie NY

"IBM Mainframe Discussion List"  wrote on
02/22/2022 10:26:40 AM:


From: "Charles Mills"
To:IBM-MAIN@LISTSERV.UA.EDU
Date: 02/22/2022 02:28 PM
Subject: Re: 2.5 Heads Up
Sent by: "IBM Mainframe Discussion List"

Would using some "debug" type utility to store a non-zero value at

address 4

be a partial circumvention?

The pre-Z restart PSW is never used for anything now -- is that correct?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Mulder
Sent: Monday, February 21, 2022 10:03 PM
To:IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

   Location 4 means address 4 (i.e. offset 4 in the PSA).

  There was a latent bug from a prior release in the loop control
code so that it was erroneously fetching from address 4, and
behaving especially badly when the data at that location
is x'', which it is as of z/OS 2.5.  In prior releases,
it was x'000130E1' when in zArchitecture mode.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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: 2.5 Heads Up

[Jim Mulder]

  Yes, the undocumented (but disclosed to ISVs) IGVDGNPP test tool will
modify all of the reserved fields in every CPU's PSA in order to expose 
latent defects in code that happens to seem to work when reserved fields 
contain zeroes.  But since that may expose latent defects in other code
(IBM, ISV, or customer), it's not the kind of thing you would want to 
use on a production system.

  We of course use that tool on our test systems, so that we tend to
not have zeros at PSA+4 on our z/OS 2.5 test systems, which may
have contributed to the bug escaping our notice 
until it got into the field. 

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

"IBM Mainframe Discussion List"  wrote on 
02/22/2022 10:26:40 AM:

> From: "Charles Mills" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 02/22/2022 02:28 PM
> Subject: Re: 2.5 Heads Up
> Sent by: "IBM Mainframe Discussion List" 
> 
> Would using some "debug" type utility to store a non-zero value at 
address 4
> be a partial circumvention?
> 
> The pre-Z restart PSW is never used for anything now -- is that correct?
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jim Mulder
> Sent: Monday, February 21, 2022 10:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: 2.5 Heads Up
> 
>   Location 4 means address 4 (i.e. offset 4 in the PSA). 
> 
>  There was a latent bug from a prior release in the loop control 
> code so that it was erroneously fetching from address 4, and 
> behaving especially badly when the data at that location 
> is x'', which it is as of z/OS 2.5.  In prior releases,
> it was x'000130E1' when in zArchitecture mode.



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

Re: Resizing MCDS

[Allan Staller]

Classification: Confidential

In additon, if you haven't already, implement ca-reclaim for the HSD CDS's. I 
would do it everywhere for all ksds'S


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Watkins
Sent: Tuesday, February 22, 2022 11:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Resizing MCDS

[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.]

I heartily agree that SMS-management and RLS is the preferred way to define all 
DFSMShsm CDSs. I made the rash assumption that Peter simply need to resize the 
MCDS in the near future instead of making a project out of it by defining the 
required coupling facility structures and making the DFSMShsm CDSs SMS-managed. 
Can the MCDS exceed the 4 GB limit without SMS-management? From the following 
discussion, it appears it can be:

See: 
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.zmainframes.com%2Fviewtopic.php%3Ft%3D2009data=04%7C01%7Callan.staller%40HCL.COM%7C7302361e8afe422606f708d9f625d146%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637811465305104587%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=%2FjDJV33U5jV5FNM5DuM%2BYJ%2F5fHGGn2hFVMrxrORBXlE%3Dreserved=0

'Over coming the 4 GB limit of VSAM.', Mon Feb 22, 2016 6:29 pm, Robert Sample: 
 If you read the manual on DEFINE CLUSTER, you will discover that the manual 
EXPLICITLY states that DATACLASS can be used for SMS or non-SMS managed 
storage. Yes, it is part of SMS but it can also be used outside SMS.

Sat Feb 27, 2016 6:00 pm, Angel:  I have suggested to use the Extended  Format 
(VSAM EF) files. As I read about them, they allow to add an extra 32 control 
bytes to each data block. But they need to be DFSMS managed. It seems to solve 
the problem. So even if a DATACLASS is also given the restriction of 4GB 
anyways remains, right?

Sat Feb 27, 2016 7:42 pm, Robert Sample:  This is another reason you REALLY 
need to talk to your site support group. If the DATACLASS given does not 
support VSAM extended format (a DATACLASS can be used for different reasons), 
then yes the 4 GB limit still applies. Only someone working at your site can 
provide you with the site-specific information you need on how to get your VSAM 
data set to go past 4 GB; we can only say that yes it can be done.

Wed May 04, 2016 4:42 pm, Angel:  We ended up using 4 GB limit, as going beyond 
that was not recommended by the policies.

Thu May 05, 2016 1:22 am, Robert Sample:  Policies often wind up being in 
effect long after they should have been changed.  I've used a number of VSAM 
linear and KSDS data sets as large as 60 GB with no problems; a policy against 
them makes less and less sense as time passes.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Nigel Morton
Sent: Tuesday, February 22, 2022 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Resizing MCDS

I would suggest using extended addressability VSAM to avoid the 4GB limit as 
well as considering multi-cluster CDSs (for MCDS and BCDS, don't think it is 
supported for the OCDS). I'd also recommend using RLS as I've seen it speed up 
long-running HSM functions significantly.

Both extended addressability and RLS for HSM CDSs have been around for several 
years.

On Tue, 22 Feb 2022 at 15:50, Michael Watkins < 
032966e74d0f-dmarc-requ...@listserv.ua.edu> wrote:

Yes, all DFSMShsm ASIDs in the HSMplex must be down. (All DFSMShsm ASIDs that 
share control datasets and a journal are in the same HSMplex.) I would rename 
the existing MCDS by appending the current date [either '.#22feb22' or 
'.#22053' (Julian date) for today, for example] to the index and data component 
names as well as to the cluster name. By including the date last used in the 
new dataset name, there will be less question of what the cluster is when you 
don't delete it and someone else is looking at it next year and wondering if 
they can reclaim the space.

First, After renaming the MCDS, I would then define the new (presumably larger) 
MCDS with the old name by using the MODEL parameter and changing only the CYLS 
for both the data and index components to (x 0). By using the same MCDS name, 
no JCL will have to be changed. No secondary should be allocated to any of the 
DFSMShsm control datasets when they are shared by DFSMShsm ASIDs on different 
LPARs, unless the DFSMShsm CDSs are managed with RLS (Record Level Sharing).

Second, REPRO the old '.#yyddd' MCDS into the new MCDS.

Third, restart DFSMShsm on all LPARs, one at a time. Done.

Let's assume your MCDS's characteristics are:
KEYLEN: 44 AVGLRECL: 435 BUFSPACE: 530432 CISIZE: 12288  RKP: 0 
MAXLRECL: 2040 EXCPEXIT: (NULL) CI/CA: 60 SHROPTNS(3,3)
SPEED UNIQUE NOERASE INDEXED 

Re: Resizing MCDS

[Allan Staller]

Classification: Confidential

Depending on the current size if the CDS's I recommends converting to SMS Mgmt 
of the CDSs.
If they are anywhere close to the 5200 cyl size, it will save a lot of effort 
(perhaps when things are broken). 
If they are tiny (FSVO tiny). Then don’t bother

Pay me now or pay me later,

HTH

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Watkins
Sent: Tuesday, February 22, 2022 9:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Resizing MCDS

[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.]

Yes, all DFSMShsm ASIDs in the HSMplex must be down. (All DFSMShsm ASIDs that 
share control datasets and a journal are in the same HSMplex.) I would rename 
the existing MCDS by appending the current date [either '.#22feb22' or 
'.#22053' (Julian date) for today, for example] to the index and data component 
names as well as to the cluster name. By including the date last used in the 
new dataset name, there will be less question of what the cluster is when you 
don't delete it and someone else is looking at it next year and wondering if 
they can reclaim the space.

First, I would then define the new (presumably larger) MCDS with the old name 
by using the MODEL parameter and changing only the CYLS for both the data and 
index components to (x 0). By using the same MCDS name, no JCL will have to be 
changed. No secondary should be allocated to any of the DFSMShsm control 
datasets when they are shared by DFSMShsm ASIDs on different LPARs, unless the 
DFSMShsm CDSs are managed with RLS (Record Level Sharing).

Second, REPRO the old '.#yyddd' MCDS into the new MCDS.

Third, restart DFSMShsm on all LPARs, one at a time. Done.

Let's assume your MCDS's characteristics are:

KEYLEN: 44 AVGLRECL: 435 BUFSPACE: 530432 CISIZE: 12288 RKP: 0  
   MAXLRECL: 2040 EXCPEXIT: (NULL) CI/CA: 60 SHROPTNS(3,3)
SPEED UNIQUE NOERASE INDEXED NOWRITECHK UNORDERED  
NOREUSE NONSPANNED

If your MCDS is not SMS-managed, then I would suggest allocating the maximum 
CYLS(5825 0) for the MCDS data component, which will allow the MCDS to reach as 
close to the VSAM 4 GB limit as possible while still allocating in CYLS instead 
of TRKS. Something close to 'CYLS(30 0)' should be sufficient for the MCDS 
index component. I would also suggest devoting an entire MOD-9 to the MCDS to 
avoid contention for the volume.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Tuesday, February 22, 2022 7:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Resizing MCDS

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Classification: Confidential

Essentially yes. HSM must be down for the duration.

I would also rename the original to .old and the new to the original name. A 
lot of JCL would need to be changed otherwise.
Of course take backups.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter
Sent: Tuesday, February 22, 2022 3:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Resizing MCDS

[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.]

Hello

Apologize for basic question

Whats your approach on resizing HSM MCDS ?

is it just defining MCDS, Rename, repro old to new and start HSM task ?

Peter

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

Re: DC4 abend - R15=91040120

[Pierre Fichaud]

Tom, OK, I'll go with that.
The call was made to the system, IARCP64, in batch.

Thanks, Pierre.

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

Re: 2.5 Heads Up

[Charles Mills]

"Low-address protection is under control of bit 35 of
control register 0, the low-address-protection-control
bit. When the bit is zero, low-address protection is off;
when the bit is one, low-address protection is on."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Tuesday, February 22, 2022 10:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

Right ...

Is there a control register bit or something like that for authority to
store in the PSA (+ Key 0 of course).

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lennie Dymoke-Bradshaw
Sent: Tuesday, February 22, 2022 9:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

There will be multiple versions of that address for PSA for each active
processor in the LPAR.
I don't think that KEY 0 is adequate authority to store there either. Could
be done from a hardware console though.

--
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: DC4 abend - R15=91040120

[Steve Beaver]

Pierre it's been a while.

What is the 0401 coming out of?  CICS, the SYSTEM??




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pierre Fichaud
Sent: Tuesday, February 22, 2022 12:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DC4 abend - R15=91040120

91040120 - The 0401 is not documented.
Can someone provide me with an explanation please ?
The lowest value documented is 0410.

Thanks in advance, Pierre.

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

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

Re: DC4 abend - R15=91040120

[Tom Harper]

I believe your MEMLIMIT was exceeded. 

Tom Harper
Phoenix Software International 

Sent from my iPhone

> On Feb 22, 2022, at 1:36 PM, Pierre Fichaud  wrote:
> 
> 91040120 - The 0401 is not documented.
> Can someone provide me with an explanation please ?
> The lowest value documented is 0410.
> 
> Thanks in advance, Pierre.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


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

DC4 abend - R15=91040120

[Pierre Fichaud]

91040120 - The 0401 is not documented.
Can someone provide me with an explanation please ?
The lowest value documented is 0410.

Thanks in advance, Pierre.

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

Re: 2.5 Heads Up

[Charles Mills]

Right ...

Is there a control register bit or something like that for authority to
store in the PSA (+ Key 0 of course).

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lennie Dymoke-Bradshaw
Sent: Tuesday, February 22, 2022 9:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

There will be multiple versions of that address for PSA for each active
processor in the LPAR.
I don't think that KEY 0 is adequate authority to store there either. Could
be done from a hardware console though.

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

Re: 2.5 Heads Up

[Lennie Dymoke-Bradshaw]

There will be multiple versions of that address for PSA for each active
processor in the LPAR.
I don't think that KEY 0 is adequate authority to store there either. Could
be done from a hardware console though.

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
Charles Mills
Sent: 22 February 2022 15:27
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

Would using some "debug" type utility to store a non-zero value at address 4
be a partial circumvention?

The pre-Z restart PSW is never used for anything now -- is that correct?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Mulder
Sent: Monday, February 21, 2022 10:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

  Location 4 means address 4 (i.e. offset 4 in the PSA). 

 There was a latent bug from a prior release in the loop control code so
that it was erroneously fetching from address 4, and behaving especially
badly when the data at that location is x'', which it is as of z/OS
2.5.  In prior releases, it was x'000130E1' when in zArchitecture mode.
 

--
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: Resizing MCDS

[Michael Watkins]

I heartily agree that SMS-management and RLS is the preferred way to define all 
DFSMShsm CDSs. I made the rash assumption that Peter simply need to resize the 
MCDS in the near future instead of making a project out of it by defining the 
required coupling facility structures and making the DFSMShsm CDSs SMS-managed. 
Can the MCDS exceed the 4 GB limit without SMS-management? From the following 
discussion, it appears it can be:

See: https://www.zmainframes.com/viewtopic.php?t=2009

'Over coming the 4 GB limit of VSAM.', Mon Feb 22, 2016 6:29 pm, Robert Sample: 
 If you read the manual on DEFINE CLUSTER, you will discover that the manual 
EXPLICITLY states that DATACLASS can be used for SMS or non-SMS managed 
storage. Yes, it is part of SMS but it can also be used outside SMS.

Sat Feb 27, 2016 6:00 pm, Angel:  I have suggested to use the Extended  Format 
(VSAM EF) files. As I read about them, they allow to add an extra 32 control 
bytes to each data block. But they need to be DFSMS managed. It seems to solve 
the problem. So even if a DATACLASS is also given the restriction of 4GB 
anyways remains, right?

Sat Feb 27, 2016 7:42 pm, Robert Sample:  This is another reason you REALLY 
need to talk to your site support group. If the DATACLASS given does not 
support VSAM extended format (a DATACLASS can be used for different reasons), 
then yes the 4 GB limit still applies. Only someone working at your site can 
provide you with the site-specific information you need on how to get your VSAM 
data set to go past 4 GB; we can only say that yes it can be done.

Wed May 04, 2016 4:42 pm, Angel:  We ended up using 4 GB limit, as going beyond 
that was not recommended by the policies.

Thu May 05, 2016 1:22 am, Robert Sample:  Policies often wind up being in 
effect long after they should have been changed.  I've used a number of VSAM 
linear and KSDS data sets as large as 60 GB with no problems; a policy against 
them makes less and less sense as time passes.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Nigel Morton
Sent: Tuesday, February 22, 2022 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Resizing MCDS

I would suggest using extended addressability VSAM to avoid the 4GB limit as 
well as considering multi-cluster CDSs (for MCDS and BCDS, don't think it is 
supported for the OCDS). I'd also recommend using RLS as I've seen it speed up 
long-running HSM functions significantly.

Both extended addressability and RLS for HSM CDSs have been around for several 
years.

On Tue, 22 Feb 2022 at 15:50, Michael Watkins < 
032966e74d0f-dmarc-requ...@listserv.ua.edu> wrote:

Yes, all DFSMShsm ASIDs in the HSMplex must be down. (All DFSMShsm ASIDs that 
share control datasets and a journal are in the same HSMplex.) I would rename 
the existing MCDS by appending the current date [either '.#22feb22' or 
'.#22053' (Julian date) for today, for example] to the index and data component 
names as well as to the cluster name. By including the date last used in the 
new dataset name, there will be less question of what the cluster is when you 
don't delete it and someone else is looking at it next year and wondering if 
they can reclaim the space.

First, After renaming the MCDS, I would then define the new (presumably larger) 
MCDS with the old name by using the MODEL parameter and changing only the CYLS 
for both the data and index components to (x 0). By using the same MCDS name, 
no JCL will have to be changed. No secondary should be allocated to any of the 
DFSMShsm control datasets when they are shared by DFSMShsm ASIDs on different 
LPARs, unless the DFSMShsm CDSs are managed with RLS (Record Level Sharing).

Second, REPRO the old '.#yyddd' MCDS into the new MCDS.

Third, restart DFSMShsm on all LPARs, one at a time. Done.

Let's assume your MCDS's characteristics are:
KEYLEN: 44 AVGLRECL: 435 BUFSPACE: 530432 CISIZE: 12288  RKP: 0 
MAXLRECL: 2040 EXCPEXIT: (NULL) CI/CA: 60 SHROPTNS(3,3)
SPEED UNIQUE NOERASE INDEXED NOWRITECHK UNORDERED 
NOREUSE NONSPANNED

If your MCDS is not SMS-managed, then I would suggest allocating the maximum 
CYLS(5825 0) for the MCDS data component, which will allow the MCDS to reach as 
close to the VSAM 4 GB limit as possible while still allocating in CYLS instead 
of TRKS. Something close to 'CYLS(30 0)'  should be sufficient for the MCDS 
index component. I would also suggest devoting an entire MOD-9 to the MCDS to 
avoid contention for the volume.

> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Allan Staller
> Sent: Tuesday, February 22, 2022 7:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Resizing MCDS
>
Essentially yes. HSM must be down for the duration.

I would also rename the original to .old and the new to the original name. A 
lot of JCL would need to be changed otherwise. Of course take backups.

HTH,
>
> -Original Message-
> From: 

DSENQSHR (was: 2.5 Heads Up)

[Paul Gilmartin]

On Tue, 22 Feb 2022 02:03:21 -0400, Jim Mulder \wrote:

>  Location 4 means address 4 (i.e. offset 4 in the PSA). 
>
> There was a latent bug from a prior release in the loop control 
>code so that it was erroneously fetching from address 4, and 
>behaving especially badly when the data at that location 
>is x'', which it is as of z/OS 2.5.  In prior releases,
>it was x'000130E1' when in zArchitecture mode.
>  
Thanks.

I like the suggestion of ignoring the content of location 4 and proceeding
with the constant value x'000130E1'.

Historians tell me that in the earliest days of OS/360 et al. ENQs established
by initiators were simply held until job termination.  Is that correct?

Later, the behavior was changed to DEQ after the last step mentioning
each DSN.  I don't see that this was ever optional; it was unconditional.

Why was the DSENQSHR behavior similarly made unconditional,
avoiding the need for the 3×3 matrix in


Often, the cost of complexity outweighs the value of flexibility.
Particularly, what is the value to customers in providing JES2 JOBCLASS
sensitivity rather than only a simple binary option on the JOB statement?

-- 
Thanks again,
gil

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

Re: Resizing MCDS

[Nigel Morton]

I would suggest using extended addressability VSAM to avoid the 4GB limit
as well as considering multi-cluster CDSs (for MCDS and BCDS, don't think
it is supported for the OCDS). I'd also recommend using RLS as I've seen it
speed up long-running HSM functions significantly.

Both extended addressability and RLS for HSM CDSs have been around for
several years.

On Tue, 22 Feb 2022 at 15:50, Michael Watkins <
032966e74d0f-dmarc-requ...@listserv.ua.edu> wrote:

> Yes, all DFSMShsm ASIDs in the HSMplex must be down. (All DFSMShsm ASIDs
> that share control datasets and a journal are in the same HSMplex.) I would
> rename the existing MCDS by appending the current date [either '.#22feb22'
> or '.#22053' (Julian date) for today, for example] to the index and data
> component names as well as to the cluster name. By including the date last
> used in the new dataset name, there will be less question of what the
> cluster is when you don't delete it and someone else is looking at it next
> year and wondering if they can reclaim the space.
>
> First, I would then define the new (presumably larger) MCDS with the old
> name by using the MODEL parameter and changing only the CYLS for both the
> data and index components to (x 0). By using the same MCDS name, no JCL
> will have to be changed. No secondary should be allocated to any of the
> DFSMShsm control datasets when they are shared by DFSMShsm ASIDs on
> different LPARs, unless the DFSMShsm CDSs are managed with RLS (Record
> Level Sharing).
>
> Second, REPRO the old '.#yyddd' MCDS into the new MCDS.
>
> Third, restart DFSMShsm on all LPARs, one at a time. Done.
>
> Let's assume your MCDS's characteristics are:
>
> KEYLEN: 44 AVGLRECL: 435 BUFSPACE: 530432 CISIZE: 12288
>  RKP: 0 MAXLRECL: 2040 EXCPEXIT: (NULL) CI/CA: 60
>  SHROPTNS(3,3)
> SPEED UNIQUE NOERASE INDEXED NOWRITECHK UNORDERED
> NOREUSE NONSPANNED
>
> If your MCDS is not SMS-managed, then I would suggest allocating the
> maximum CYLS(5825 0) for the MCDS data component, which will allow the MCDS
> to reach as close to the VSAM 4 GB limit as possible while still allocating
> in CYLS instead of TRKS. Something close to 'CYLS(30 0)' should be
> sufficient for the MCDS index component. I would also suggest devoting an
> entire MOD-9 to the MCDS to avoid contention for the volume.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Allan Staller
> Sent: Tuesday, February 22, 2022 7:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Resizing MCDS
>
> CAUTION: This email originated from outside of the Texas Comptroller's
> email system.
> DO NOT click links or open attachments unless you expect them from the
> sender and know the content is safe.
>
> Classification: Confidential
>
> Essentially yes. HSM must be down for the duration.
>
> I would also rename the original to .old and the new to the original name.
> A lot of JCL would need to be changed otherwise.
> Of course take backups.
>
> HTH,
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Peter
> Sent: Tuesday, February 22, 2022 3:57 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Resizing MCDS
>
> [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.]
>
> Hello
>
> Apologize for basic question
>
> Whats your approach on resizing HSM MCDS ?
>
> is it just defining MCDS, Rename, repro old to new and start HSM task ?
>
> Peter
>
> --
> 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.
> 
>
> 

Re: 2.5 Heads Up

[Charles Mills]

Interesting question, but the problem at hand is pure z/OS.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Tuesday, February 22, 2022 7:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

Do any of z/TPF, z/VM or z/VSE ever run in ESA mode?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Charles Mills [charl...@mcn.org]
Sent: Tuesday, February 22, 2022 10:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

Would using some "debug" type utility to store a non-zero value at address 4
be a partial circumvention?

The pre-Z restart PSW is never used for anything now -- is that correct?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Mulder
Sent: Monday, February 21, 2022 10:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

  Location 4 means address 4 (i.e. offset 4 in the PSA).

 There was a latent bug from a prior release in the loop control
code so that it was erroneously fetching from address 4, and
behaving especially badly when the data at that location
is x'', which it is as of z/OS 2.5.  In prior releases,
it was x'000130E1' when in zArchitecture mode.


--
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: creating a python login module

[Seymour J Metz]

APF and AC(1) are related in that ATTACH RSAPF=YES only tests the AC if the 
module comes from an authorized concatenation.

Yes, never mark a module as AC(1) unless it is intended to be an authorized 
jobstep program or an authorized TSO command.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Erik Janssen [eaw.jans...@gmail.com]
Sent: Tuesday, February 22, 2022 10:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: creating a python login module

Yes, I think I understand that now. It was only recently that I found out the 
APF and AC(1) are even sort of unrelated in a way. I always though that any 
module performing authorized functionality had to be linked AC(1), but I found 
that only main routines should be linked AC(1) and that it can even be 
dangerous to link a module that is not intended to be called as a main routine 
AC(1).


On Tue, 22 Feb 2022 15:12:35 +, Seymour J Metz  wrote:

>APF AC(1), program control and UID(0) are mutually unrelated.
>
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>Erik Janssen [eaw.jans...@gmail.com]
>Sent: Monday, February 21, 2022 3:59 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: creating a python login module
>
>Well, the routine I wrote can handle a user, password or passphrase and 
>optionally an APPL to verify against.
>So, even though there are a lot of options to do it different, I was more 
>looking for ways how such a 'service routine' that needs apf authorization 
>could be used from a non-authorized caller.
>The __passwd routine can do it, but it requires program controlled environment 
>and python doesn't seem to be defined as program controlled and I don't want 
>to 'just' enable it.
>Also, the relation between APF authorisation and program control (if any) 
>still eludes me, and if there is no relation then I don't understand how 
>__passwd can check a password if the environment is not apf authorized.
>I hope that someone can explain how that works.
>
>Kind regards,
>Erik.
>
>On Mon, 21 Feb 2022 15:10:48 +, Colin Paice  wrote:
>
>>Erik,
>>
>>Do you need to specify a password?
>>
>>Could you define a RACF profile  instead, and use RACF  check to see if the
>>userid has access to that profile?
>>I dont think there is a Callable function for it, but you could write some
>>glue code to call an assembler routine to do a RACROUTE call.
>>
>>You could use an existing class, such as APP.
>>I dont think it needs to be APF authorised... but you would need to check
>>this.
>>
>>Colin
>>
>
>--
>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: 2.5 Heads Up

[Seymour J Metz]

Do any of z/TPF, z/VM or z/VSE ever run in ESA mode?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Tuesday, February 22, 2022 10:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

Would using some "debug" type utility to store a non-zero value at address 4
be a partial circumvention?

The pre-Z restart PSW is never used for anything now -- is that correct?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Mulder
Sent: Monday, February 21, 2022 10:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

  Location 4 means address 4 (i.e. offset 4 in the PSA).

 There was a latent bug from a prior release in the loop control
code so that it was erroneously fetching from address 4, and
behaving especially badly when the data at that location
is x'', which it is as of z/OS 2.5.  In prior releases,
it was x'000130E1' when in zArchitecture mode.


--
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: Resizing MCDS

[Michael Watkins]

Yes, all DFSMShsm ASIDs in the HSMplex must be down. (All DFSMShsm ASIDs that 
share control datasets and a journal are in the same HSMplex.) I would rename 
the existing MCDS by appending the current date [either '.#22feb22' or 
'.#22053' (Julian date) for today, for example] to the index and data component 
names as well as to the cluster name. By including the date last used in the 
new dataset name, there will be less question of what the cluster is when you 
don't delete it and someone else is looking at it next year and wondering if 
they can reclaim the space.

First, I would then define the new (presumably larger) MCDS with the old name 
by using the MODEL parameter and changing only the CYLS for both the data and 
index components to (x 0). By using the same MCDS name, no JCL will have to be 
changed. No secondary should be allocated to any of the DFSMShsm control 
datasets when they are shared by DFSMShsm ASIDs on different LPARs, unless the 
DFSMShsm CDSs are managed with RLS (Record Level Sharing).

Second, REPRO the old '.#yyddd' MCDS into the new MCDS.

Third, restart DFSMShsm on all LPARs, one at a time. Done.

Let's assume your MCDS's characteristics are:

KEYLEN: 44 AVGLRECL: 435 BUFSPACE: 530432 CISIZE: 12288 RKP: 0  
   MAXLRECL: 2040 EXCPEXIT: (NULL) CI/CA: 60 SHROPTNS(3,3)
SPEED UNIQUE NOERASE INDEXED NOWRITECHK UNORDERED  
NOREUSE NONSPANNED

If your MCDS is not SMS-managed, then I would suggest allocating the maximum 
CYLS(5825 0) for the MCDS data component, which will allow the MCDS to reach as 
close to the VSAM 4 GB limit as possible while still allocating in CYLS instead 
of TRKS. Something close to 'CYLS(30 0)' should be sufficient for the MCDS 
index component. I would also suggest devoting an entire MOD-9 to the MCDS to 
avoid contention for the volume. 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: Tuesday, February 22, 2022 7:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Resizing MCDS

CAUTION: This email originated from outside of the Texas Comptroller's email 
system.
DO NOT click links or open attachments unless you expect them from the sender 
and know the content is safe.

Classification: Confidential

Essentially yes. HSM must be down for the duration.

I would also rename the original to .old and the new to the original name. A 
lot of JCL would need to be changed otherwise.
Of course take backups.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter
Sent: Tuesday, February 22, 2022 3:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Resizing MCDS

[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.]

Hello

Apologize for basic question

Whats your approach on resizing HSM MCDS ?

is it just defining MCDS, Rename, repro old to new and start HSM task ?

Peter

--
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: creating a python login module

[Erik Janssen]

Yes, I think I understand that now. It was only recently that I found out the 
APF and AC(1) are even sort of unrelated in a way. I always though that any 
module performing authorized functionality had to be linked AC(1), but I found 
that only main routines should be linked AC(1) and that it can even be 
dangerous to link a module that is not intended to be called as a main routine 
AC(1).


On Tue, 22 Feb 2022 15:12:35 +, Seymour J Metz  wrote:

>APF AC(1), program control and UID(0) are mutually unrelated.
>
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>Erik Janssen [eaw.jans...@gmail.com]
>Sent: Monday, February 21, 2022 3:59 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: creating a python login module
>
>Well, the routine I wrote can handle a user, password or passphrase and 
>optionally an APPL to verify against.
>So, even though there are a lot of options to do it different, I was more 
>looking for ways how such a 'service routine' that needs apf authorization 
>could be used from a non-authorized caller.
>The __passwd routine can do it, but it requires program controlled environment 
>and python doesn't seem to be defined as program controlled and I don't want 
>to 'just' enable it.
>Also, the relation between APF authorisation and program control (if any) 
>still eludes me, and if there is no relation then I don't understand how 
>__passwd can check a password if the environment is not apf authorized.
>I hope that someone can explain how that works.
>
>Kind regards,
>Erik.
>
>On Mon, 21 Feb 2022 15:10:48 +, Colin Paice  wrote:
>
>>Erik,
>>
>>Do you need to specify a password?
>>
>>Could you define a RACF profile  instead, and use RACF  check to see if the
>>userid has access to that profile?
>>I dont think there is a Callable function for it, but you could write some
>>glue code to call an assembler routine to do a RACROUTE call.
>>
>>You could use an existing class, such as APP.
>>I dont think it needs to be APF authorised... but you would need to check
>>this.
>>
>>Colin
>>
>
>--
>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: 2.5 Heads Up

[Charles Mills]

Would using some "debug" type utility to store a non-zero value at address 4
be a partial circumvention?

The pre-Z restart PSW is never used for anything now -- is that correct?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Mulder
Sent: Monday, February 21, 2022 10:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

  Location 4 means address 4 (i.e. offset 4 in the PSA). 

 There was a latent bug from a prior release in the loop control 
code so that it was erroneously fetching from address 4, and 
behaving especially badly when the data at that location 
is x'', which it is as of z/OS 2.5.  In prior releases,
it was x'000130E1' when in zArchitecture mode.
 

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

Re: creating a python login module

[Seymour J Metz]

APF AC(1), program control and UID(0) are mutually unrelated.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Erik Janssen [eaw.jans...@gmail.com]
Sent: Monday, February 21, 2022 3:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: creating a python login module

Well, the routine I wrote can handle a user, password or passphrase and 
optionally an APPL to verify against.
So, even though there are a lot of options to do it different, I was more 
looking for ways how such a 'service routine' that needs apf authorization 
could be used from a non-authorized caller.
The __passwd routine can do it, but it requires program controlled environment 
and python doesn't seem to be defined as program controlled and I don't want to 
'just' enable it.
Also, the relation between APF authorisation and program control (if any) still 
eludes me, and if there is no relation then I don't understand how __passwd can 
check a password if the environment is not apf authorized.
I hope that someone can explain how that works.

Kind regards,
Erik.

On Mon, 21 Feb 2022 15:10:48 +, Colin Paice  wrote:

>Erik,
>
>Do you need to specify a password?
>
>Could you define a RACF profile  instead, and use RACF  check to see if the
>userid has access to that profile?
>I dont think there is a Callable function for it, but you could write some
>glue code to call an assembler routine to do a RACROUTE call.
>
>You could use an existing class, such as APP.
>I dont think it needs to be APF authorised... but you would need to check
>this.
>
>Colin
>

--
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: XEDIT equivalent to ISPF C - OO/OO (copy overlay)

[Seymour J Metz]

A combination of C and O or CC and OO with equal size blocks may be easy on a 
TN3270 client with support for block C, but is there a TN3270 client that 
will replicate the source if it is smaller than the target? I quite commonly 
mark a single lline with C and multiple lines with oo, or mark a short block 
with cc and a long block with oo.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Harminc [t...@harminc.net]
Sent: Monday, February 21, 2022 4:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XEDIT equivalent to ISPF C - OO/OO (copy overlay)

On Mon, 21 Feb 2022 at 15:32, Phil Smith III  wrote:

> Binyamin Dissen wrote:
>
> >I am referring to the function where you type C on a line that has the
> overlay
> >data and then OO/OO on the group of lines that you wish to overlay. The
> only
> >dependence on the data on the OO lines is that it will not replace a
> >non-blank.
>
> I've used XEDIT since it was released, KEDIT equally, and neither has this
> direct analog. I have also never actually *WANTED* it, which is not to
> dismiss your requirement-just to note that it may not be that common.
>

I use it all the time to put change markers on new lines. Of course with a
decent TN3270 program you can probably just as easily copy & paste them in
at that level.

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: 2.5 Heads Up

[Seymour J Metz]

Yes. From PoOps:

In the z/Architecture architectural mode, a restart
interruption causes the old PSW to be stored at real
locations 288-303 and a new PSW, designating the
start of the program to be executed, to be fetched
from real locations 416-431. In the ESA/390-compat-
ibility mode, a restart interruption causes the short-
format old PSW to be stored at real locations 8-15
and a short-format new PSW to be fetched from real
locations 0-7. The instruction-length code and inter-
ruption code are not stored.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Lennie Dymoke-Bradshaw [032fff1be9b4-dmarc-requ...@listserv.ua.edu]
Sent: Monday, February 21, 2022 6:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

Maybe they were using the contents of location 4 instead of a 4?
e.g.   LA R5,4   vs   LA R5,4(,R5)
I think location 4 used to be part of the Restart new PSW under old-style 
31-bit operation. Maybe it is no longer used.

Lennie Dymoke-Bradshaw
https://secure-web.cisco.com/1yM40BYyhO9Myr1uDKTVftC_rDZJWU453aYsRt9-vIEFTQYNIqirIxHqlI61L2K7SdEN0zik2mOy1aqNvlhQcoOkidpY1wkqosg98Pmz5RabR9xPu_PXCJjeBvz-clWpmlz8RNW7gJOF6oQTvgR1EVcCemVzoOeYnVvryaKMnaayMjfciNOpGVwbG993h01ccRjrmWmFmdkraas9yWAR_kvJBqL2jqfhy3nNk5FWGmMMeYmuE1nfi_8n8ZWk9MU0_-_XVc205oR5H4lrZ6kBEjpXIKrCOrkKEve-L8PlsRhVDeFE-rLIvfT6uIfrjP0rAwaUHoXqGcxxJC-4U_n1KXliXCiWMK71XinXhzVn6bdGFanQynXe7uSYxhK332leWBVhxXMw5RwS0-FLQLm274Ee4st6Nj1Cuj2HYDNs57Y6aknPmBjpJM4FmjlAW53iD/https%3A%2F%2Frsclweb.com
‘Dance like no one is watching. Encrypt like everyone is.’


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: 21 February 2022 22:03
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2.5 Heads Up

On Mon, 21 Feb 2022 12:54:14 -0800, Ed Jaffe wrote:

>On 2/21/2022 12:00 PM, Mark Jacobs wrote:
>> Found APAR OA62381 for this problem. PTFs are not yet available.
>
Yet: APAR status
Closed as program error.

>Hugely helpful! THANKS!
>
>https://www.ibm.com/support/pages/apar/OA62381
>
Local fix
BYPASS/CIRCUMVENTION:
Set DSENQSHR to DISALLOW in the relevant JOBCLASSes

Doesn't that just say, "Don't do that!"?  Hardly a circumvention.

if the storage at location x'0004' is zeroed out.

What's llocation 4 supposed to mean?

-- 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: Resizing MCDS

[Allan Staller]

Classification: Confidential

Essentially yes. HSM must be down for the duration.

I would also rename the original to .old and the new to the original name. A 
lot of JCL would need to be changed otherwise.
Of course take backups.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter
Sent: Tuesday, February 22, 2022 3:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Resizing MCDS

[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.]

Hello

Apologize for basic question

Whats your approach on resizing HSM MCDS ?

is it just defining MCDS, Rename, repro old to new and start HSM task ?

Peter

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

Why SLIP PVTMOD/PVT EP does not work for Private load modules in CICS

[Peter Relson]

If a program does "LOAD with ADDR" (AKA "directed load") there are no 
residual system control blocks (such as CDEs).
I'd guess that that is what CICS does. If so, they do use system services 
to load the module but they provide and manage the storage.

When that is done, there is no way for SLIP or anything other than the 
provider of the storage to understand where the module is.

Peter Relson
z/OS Core Technology Design


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

Re: Resizing MCDS

[David Purdy]

Peter, hsm also includes tools to analyze and split an MCDS as well.  You have 
to decide how many.
In our case, I have three, and I use your method to do reorgs plus try to repro 
evenly across all three.
David


-Original Message-
From: Gadi Ben-Avi 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tue, Feb 22, 2022 5:22 am
Subject: Re: Resizing MCDS

That's what I've been doing.
I use sort to copy, and do the rename after the copy, but it general it's the 
same process.

Gadi

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter
Sent: Tuesday, February 22, 2022 11:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Resizing MCDS

Hello

Apologize for basic question

Whats your approach on resizing HSM MCDS ?

is it just defining MCDS, Rename, repro old to new and start HSM task ?

Peter

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

Email secured by Check Point

--
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 a python login module

[Erik Janssen]

In addition to my own post, of course for the actual PADS functionality, where 
you allow a different access to a dataset if a certain program is doing the 
open it also makes sense that you only want to do that if you can make sure 
that this 'certain program' is actual the one you intended to give the access 
and not some rogue program that was just named likewise in an untrusted 
library. So I didn't want to imply that identity changing is the only 'use 
case' for program control.

On Tue, 22 Feb 2022 04:30:49 -0600, Erik Janssen  wrote:

>Thanks for the pointers! Very interesting, I never realized that the ZSS part 
>was also open source and written in metal C. I've so far only seen very 
>minimal examples of using metal C, so I will look into the code!
>It seems that ZOWE also has the approach to have a PC service that runs the 
>authorized code, so I guess my initial feeling was correct that this is the 
>correct 'pattern' to provide authorized services to an unauthorized (yet 
>perhaps 'program controlled') backend. The program control seems to be a 
>specialization of that 'pattern', where you might decide that the only 
>'clients' of your authorized PC service can be programs that have been loaded 
>from a 'controlled environment'. This mainly seems to have been focused on 
>services that allow the identify of the invoker to change like the 
>pthread_security_np() call, which seems to make sense that you would only want 
>to allow that to happen if you know where the module that wants to do that was 
>loaded from.
>I will see if I can get slack up and running :-)
>
>Kind Regards,
>Erik. 
>
>

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

Re: Resizing MCDS

[Dejan Stamatovic]

Hello Peter,

Your approch to the matter applies to resizing any VSAM KSDS data set.
Just make it simple, do not over think.

Your method is probably the best even though it has been used for ages.

I wish there was some new method to do the same as with this method you must 
shut down HSM.

Dejan Stamatovic
CROZ DOO

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

Re: creating a python login module

[Erik Janssen]

Thanks for the pointers! Very interesting, I never realized that the ZSS part 
was also open source and written in metal C. I've so far only seen very minimal 
examples of using metal C, so I will look into the code!
It seems that ZOWE also has the approach to have a PC service that runs the 
authorized code, so I guess my initial feeling was correct that this is the 
correct 'pattern' to provide authorized services to an unauthorized (yet 
perhaps 'program controlled') backend. The program control seems to be a 
specialization of that 'pattern', where you might decide that the only 
'clients' of your authorized PC service can be programs that have been loaded 
from a 'controlled environment'. This mainly seems to have been focused on 
services that allow the identify of the invoker to change like the 
pthread_security_np() call, which seems to make sense that you would only want 
to allow that to happen if you know where the module that wants to do that was 
loaded from.
I will see if I can get slack up and running :-)

Kind Regards,
Erik. 


On Tue, 22 Feb 2022 08:35:50 +0800, David Crayford  wrote:

>On 22/2/22 4:59 am, Erik Janssen wrote:
>> Well, the routine I wrote can handle a user, password or passphrase and 
>> optionally an APPL to verify against.
>> So, even though there are a lot of options to do it different, I was more 
>> looking for ways how such a 'service routine' that needs apf authorization 
>> could be used from a non-authorized caller.
>> The __passwd routine can do it, but it requires program controlled 
>> environment and python doesn't seem to be defined as program controlled and 
>> I don't want to 'just' enable it.
>
>Program Control can be a PITA, but APF authorizing a service is a bag of
>worms.
>
>> Also, the relation between APF authorisation and program control (if any) 
>> still eludes me, and if there is no relation then I don't understand how 
>> __passwd can check a password if the environment is not apf authorized.
>> I hope that someone can explain how that works.
>
>AFAIK, there is no relationship. I've very leery when I see a z/OS UNIX
>program APF authorized.
>
>Zowe has a couple of components you may be interested in. All APF
>authorized services are processed in the ZIS server, otherwise nown as
>the cross-memory server. It's a Metal/C application that is open source
>an available to
>Github. It provides services via PC calls which are exploited by the ZSS
>server which is a lightweight HTTP server written in C. Both have tiny
>footprints and you can write your own plugins. SAF
>authentication/authorization are
>already provided.
>
>Disclaimer: I'm a Zowe commiter and I mainly work on these components.
>Although only for code reviews, we have devs working full time on Zowe.
>
>https://docs.zowe.org/stable/getting-started/zowe-architecture/
>https://github.com/zowe/zss
>
>BTW, building this stuff can be tricky. You can reach out on the
>OpenMainframe slack channel and one of our helpful devs can assist you.
>Or just ping me offline.
>
>
>>

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

Re: Resizing MCDS

[Gadi Ben-Avi]

That's what I've been doing.
I use sort to copy, and do the rename after the copy, but it general it's the 
same process.

Gadi

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter
Sent: Tuesday, February 22, 2022 11:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Resizing MCDS

Hello

Apologize for basic question

Whats your approach on resizing HSM MCDS ?

is it just defining MCDS, Rename, repro old to new and start HSM task ?

Peter

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

Email secured by Check Point

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

Resizing MCDS

[Peter]

Hello

Apologize for basic question

Whats your approach on resizing HSM MCDS ?

is it just defining MCDS, Rename, repro old to new and start HSM task ?

Peter

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