Re: Dumb SDSF question

[Rob Scott]

For SDSF displays that can contain sysplex wide data (gathered using a SYSNAME 
pattern and XCF services), each row contains the syslevel as it could be 
different for each member of the sysplex.

Note that JES2 panels (eg ST and H) are typically have a MAS scope, so the data 
is gathered locally and not routed via XCF.

Rob Scott
Rocket Software

Get Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
Phil Smith III 
Sent: Thursday, July 18, 2024 10:32:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Dumb SDSF question

EXTERNAL EMAIL




Poking around in SDSF today, I scrolled all the way to the right and found:

SysLevel
z/OS 02.04.00 HBB77C0
z/OS 02.04.00 HBB77C0
z/OS 02.04.00 HBB77C0
(etc.)

Why is this listed for each running task? Wild guess: in a SYSPLEX/JESPLEX (and 
no, I don’t understand the difference between those) the levels could vary. Is 
that it? Googling didn’t help me, alas:
sdsf "sysplex"
gets a total of 20 hits. Though one of those:
https://bit.listserv.ibm-main.narkive.com/viUMTwqk/why-does-sdsf-st-only-show-current-jesplex-jobs<https://bit.listserv.ibm-main.narkive.com/viUMTwqk/why-does-sdsf-st-only-show-current-jesplex-jobs>
certainly suggests that it’s seeing the whole SYSPLEX, which led to my 
conjecture.

TIA

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


Rocket Software, Inc. and subsidiaries ¦ 77 Fourth Avenue, Waltham MA 02451 ¦ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: z/OS 3.1 Enhancements & Support News

[Rob Scott]

Steve,

The current big advantage REXX has is the extensive list of host environments 
available using ADDRESS.

I suspect over time , that python interfaces to many will appear as developers 
can safely assume its presence on the system.

Rob Scott
Rocket Software

Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
Steve Horein <05b0b4f1358b-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, June 29, 2024 2:03:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: z/OS 3.1 Enhancements & Support News

EXTERNAL EMAIL





I don't mind flaunting my ignorance, but does python on z provide access to
other functions and programs?
In other words, what are the python equivalents for things like:
attach
attchmvs
attchpgm
bcpii
bpxwunix
call
dsnrexx
ftpapi
irrxutil
link
linkmvs
linkpgm


Is there a python/rexx mapping (official or otherwise) similar to JES2/JES3
command mapping?

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



Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: z/OS 3.1 Enhancements & Support News

[Rob Scott]

Definitely 31bit.

See the IRXSHVB data area mapping (used by the REXX variables access interface).

Rob Scott
Rocket Software

Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, June 29, 2024 9:51:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: z/OS 3.1 Enhancements & Support News

EXTERNAL EMAIL




"REXX variables are limited to 31-bit storage"

Is it really 31-bit or rather 24-bit?

I'm asking because many moons ago I tried to use some REXX variables
coming from RMM and due to large number of tape volumes (~25000) the
script did not work. I asked on IBM-MAIN and people here explained it is
because of 24-bit memory limitation.
I vaguely remember it could be OS/390 2.10

--
Radoslaw Skorupka
Lodz, Poland



W dniu 29.06.2024 o 07:52, Rob Scott pisze:
> I have been using REXX for over 30 years and I pretty much agree with 
> everything Dave says here.
>
> Having Python " automatically there " on a customer system will make it used 
> much more frequently by IBM, ISV and public domain software.
>
> REXX has always had some big pluses :
>
> 1. It is not CLIST
> 2. The ADDRESS host environment feature
> 3. Some nice parser functions compared to what else was around in late 1980s.
>
> It is an easy scripting language for ad-hoc solutions and product invocation 
> drivers, but it is so limited in features, performance and scalability 
> compared to Python. The fact that REXX variables are limited to 31-bit 
> storage is a very real constraint that is most likely not going to change.
>
> Migration away from REXX will happen slowly, but it will happen and we should 
> embrace it.
>
> Rob Scott
> Rocket Software
>
> Sent from Outlook for Android<https://aka.ms/AAb9ysg<https://aka.ms/AAb9ysg>>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> David Crayford <0595a051454b-dmarc-requ...@listserv.ua.edu>
> Sent: Friday, June 28, 2024 10:07:17 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: z/OS 3.1 Enhancements & Support News
>
> EXTERNAL EMAIL
>
>
>
>
>
>> Even before Python or Java emerged, opting for offloads to zIIPs was a 
>> better choice.
> I meant to say "Even before Python emerged on z/OS, opting for offloads to 
> zIIPs was a better choice utilizing the JVM.
>
>> On 29 Jun 2024, at 5:01 AM, David Crayford  wrote:
>>
>> Even before Python or Java emerged, opting for offloads to zIIPs was a 
>> better choice.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> 
> Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
> Main Office Toll Free Number: +1 855.577.4323
> Contact Customer Support: 
> https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport<https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport>
> Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
> http://www.rocketsoftware.com/manage-your-email-preferences<http://www.rocketsoftware.com/manage-your-email-preferences>
> Privacy Policy - 
> http://www.rocketsoftware.com/company/legal/privacy-policy<http://www.rocketsoftware.com/company/legal/privacy-policy>
> 
>
> This communication and any attachments may contain confidential information 
> of Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
> prohibited. If you are not the intended recipient, please notify Rocket 
> Software immediately and destroy all copies of this communication. Thank you.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: z/OS 3.1 Enhancements & Support News

[Rob Scott]

I have been using REXX for over 30 years and I pretty much agree with 
everything Dave says here.

Having Python " automatically there " on a customer system will make it used 
much more frequently by IBM, ISV and public domain software.

REXX has always had some big pluses :

1. It is not CLIST
2. The ADDRESS host environment feature
3. Some nice parser functions compared to what else was around in late 1980s.

It is an easy scripting language for ad-hoc solutions and product invocation 
drivers, but it is so limited in features, performance and scalability compared 
to Python. The fact that REXX variables are limited to 31-bit storage is a very 
real constraint that is most likely not going to change.

Migration away from REXX will happen slowly, but it will happen and we should 
embrace it.

Rob Scott
Rocket Software

Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
David Crayford <0595a051454b-dmarc-requ...@listserv.ua.edu>
Sent: Friday, June 28, 2024 10:07:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: z/OS 3.1 Enhancements & Support News

EXTERNAL EMAIL





> Even before Python or Java emerged, opting for offloads to zIIPs was a better 
> choice.

I meant to say  "Even before Python emerged on z/OS, opting for offloads to 
zIIPs was a better choice utilizing the JVM.

> On 29 Jun 2024, at 5:01 AM, David Crayford  wrote:
>
> Even before Python or Java emerged, opting for offloads to zIIPs was a better 
> choice.


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



Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SDSF and z/OS V2.5

[Rob Scott]

Note that most customers can avoid using ISFACR and use much simpler tools and 
approaches. The ISFRACEX member of SISFJCL has a very easy starter set of RACF 
statements to setup basic SDSF security and ISFNTCNV in SISFEXEC can help 
convert NTBL statements from ISFPRMxx.

SDSF class security is quite easy to implement,  however customers activating 
OPERCMDS and JESSPOOL have a much larger scale migration ahead.

Rob Scott
Rocket Software.

Get Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
Mark Charles 
Sent: Monday, June 17, 2024 7:17:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SDSF and z/OS V2.5

EXTERNAL EMAIL





Hi Lizette:  even though this manual says it is for conversion to RACF, it can 
also be used to set up a new SDSF:
z/OS SDSF Security Migration Guide

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



Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: As a long-time Rexx programmer (SDSF)

[Rob Scott]

For every z/OS release we also create a "What's new in SDSF" style presentation 
that we give at Share and GSE and then upload to the IBM Education GitHub. 
There is also an in-product help table of new functions for the release.

As for SDSF rexx examples, you can use the RGEN command that will generate 
sample rexx statements to navigate to where you currently are in the product OR 
use "RGEN X" to pick a sample from the supplied list of basic scenarios.

Rob Scott
Rocket Software.

Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu>
Sent: Friday, June 14, 2024 9:02:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: As a long-time Rexx programmer (SDSF)

EXTERNAL EMAIL




Friday, a little bit off-topic, but still about mainframes and SDSF

SDSF is great tool. I was enhanced significantly last years. I like it.
However I observe many users are simply *not aware* of many new features.
They obviously use panels, which are visible in main menu, but they miss
many other tools.
I believe everything is documented, but it is rather rare that someone
read whole documentation as a novel.

Q: is there any presentation or whitepaper describing "new and shining"
things in SDSF?

Regarding SDSF and REXX - I miss simple examples. It is not only
SDSF-related pain. I observe many z/OS users are looking for code
samples via Google search and we find some bad or very bad ones,
submitted on some forums.

My €0.02

Regards
--
Radoslaw Skorupka
Lodz, Poland






W dniu 14.06.2024 o 20:20, Rob Scott pisze:
> I must admit that I find nothing amiss with the quoted section.
>
> It describes the syntax requirements of the SDSF-specific ISFEXEC verb.
>
> It does not get into any generic REXX techniques to provide the statement 
> buffer to the verb as that is not required in this case.
>
> Contrast that with the documentation for ISFSLASH that does include required 
> REXX techniques as it supports alternate input using stem variables.
>
> The product documentation is written by information development team members, 
> but based on input provided by the development team. In this case, that 
> developer (not me) has decades of asm, plx and rexx experience and is fully 
> aware of the nuances of the language.
>
> The documentation will always be updated when required for the current (most 
> recent) release.
>
>
>
> Rob Scott
> Rocket Software
>
> Get Outlook for Android<https://aka.ms/AAb9ysg<https://aka.ms/AAb9ysg>>

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


Rocket Software, Inc. and subsidiaries ¦ 77 Fourth Avenue, Waltham MA 02451 ¦ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: As a long-time Rexx programmer

[Rob Scott]

I must admit that I find nothing amiss with the quoted section.

 It describes the syntax requirements of the SDSF-specific ISFEXEC verb.

It does not get into any generic REXX techniques to provide the statement 
buffer to the verb as that is not required in this case.

 Contrast that with the documentation for ISFSLASH that does include required 
REXX techniques as it supports alternate input using stem variables.

The product documentation is written by information development team members, 
but based on input provided by the development team. In this case, that 
developer (not me) has decades of asm, plx and rexx experience and is fully 
aware of the nuances of the language.

The documentation will always be updated when required for the current (most 
recent) release.



Rob Scott
Rocket Software

Get Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
Phil Smith III 
Sent: Friday, June 14, 2024 5:51:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: As a long-time Rexx programmer

EXTERNAL EMAIL




"If the command contains special characters or blanks, enclose it in single 
quotation marks."

Might not be the best example, but it's clear from the doc that whoever wrote 
it doesn't understand that unassigned Rexx variables return their literal 
values.

Point is, if this is an SDSF special thing, then that isn't clear. If it's 
referring to "Hey, if you want to pass something like
xyz;abc
then you need to either have that in a variable and specify the variable OR put 
it in quotes because that's how Rexx works", then that's different. (And is 
what is pretty clear from some other places in the doc, though perhaps not this 
specific case.)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Scott
Sent: Friday, June 14, 2024 4:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: As a long-time Rexx programmer

Ok I will bite.

Please point out what parts of that extract are "grim" and "embarrassing".

Rob Scott
Rocket Software

Get Outlook for Android<https://aka.ms/AAb9ysg<https://aka.ms/AAb9ysg>> 

From: IBM Mainframe Discussion List  on behalf of 
Lionel B. Dyck <057b0ee5a853-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, June 13, 2024 8:43:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: As a long-time Rexx programmer

EXTERNAL EMAIL




Just be glad we do have a REXX API to invoke SDSF 


Lionel B. Dyck <><
Github: 
https://github.com/lbdyck<https://github.com/lbdyck><https://github.com/lbdyck<https://github.com/lbdyck>>
System Z Enthusiasts Discord: 
https://discord.gg/sze<https://discord.gg/sze><https://discord.gg/sze<https://discord.gg/sze>>

“Worry more about your character than your reputation. Character is what you 
are, reputation merely what others think you are.” - - - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Thursday, June 13, 2024 1:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: As a long-time Rexx programmer

...am I the only one who SMH at the documentation for things like ISFEXEC 
(https://www.ibm.com/docs/en/zos/2.4.0?topic=language-issuing-commands-isfexec<https://www.ibm.com/docs/en/zos/2.4.0?topic=language-issuing-commands-isfexec><https://www.ibm.com/docs/en/zos/2.4.0?topic=language-issuing-commands-isfexec<https://www.ibm.com/docs/en/zos/2.4.0?topic=language-issuing-commands-isfexec>>)?
 It reads like it was written by someone who doesn't quite understand how 
variables/literals work in Rexx:
--
You issue commands with the ISFEXEC host command as follows:
Address SDSF
"ISFEXEC sdsf-command (options)"
sdsf-command
is a supported SDSF command, including any parameters. If the command contains 
special characters or blanks, enclose it in single quotation marks.
--
The rest of the doc seems to be similar. If only IBM had some Rexx 
experience.oh, wait.

Yes, I'm being snide, but this is just grim. And embarrassing. I realize 
unlikely to be fixed at this late date, of course.

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport<https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport>
Unsubscribe from Marketing Messages/Manage Your Subs

Re: As a long-time Rexx programmer

[Rob Scott]

Ok I will bite.

Please point out what parts of that extract are "grim" and "embarrassing".

Rob Scott
Rocket Software

Get Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
Lionel B. Dyck <057b0ee5a853-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, June 13, 2024 8:43:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: As a long-time Rexx programmer

EXTERNAL EMAIL




Just be glad we do have a REXX API to invoke SDSF 


Lionel B. Dyck <><
Github: https://github.com/lbdyck<https://github.com/lbdyck>
System Z Enthusiasts Discord: https://discord.gg/sze<https://discord.gg/sze>

“Worry more about your character than your reputation. Character is what you 
are, reputation merely what others think you are.” - - - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Thursday, June 13, 2024 1:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: As a long-time Rexx programmer

...am I the only one who SMH at the documentation for things like ISFEXEC 
(https://www.ibm.com/docs/en/zos/2.4.0?topic=language-issuing-commands-isfexec<https://www.ibm.com/docs/en/zos/2.4.0?topic=language-issuing-commands-isfexec>)?
 It reads like it was written by someone who doesn't quite understand how 
variables/literals work in Rexx:
--
You issue commands with the ISFEXEC host command as follows:
Address SDSF
"ISFEXEC sdsf-command (options)"
sdsf-command
is a supported SDSF command, including any parameters. If the command contains 
special characters or blanks, enclose it in single quotation marks.
--
The rest of the doc seems to be similar. If only IBM had some Rexx 
experience.oh, wait.

Yes, I'm being snide, but this is just grim. And embarrassing. I realize 
unlikely to be fixed at this late date, of course.

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: CVT and PROCLIB

[Rob Scott]

The SDSF "PROC" display uses the SSI interface to JES2 to gather the 
information and can therefore support dynamic proclibs, whereas methods that 
look at current DD allocations for the JES2 ASID will only show current 
allocations. For example you could issue "JDD" against the JES2 row on "DA" to 
see current allocations for all DDnames (including spool), or even issue "JDD" 
against *MASTER* if you want to see a representation of the MSTJCLxx).

The PROC command is the one I would recommend.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Thursday, June 6, 2024 11:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CVT and PROCLIB

EXTERNAL EMAIL





I mean very simple and straightforward environment. JES2, default PROCLIB 
concatenation used when job invokes some PROC.
It can be static or dynamic, nevermind. I believe it is the same concatenation 
as shown in SDSF.PROC panel.

Regarding the topic: I see two ways: console command (output trapped and
analyzed) or ISFCALL.
I prefer the SDSF, because it seems simpler and does not put garbage into 
syslog.

THANK YOU GENTLEMEN!

--
Radoslaw Skorupka
Lodz, Poland




W dniu 06.06.2024 o 02:54, Steve Horein pisze:
> Which ones? Master scheduler? JES? Your own?
> I don't really have an immediate answer for any of the above, but was
> curious about the context.
>
> On Wed, Jun 5, 2024 at 3:37 PM Radoslaw Skorupka <
> 0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:
>
>> Is there any way to obtain a list of PROCLIB concatenation programatically?
>> (I mean REXX)
>>
>> --
>> Radoslaw Skorupka
>> Lodz, Poland
>>

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: XCF/XES programming

[Rob Scott]

Tom

It is not difficult to imagine code from 2005 using user-key common storage as 
that was not as well known as a security/integrity problem to the wide world as 
it is now.

No-one in the right mind would develop using user-key CSA these days.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Tuesday, May 28, 2024 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XCF/XES programming

EXTERNAL EMAIL





What do you mean by "code modified to solve the RUCSA problem"?
IIRC, RUCSA was introduced with z/OS 2.4, in 2020.
It is difficult to imagine a presentation  in 2005 or 2012 that would have 
talked about it.

--
Tom Marchant

On Sat, 25 May 2024 13:18:55 -0500, Stefan Lezzi 
 wrote:

>Hi again,
>
>I've got a 2005 SHARE Anaheim version, thank you John!, and I'd love to
>have the SHARE Atlanta 2012 version also.
>Only there is the code modified to circumvent the RUCSA problem (solved with 
>"...the authorized TSO command processor RXCUAUTH via TSOEXEC to update these 
>structures").
>
>Sadly, I'm not an enough skilled assembler programmer to code this part myself.
>
>If you can check your old project/files for this RXC zip, it would be great!
>
>Thanks
>
>Stefan

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SDSF:DA snapshot

[Rob Scott]

Peter

You can use the SDSF REXX interface to extract information from the DA panel 
and then use "address TSO EXECIO" to write the required output to a known 
DDname which could specify a GDG.

You could then either schedule JCL to run this REXX in batch periodically or 
have some sort of long-running task that mainly sleeps and then invokes the 
same logic every 60 minutes.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter
Sent: Wednesday, May 22, 2024 5:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF:DA snapshot

EXTERNAL EMAIL





Hello

Good evening

Is it possible to take an hourly snapshot of SDSF:DA panel to a GDG ?
Has anyone tried and would like to share the method to achieve this?

Peter

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: REXX SDSF

[Rob Scott]

Roberto

Are there fields on this operator command that are not returned by the SDSF 
"NA" command ?

You could use the SDSF REXX interface to access the columns returned by NA and 
then filter for TN3270 port number(s).

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Roberto Halais
Sent: Tuesday, May 21, 2024 7:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX SDSF

EXTERNAL EMAIL





I was just issuing the command:
D tcpip,tn3270,t,conn,max=*
In order to list all tn3270 connections and capture it in the rexx. It was 
captured in the rexx but it was also written to the system log. Output was 
around 8,000 lines. That’s why I wanted to avoid writing to system log.

Politics: Poli (many) - tics (blood sucking parasites)


On Tue, May 21, 2024 at 1:48 PM Paul Gilmartin < 
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 21 May 2024 12:24:14 -0500, Tom Marchant wrote:
>
> >I certainly hope not. The system log is supposed to be a log of
> >things
> done to the system.
> >
> I'd hardly regard DISPLAY, for example, as "things done to".  If
> there's a security concern, the command should be rejected, not executed and 
> logged.
>
> But what was the OP trying to do, and what alternatives exist?
>
>
> >On Tue, 21 May 2024 13:19:03 -0400, Roberto Halais wrote:
> >
> >>I have a rexx that issues console commands thru ISFEXEC. Is there a
> >>way
> to
> >>prevent the command output to not appear in the system syslog.
> >>I capture the output in my rexx but it also appears in the system log.
>
>
> --
> 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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Testdriving svc in key 9 (was: finding callers key in svc)

[Rob Scott]

Erik,

The source is in github : https://github.com/rscott-rocket/mxe

There was a matching Share presentation from Dallas 2020 that goes with it :

Session 26556
z/OS Cross-Memory Server Code Walkthrough

The main purpose was to show how to write a PC-ss and is probably way more than 
you need, but it will show the basics of what is required.

I hope this helps - (warning I use IBM structured programming macros and some 
folks don’t like 'em).

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Erik Janssen
Sent: Friday, May 3, 2024 4:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Testdriving svc in key 9 (was: finding callers key in svc)

EXTERNAL EMAIL





Hello Rob,

It is a user SVC that has been on our system for a long time and it is used by 
a number of applications. So unfortunately our best (short time) option is to 
secure the SVC.
I will contact you of list if that is ok about the sample code for a pc routine.

Kind regards,

Erik.

On Fri, 3 May 2024 12:12:03 +, Rob Scott  wrote:

>Erik.
>
>>> In the current implementation of the SVC that would work fine, since it is 
>>> all doing the MVC's in key 0, but if I change that to MVCSK and MVCDK 
>>> instructions I might get the 0C4 abend.
>
>Whilst I applaud your desire to implement MVCDK/SK, I think the word
>"fine" is doing some heavy lifting in the above. 
>Using MVC in key0 to read/write non-Key0 memory is obviously a risk to system 
>integrity.
>
>A couple of other minor observations :
>(o) Is this SVC part of new development? If so, perhaps consider using PC-cp 
>instead - I am some sample code that could help in this endevour if you are 
>interested.
>You will require a resource owning ASID to house the PC routine, but it can be 
>limited function in design.
>
>(o) I am not a CICS person, but I thought that normal transactions are 
>discouraged from issuing SVCs (happy to be corrected if not so).

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Testdriving svc in key 9 (was: finding callers key in svc)

[Rob Scott]

Erik.

>> In the current implementation of the SVC that would work fine, since it is 
>> all doing the MVC's in key 0, but if I change that to MVCSK and MVCDK 
>> instructions I might get the 0C4 abend.

Whilst I applaud your desire to implement MVCDK/SK, I think the word "fine" is 
doing some heavy lifting in the above. 
Using MVC in key0 to read/write non-Key0 memory is obviously a risk to system 
integrity.

A couple of other minor observations :
(o) Is this SVC part of new development? If so, perhaps consider using PC-cp 
instead - I am some sample code that could help in this endevour if you are 
interested.
You will require a resource owning ASID to house the PC routine, but it can be 
limited function in design.

(o) I am not a CICS person, but I thought that normal transactions are 
discouraged from issuing SVCs (happy to be corrected if not so).

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Erik Janssen
Sent: Thursday, May 2, 2024 6:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Testdriving svc in key 9 (was: finding callers key in svc)

EXTERNAL EMAIL





Hello Peter,

My apologies for not changing the subject. I managed to show now that the code 
in the svc is correct, it indicated that the caller was in key 9. I've solved 
the testdriver issue now by marking that routine as REFReshable and put it in 
SYS1.LINKLIB. I saw an old thread about this that gave this option, the module 
now gets loaded into subpool 252, which is not fetch protected. I'm testing 
this on a personal ZPDT machine, so in this case it is a fair way to get the 
job done easily, without having to figure out how to do ATTACHX programming.

I just would like to simulate the situation where a cics transaction running in 
key 9 would access a storage area it provided to the svc with key 8. In the 
current implementation of the SVC that would work fine, since it is all doing 
the MVC's in key 0, but if I change that to MVCSK and MVCDK instructions I 
might get the 0C4 abend.
That was also where my confusion (bias) was, I was thinking (expecting) the 0C4 
was triggered in the SVC, while actually it was my test program that abended on 
not being able to get the next instruction from the fetch protected subpool 251 
my program was loaded in.

Next stop is to see if I can get an ESTAE in the routine to give a message 
about this situation and after that perhaps make it more intelligent to allow a 
switch to key 8 in this situation.
I've not done a lot of assembler programming over the years, so it always takes 
me some time to get used to it again, and these routines are of course not the 
easiest to handle. But I like taking on such a challenge, because the amount of 
stuff you learn is always very satisfying.

Kind regards,

Erik Janssen.


On Thu, 2 May 2024 14:07:25 +, Peter Relson  wrote:

>Please try to have different threads with suitable subjects for each. The 0C4 
>is unrelated to the subject.
>
>Since the code shown for the SVC routine is correct for type 2/3/4 yet you say 
>that you do not find the right data, then prove it:
>Show the definition of the SVC, show extracts from IPCS looking at the dump 
>storage.
>
>If you are blowing up at the instruction right after the SPKA to a different 
>key, regardless of what that instruction was, then your program is in key 8 
>fetch-protected storage so unless your new key is 0, you will not be able to 
>access the instruction. Requirements for placing a reentrant program into key 
>0 non-fetch-protected storage depend on authorization and various system-wide 
>options, along with the possibility of doing an ATTACHX with the KEY=NINE 
>parameter (which will place into key 0 storage without relying on 
>authorization).
>
>Peter Relson
>z/OS Core Technology Design
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibite

Re: Control Block field that provides the last USS System-Call?

[Rob Scott]

Dave

The only method I can think of is using PGTHJSYSCALL (and PGTHJPREVSC) from the 
BPX1GTH service.

I would not be surprised if the information is actually held inside control 
blocks in OMVS address space rather than the user/caller.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Thomas David Rivers
Sent: Thursday, April 25, 2024 9:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Control Block field that provides the last USS System-Call?

EXTERNAL EMAIL



I've been scouring control-blocks wondering if there is a field somewhere
that happens to provide the most recent USS system-call (to be able
to, in a SIR, determine of cond_setup was the most recent call.)

Does anyone happen to know if that exists somewhere?

- Many thanks -
- Dave Rivers -

--
riv...@dignus.com<mailto:riv...@dignus.com> Work: (919) 676-0847
Get your mainframe programming tools at 
http://www.dignus.com<http://www.dignus.com>

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


Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: S0c4 creation

[Rob Scott]

Easiest way to create a deliberate 0C1 is to branch to (or inject insteam to 
your executing code) a halfword of zeroes.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Darrold Usher
Sent: Monday, April 22, 2024 1:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: S0c4 creation

EXTERNAL EMAIL





How about create a S0C1?

On Mon, Apr 22, 2024 at 7:21 AM Peter Relson  wrote:

> Bernd O wrote
> 
> I'd suggest to be very careful with such codings; a co-worker some
> years ago did this and - by accident - the code ran privileged, which
> caused the whole LPAR to hang.
>
> Same goes for ST at address zero, which was suggested by another poster.
> 
>
> I challenge both of those.
>
> The first will never happen unless something changed to key 0 (being
> privileged is relevant only to the extent that you could then change
> to key 0). And that doesn't happen without intent.
>
> The second will never happen outside of the OS itself in the absence
> of an APARable z/OS error (related to what we refer to as low-core protect).
>
> Peter Relson
> z/OS Core Technology Design
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: S0c4 creation

[Rob Scott]

There are certain virtual storage addresses that are made read-only (by 
default) on purpose , protected even from programs running key0. Including in 
this list is zero and areas such as PLPA.

Another guaranteed bad address for reference 0c4 is 7BAD and this explicit 
value is used on purpose by some products to catch unintended or unwanted 
reference.

You can get more exotic 0c4s (eg oc4-3b) by polluting the HH of a register and 
then switching to AMODE 64 and using it as base address.

Rob Scott

Sent from Samsung Mobile on O2
Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Sunday, April 21, 2024 3:11:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: S0c4 creation

EXTERNAL EMAIL




Do you need to distinguish among possible reasons?

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


From: IBM Mainframe Discussion List  on behalf of 
Peter <05e4a8a0a03d-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, April 21, 2024 3:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: S0c4 creation

Hello

Good morning

Is there any sample Jobs or I can enforce a s0c4 abend in a Started task ?

I am trying to teach SLIP trap to a rookie..Is there any other efficient
way to do this?

Peter

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


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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: S0c4 creation

[Rob Scott]

Try to store something at address zero will get you 0c4-4

Rob Scott

Sent from Samsung Mobile on O2
Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
Peter <05e4a8a0a03d-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, April 21, 2024 8:45:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: S0c4 creation

EXTERNAL EMAIL





Hello

Good morning

Is there any sample Jobs or I can enforce a s0c4 abend in a Started task ?

I am trying to teach SLIP trap to a rookie..Is there any other efficient
way to do this?

Peter

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



Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: ALESERV rc 15 = 0 and alet = 0

[Rob Scott]

Joseph,

Are you 100% sure that SDWAPRIM is not actually the same as the current PASN ?

This might explain R15=0 and the ALET being zero (although I must admit I have 
never tried ALESERV ADD for the STOKEN of my own PASN before).

I still believe you need to revisit your design. Trying to be “too clever” in 
general purpose recovery routines is not a good idea in my opinion.

Rob

From: IBM Mainframe Discussion List  On Behalf Of Rob 
Scott
Sent: Friday, April 19, 2024 8:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ALESERV rc 15 = 0 and alet = 0

EXTERNAL EMAIL



Joseph,

If I understand your last two posts correctly, you are attempting to add an 
ASID (that you do not control) using ALESERV CHKEAX=NO to the DU-AL of a unit 
of work that is abending (possibly for a large variety of reasons outside of 
your control) in order to add a small amount of diagnostic information ?

This approach seems riddled with system stability risks and I would advise 
against it.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Joseph 
Reichman
Sent: Friday, April 19, 2024 12:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: ALESERV rc 15 = 0 and alet = 0

EXTERNAL EMAIL





Hi

Just tried to get access list token for the GRS Address space ASID 7

Got R15 = 0 and alet = 0, as well this was both on my zpdt system and on the 
CBT real iron I believe z15 system

As well was running under TESTAUTH

Here is the code

* JOER
LOCASCB ASID=SDWAPRIM LOC prim to SRB JOER
* JOER
L R1,ASCBASSB-ASCB(R1) JOER
MVC STOKEN,ASSBSTKN-ASSB(R1) Get Stokrn JOER
* JOER
ALESERV ADD, Put it on DU-AL JOERX
ACCESS=PUBLIC, JOERX
CHKEAX=NO, JOERX
AL=WORKUNIT,STOKEN=STOKEN,ALET=ALET JOER
* JOER
* JOER


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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport<https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport>
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences<http://www.rocketsoftware.com/manage-your-email-preferences>
Privacy Policy - 
http://www.rocketsoftware.com/company/legal/privacy-policy<http://www.rocketsoftware.com/company/legal/privacy-policy>


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: ALESERV rc 15 = 0 and alet = 0

[Rob Scott]

Joseph,

If I understand your last two posts correctly, you are attempting to add an 
ASID (that you do not control) using ALESERV CHKEAX=NO to the DU-AL of a unit 
of work that is abending (possibly for a large variety of reasons outside of 
your control) in order to add a small amount of diagnostic information ?

This approach seems riddled with system stability risks and I would advise 
against it.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Joseph Reichman
Sent: Friday, April 19, 2024 12:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ALESERV rc 15 = 0 and alet = 0

EXTERNAL EMAIL





Hi

Just tried to get access list token for the GRS Address space ASID 7

Got R15 = 0 and alet = 0, as well this was both on my zpdt system and on the 
CBT real iron I believe z15 system

As well was running under TESTAUTH

Here is the code

*  JOER
  LOCASCB ASID=SDWAPRIMLOC prim to  SRB JOER
 *  JOER
  L R1,ASCBASSB-ASCB(R1)JOER
  MVC   STOKEN,ASSBSTKN-ASSB(R1)  Get StokrnJOER
 *  JOER
  ALESERV ADD,Put it on DU-AL   JOERX
ACCESS=PUBLIC,  JOERX
CHKEAX=NO,  JOERX
AL=WORKUNIT,STOKEN=STOKEN,ALET=ALET JOER
 *  JOER
 *  JOER


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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: RACF - SDSF question

[Rob Scott]

Of course, that should read "UPDATE or ALTER access"

Rob

From: IBM Mainframe Discussion List  On Behalf Of Rob 
Scott
Sent: Wednesday, April 17, 2024 4:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



You can check what security activity is going on behind the scenes in SDSF, by 
doing the following :


1. Invoke SDSF and get to the point just before the user issues the action
2. Issue "SET SECTRACE ON"
3. Issue the "C" action
4. Issue "SET SECTRACE OFF"
5. Go into SDSF ULOG and there will new numerous security trace messages 
showing the resources checked by SDSF and the SAF result from each.

They look something like :

ISF051I SAF Access allowed SAFRC=0 ACCESS=ALTER CLASS=JESSPOOL 
RESOURCE=node.owner.jobnameetc

In your specific case, SDSF will do a JESSPOOL profile check and require UPDATE 
or UPDATE access for CANCEL style actions.

Note that this is a "value add" thing that SDSF does and might not be reflected 
in the behaviour of other products/methods that can issue MVS and JES2 commands.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Wednesday, April 17, 2024 1:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



Hi,
I would like to resurrect this question again, because my issue is back but not 
sure if by design or my RACF setup...

Because we are a development shop, we allow our developers to start/stop and 
issue modify commands to shutdown their CICS regions that run as batch Jobs.

They are the owners/notify of said regions, However, what I would like to 
prevent to them Cancelling the regions, due to possible file corruption, etc.

They put a C beside a jobname which then issues a $CJ, which then translates 
into a CANCEL ,A=xx command.

$CJ(5138)
CANCEL C30TCIE2,A=0051
IEE301I C30TCIE2 CANCEL COMMAND ACCEPTED
$HASP890 JOB(C30TCIE2) 288
$HASP890 JOB(C30TCIE2) STATUS=(EXECUTING/SPS1),CLASS=Y,
$HASP890 PRIORITY=9,SYSAFF=(ANY),HOLD=(NONE
$HASP890 CANCEL=YES

So my question becomes is it even possible to stop this because technically 
they are the owners?

In RACF.
My JESSPOOL class has.
*.*.C30TCI*.** (G)

My OPERCMDS class has
JES2.CANCEL.BAT with them having UPDATE access

MVS.CANCEL.JOB.C30TCI* (G) NO access

So not sure this is possible or not?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com%3cmailto:terri.shaf...@aciworldwide.com>>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>>
 On Behalf Of Shaffer, Terri
Sent: Wednesday, February 8, 2023 9:09 AM
To: 
IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Thank you, with your input and Robs, I now know the order of the checks, which 
was the piece I didn't fully understand.

I have now cleaned up my extra rules and added rules under jesspool and they 
are now stopped.

Rob, thanks for the slides!

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com%3cmailto:terri.shaf...@aciworldwide.com>>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>>
 On Behalf Of Robert S. Hansel (RSH)
Sent: Wednesday, February 8, 2023 8:00 AM
To: 
IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Hi Terri,

Here are a couple of thoughts to add to what others have mentioned.

Since SDSF is issuing a JES2 cancel job $CJ command, the name of the OPERCMDS 
resource being checked is JES2.CANCEL.BAT. Profile JES2.CANCEL.BAT.C30TCI* is 
superfluous since the resource name never includes the jobname, so you can 
delete it. Profile JES2.CANCEL.BAT.** is guarding JES2.CANCEL.BAT because the 
.** generic suffix applies to zero or more qualifiers, and in this case it is 
zero qualifiers. The suggestions to lock down MVS cancel job commands won't 
help in this situation because SDSF is issuing JES2 commands instead of MVS 
commands, so the OPERCMDS MVS.CANCEL.JOB

Re: RACF - SDSF question

[Rob Scott]

You can check what security activity is going on behind the scenes in SDSF, by 
doing the following :


  1.  Invoke SDSF and get to the point just before the user issues the action
  2.  Issue "SET SECTRACE ON"
  3.  Issue the "C" action
  4.  Issue "SET SECTRACE OFF"
  5.  Go into SDSF ULOG and there will new numerous security trace messages 
showing the resources checked by SDSF and the SAF result from each.

They look something like :

ISF051I SAF Access allowed SAFRC=0 ACCESS=ALTER CLASS=JESSPOOL 
RESOURCE=node.owner.jobnameetc

In your specific case, SDSF will do a JESSPOOL profile check and require UPDATE 
or UPDATE access for CANCEL style actions.

Note that this is a "value add" thing that SDSF does and might not be reflected 
in the behaviour of other products/methods that can issue MVS and JES2 commands.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Wednesday, April 17, 2024 1:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



Hi,
I would like to resurrect this question again, because my issue is back but not 
sure if by design or my RACF setup...

Because we are a development shop, we allow our developers to start/stop and 
issue modify commands to shutdown their CICS regions that run as batch Jobs.

They are the owners/notify of said regions, However, what I would like to 
prevent to them Cancelling the regions, due to possible file corruption, etc.

They put a C beside a jobname which then issues a $CJ, which then translates 
into a CANCEL ,A=xx command.

$CJ(5138)
CANCEL C30TCIE2,A=0051
IEE301I C30TCIE2 CANCEL COMMAND ACCEPTED
$HASP890 JOB(C30TCIE2) 288
$HASP890 JOB(C30TCIE2) STATUS=(EXECUTING/SPS1),CLASS=Y,
$HASP890 PRIORITY=9,SYSAFF=(ANY),HOLD=(NONE
$HASP890 CANCEL=YES

So my question becomes is it even possible to stop this because technically 
they are the owners?

In RACF.
My JESSPOOL class has.
*.*.C30TCI*.** (G)

My OPERCMDS class has
JES2.CANCEL.BAT with them having UPDATE access

MVS.CANCEL.JOB.C30TCI* (G) NO access

So not sure this is possible or not?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Wednesday, February 8, 2023 9:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Thank you, with your input and Robs, I now know the order of the checks, which 
was the piece I didn't fully understand.

I have now cleaned up my extra rules and added rules under jesspool and they 
are now stopped.

Rob, thanks for the slides!

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Robert 
S. Hansel (RSH)
Sent: Wednesday, February 8, 2023 8:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Hi Terri,

Here are a couple of thoughts to add to what others have mentioned.

Since SDSF is issuing a JES2 cancel job $CJ command, the name of the OPERCMDS 
resource being checked is JES2.CANCEL.BAT. Profile JES2.CANCEL.BAT.C30TCI* is 
superfluous since the resource name never includes the jobname, so you can 
delete it. Profile JES2.CANCEL.BAT.** is guarding JES2.CANCEL.BAT because the 
.** generic suffix applies to zero or more qualifiers, and in this case it is 
zero qualifiers. The suggestions to lock down MVS cancel job commands won't 
help in this situation because SDSF is issuing JES2 commands instead of MVS 
commands, so the OPERCMDS MVS.CANCEL.JOB.jobname resources won't be checked.

As was mentioned, to cancel a job typically also requires ALTER access to the 
JESSPOOL resource guarding the job. Look into setting up appropriate JESSPOOL 
profiles to isolate and restrict ALTER access to these jobs. Also consider 
whether users have been (inadvertently) set up as Destination Operators. If 
they have READ access to SDSF resource ISFOPER.DEST.JES2 and ALTER access to 
SDSF resources prefixed ISFAUTH.DEST., they can cancel jobs while bypassing 
JESSPOOL profile checks.

If the CONSOLE class is active, you can permit ID(*) UPDATE access to 
JES2.CANCEL.BAT.** conditionally by adding operand WHEN(CONSOLE(SDSF)) to the 
PERMIT command so that users can only issue JES2 cancel job commands from 
within SDSF panels. Th

Re: Program to split a jobs output

[Rob Scott]

I believe that Lionel Dyck has a simple SDSF REXX exec that does pretty much 
what you require - it is called "SDSFXDD".

It takes each SYSOUT dataset from a job and saves it as a member of a PDS.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of ??? 
?? ???
Sent: Tuesday, April 9, 2024 9:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Program to split a jobs output

EXTERNAL EMAIL





Hi,
Today I had to sent a jobs output to IBM to help determine a problem.
The jobs had 11 sysout datasets, and I wanted to send each one individually.

Does anyone know of a program to do this automagically, before I see how 
complicated it would be to write one?

Gadi

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SDSF issue.

[Rob Scott]

Gadi.

The supported way to achieve what you want is either :

(1) Issue "R" to reset/resume or "RQ" to "Reset Quiesce" in the NP field 
against the row on DA.

(2) Overtype the "Quiesce" column with either "QUIESCE" or "RESUME" (you must 
use the entire word - no abbreviations)

Hope this helps

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of ??? 
?? ???
Sent: Thursday, April 4, 2024 12:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF issue.

EXTERNAL EMAIL





Hi,
In previous versions, when I wrote Q in the QUIECE field on the DA panel, SDSF 
issued a RESET joname,Q command and the job was quiesced.
We don't use this very often, s I just noticed that in my level of SDSF in z/OS 
v2.5 it doesn't work.
I just checked by z/OS v2.4 system, and it seems to be broken there too.
I looks like SDSF issue the RESET jobname command, which causes the IEE308I 
RESETTERM LENGTH ERROR message to be issued.

Has anyone else see this?

Gadi




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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SDSF CSR

[Rob Scott]

If you are running on z/OS 2.5 or above, you can issue the "JCS" action against 
the row on the "CSR" panel and that will show each individual block of common 
storage which you can then browse using the "S" action.

This will allow you to see if you recognize the contents of the block.

It is very possible that IBM z/OS services your code is invoking are obtaining 
common storage on your behalf and the amount and contents of these blocks are 
not immediately obvious.

SDSF get the information for the CSR panel from the CAUB control blocks created 
by VSM common storage tracking in response to DIAGxx statement "VSM TRACK 
CSA(ON) SQA(ON)"

The JCS action analyses the GQE control blocks that describe each allocated 
block of common storage.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
esst...@juno.com
Sent: Sunday, March 17, 2024 3:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF CSR

EXTERNAL EMAIL





,
Hello,
.
Im trying to understand an anomaly using SDSF CSR - (Common Storage Remaining) 
I have read some of the documentation on SDSF CSR, however it didn't really 
give me an understand of the issue below - .
I have two jobs which invoke the same program from the same load library - 
Bothe jobs invokes IEFSSI REQUEST=ADD and the SSI INIT ROUTINE is the same for 
both JOBs. The SSI INIT Routine has multiple CSECTS and issues IEFSSI 
REQUEST=ACTIVATE (Activate the subsystem), STORAGE OBTAIN (Key 0, Subpool 241, 
Length x'34'), and IEFSSI REQUEST=PUT (Store Sub System Data).
.
Granted the Key 0, subpool 241 may not be the best choice form allocating 
storage from MVS common, that's not the issue for this discussion.
.--
In SDSF I see the following in CSR (Common Storage Remaining) -
JOBNAMECSACSA%   SQASQA%  ECSA   ECSA%
JOBNUMA3920.0076 0   0.56960.0079
JOBNUMB   0 0. 0   0.97920.0135
.--
When I submit the first job (JOBNUMB) I see in SDSF CSR the job retains 9792 
bytes of ECSA and 0.0135% of ECSA. Im not sure where the 9792 bytes of ECSA 
came from - I suspect the majority of this allocation are various control block 
structures associated with the SSI - .
The storage obtain macro in the INIT Routine acquires X'34' bytes of storage - .
However when I submit the second job (JOBNUMA), I see in SDSF CSR, the second 
job retains 5696 bytes of ECSA and 0.0079% of ECSA. Also JOBNUMA allocated 392 
byes of storage from CSA, why?
.
Both jobs invoke the same program, and the same SSI INIT Routine from the same 
load library - I expected to see the same ECSA values for both jobs/programs.
.
Can someone explain why there is such a difference in values?
I obviously don't understand this.
..
   Paul -
.
.

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Recovery routine for IRB

[Rob Scott]

Joe

There is a very good “Providing Recovery” section of the Advanced Assembler 
Services guide that will help.

It includes the following sentence :

“Programs that are disabled, hold locks, or are in SRB mode cannot use 
ESTAE-type recovery routines.”

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Friday, March 1, 2024 12:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Recovery routine for IRB

EXTERNAL EMAIL



Does ESTAE support code that holds a lock? I suspect tthat you need an ARR or 
FRR?

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


From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of Joseph 
Reichman 
<05812645a43c-dmarc-requ...@listserv.ua.edu<mailto:05812645a43c-dmarc-requ...@listserv.ua.edu>>
Sent: Thursday, February 29, 2024 11:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Recovery routine for IRB

HI

I have tested my recovery routines in many different scenarios. My last step
was to test a asynchronous exit or an IRB. Since many people have told I
don't post my code I'll do so now.

I have tested the asynchronous exit or IRB and it has gotten control however
when I insert H'0' it abends with without the recovery getting control

I take the current TCB or PSATOLD (the same one that was active when I
established the estate and save it in IQETCB so since the IRB runs under the
same TCB that established the estate it (the recovery program) should get
control

The local lock is held however I don't think the should stop the estate from
getting control

*++
MODULE CESTAE,BASE=12,LOC=BELOW,AMODE=31,RMODE=ANY, X
TEXT=' ESTABLISH AN ESTAEX ROUTINE'
* *---*
* * LOAD THE ESTAE ROUTINE *
* *---*
MODESET KEY=ZERO,MODE=SUP


LOAD EP=GRECOV,ERRET=EXIT0C LOAD THE ESTAEX ROUTINE
LR R3,R0 ADDRESS OF ESTAEX ROUTINE TO R3
* *---*
* * BUILD PARMLIST FOR ESTAEX ROUTINE *
* *---*
LAE R4,ESTPARAM ADDRESS OF PARMS FOR ESTAE RTN
USING ESTPARM,R4 MAP ESTAE PARMLIST
LAE R15,RETRY RETRY ADDRESS
ST R15,ESTRETRY SAVE IN PARMS FOR ESTAE ROUTINE
* *---*
* * UNCOMMENT THE FOLLOWING 2 LINES *
* * IF THIS MODULE EXECUTES IN *
* * SUPERVISOR STATE. *
* *---*
ST R12,ESTLOAD ENTRY POINT TO ESTAE PARMLIST
MVC ESTMOD(8),=CL8'CESTAE' MODULE NAME TO ESTAE PARMLIST
* *---*
* * ISSUE THE ESTAEX MACRO *
* *---*
ESTAEX (R3),PARAM=(R4),MF=(E,ESTAELST)
* *---*
* * THE FOLLOWING 4 INSTRUCTIONS *
* * REPRESENTS THE REST OF THE *
* * PROCESSING IN THIS MODULE. *
* * AN ERROR WILL CAUSE RTM TO INVOKE *
* * AN ERROR WILL CAUSE RTM TO INVOKE *
* * THE ESTAEX ROUTINE. *
* *---*
* DC H'0'
B IRBERR
ENDMOD RESTORE REGISTERS AND RETURN
IRBERR DS 0H
LOAD EP=IRBPTR
LR R5,R0
* O R5,=X'8000'
ST R5,IRBADD

*
USING PSA,0
L R4,PSATOLD


*
*
*
SETLOCK OBTAIN,TYPE=LOCAL,MODE=UNCOND,REGS=STDSAVE
*
CIRB EP=(R5), X
RETIQE=YES, X
STAB=DYN, X
MODE=SUPR, X
KEY=SUPR, X
WKAREA=255, X
BRANCH=YES, X
AMODE=DEFINED


*

USING RBBASIC,R1
L R5,RBNEXAV Get IQE Pointer
USING IQESECT,R5
ST R5,IQEADD
ST R1,IQEIRB
LA R15,PLIST
ST R15,IQEPARAM
ST R4,IQETCB
*
*
*
SCHEDIRB IQEPTR=IQEADD, X
MF=(E,IRBLST)
*
SETLOCK RELEASE,TYPE=LOCAL,REGS=STDSAVE
B EXIT

* Here is my IRB rtn as you can see I inserted a H'0' upfront
* When I take the H'0' out the IRB routine gets control and runs
till the end
*
IRBPTR CSECT
IRBPTR AMODE 31
IRBPTR RMODE ANY
YREGS
*
* STM R14,R12,12(R13)
LR R5,R15
LR R11,R14
DC H'0'



Thanks


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu<mailto: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<mailto:lists...@listserv.ua.edu> with 
the message: INFO IBM-MAIN


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
==

Re: Query - do you have access to GitHub from your z/OS system? And do you have git on your z/OS system?

[Rob Scott]

We use git on z/OS extensively throughout the company and it is one of those 
tools where you end up thinking "how on earth did I function effectively 
without it?".

We also use BitBucket for our remote repos as it interfaces very nicely with 
Jira.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Matt Hogstrom
Sent: Wednesday, February 14, 2024 8:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Query - do you have access to GitHub from your z/OS system? And do 
you have git on your z/OS system?

EXTERNAL EMAIL





Yes and yes.



Matt Hogstrom

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom

> On Feb 14, 2024, at 14:16, Frank Swarbrick  
> wrote:
>
> From: IBM Mainframe Discussion List  <mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf of Lionel B. Dyck
> <057b0ee5a853-dmarc-requ...@listserv.ua.edu
> <mailto:057b0ee5a853-dmarc-requ...@listserv.ua.edu>>
> Sent: Wednesday, February 14, 2024 7:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU <mailto:IBM-MAIN@LISTSERV.UA.EDU>
> mailto:IBM-MAIN@LISTSERV.UA.EDU>>
> Subject: Query - do you have access to GitHub from your z/OS system? And do 
> you have git on your z/OS system?
>
> As part of the z/OS Open Tools project I'm asking if your z/OS system
> has access to GitHub. The reason for this question is that IBM, ISVs,
> and open-source developers are increasingly using GitHub.
>
> Questions:
>
>1. Do you have access to GitHub from your z/OS system?
>2. Do you have git installed on your z/OS system?
>
> Thank you


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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SDSF able to provide a display/panel for System Recovery Boost (SRB) for Middleware Subsystems on z16?

[Rob Scott]

Roger

I have discussed this with the RMF team and I think we can add a column to SDSF 
“DA” to indicate that the address space can be boosted.

Please contact me offline so that we can discuss.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Roger Lowe
Sent: Monday, February 5, 2024 11:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF able to provide a display/panel for System Recovery Boost 
(SRB) for Middleware Subsystems on z16?

EXTERNAL EMAIL



I was actually after a display 'somewhere' in SDSF that will show me which 
address space(s) have had a boost action against it. For example, I have 
enabled a number of our CICS Regions to be BOOST=YES in WLM and it would be 
nice to go into an SDSF panel (perhaps a "DA OSTC") and a column in that panel 
will show the text string of what I see in the SYSLOG/OPERLOG with the IEA687I 
message of -
"IEA687I Recovery process boost requestor: Middleware Region Startup"

The 'text string' of the IEA687I message is potentially one of:

o Not identified

o Sysplex Partitioning

o CF Structure Recovery

o CF Data-sharing Member Recovery

o Hyperswap

o SVC Dump

o Middleware Region Startup

o Hyperswap Config Load

Roger

On Mon, 5 Feb 2024 10:10:46 +, Rob Scott 
mailto:rsc...@rocketsoftware.com>> wrote:

>I forgot to point out that the SDSF "SYS" command also shows the current boost 
>status for z/OS 2.5+ as well.
>
>For what it is worth, having a panel that showed historical boost activity was 
>one of the driving reasons for the ELOG panel in SDSF 3.1 
>
>Rob Scott
>Rocket Software
>
>-Original Message-
>From: IBM Mainframe Discussion List 
>mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Roger 
>Lowe
>Sent: Sunday, February 4, 2024 7:26 AM
>To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
>Subject: SDSF able to provide a display/panel for System Recovery Boost (SRB) 
>for Middleware Subsystems on z16?
>
>EXTERNAL EMAIL
>
>
>
>
>
>Hi,
> We have a z16 (3932-AGZ) running zOS 3.1 along with IBM Middleware subsystems 
> of Db2 V12, CICS/TS 6.1, MQ 9..2.1, IIB V10 as well as CA- Datacom V15 and 
> ADABAS V712.
>
>We have now enabled SRB for these various Middleware Subsystems specifying 
>BOOST=YES in WLM.
>
>Other than invoking WLM (via ISPF or zOSMF) and then reviewing the 
>Classifcation Rules, we can't find and easy way of what Middleware 
>Subsystem(s) are firstly enabled for BOOST and secondly as easily identifying 
>what subsystem(s) might have used BOOST.
>
>Wouldn't it be nice if SDSF had a panel to show thii information?
>
>Looking at opening up an IBM Ideas,ubut thought I would post here, just in 
>case someone has a suggestion(s) that we haven't considered.
>
>Thanks, Roger
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
>lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the message: 
>INFO IBM-MAIN
>
>
>Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
>Main Office Toll Free Number: +1 855.577.4323
>Contact Customer Support: 
>https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport<https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport>
>Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
>http://www.rocketsoftware.com/manage-your-email-preferences<http://www.rocketsoftware.com/manage-your-email-preferences>
>Privacy Policy - 
>http://www.rocketsoftware.com/company/legal/privacy-policy<http://www.rocketsoftware.com/company/legal/privacy-policy>
>
>
>This communication and any attachments may contain confidential information of 
>Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
>prohibited. If you are not the intended recipient, please notify Rocket 
>Software immediately and destroy all copies of this communication. Thank you.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu<mailto: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<mailto:lists...@listserv.ua.edu> with 
the message: INFO IBM-MAIN


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSuppo

Re: SDSF PS Command column

[Rob Scott]

>> Since BPXEKDA doesn't need the OMVS segment for the first 40 bytes of the 
>> command, why does it need it for the rest of the command? Isn't it just a 
>> null terminated field that can be fully copied?

My educated guess here is that BPXEKDA is used by the "D OMVS" operator command 
and provides an interface layer between the z/OS unix control blocks and the 
display command service, most likely via a PC-ss, and just gathers the required 
information without going through the dubbing process. Behind the scenes there 
is probably one or more tables in OMVS private storage describing the current 
processes.

Using this interface also makes sense that operator commands can gather 
information independently of possible environmental problems that could affect 
BPX1/4 callable services. Due to console screen real estate, I imagine that the 
original authors returned only the characters that they needed for the display 
command response.

To get more characters from BPXEKDA, there would have to be an enhancement to 
that service so that consumers like SDSF could display more data.

OR

The other alternative is that consumers like SDSF, call BPX(1/4)GTH in some 
fashion to gather the full text.

I know where I would put my money on which could happen faster.

As to "why don't you just fix it ?" style questions, we have to consider quite 
a few compatibility issues across n-2 releases especially when the "fix" 
requires changes to configuration and security for either (or both of) the SDSF 
server(s) and client users.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Monday, February 5, 2024 3:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF PS Command column

EXTERNAL EMAIL





On Sat, 3 Feb 2024 09:24:07 +, Rob Scott  wrote:

>SDSF calls the BPXEKDA service returns truncated command information.

Since BPXEKDA doesn't need the OMVS segment for the first 40 bytes of the 
command, why does it need it for the rest of the command? Isn't it just a null 
terminated field that can be fully copied?

>We have an existing RFE to provide more information.

My guess is that the RFE includes more than just the command which probably 
need dubbing. I would think you could just as easily copy 100 bytes as 40 bytes.

> When the PS command was originally written OMVS segments were not
> commonplace and the design goal was to provide the data without being
> dubbed

In the past, dubbing caused some conflicts in some OEM products. For example, I 
was a developer for an automation product that included multi-tasking & 
multi-user TSO in the address space (also TCP tasks). You might introduce 
similar problems in the console address space so you will need more than simple 
testing.

>BPXEKDA is used by the operator command responses which probably explains the 
>truncation length.

I suspect the truncation is by choice. One possibility for the limitation is 
MLWTO secondary messages having a max length of 80. Another possibility is 
security.where the user does not have an OMVS segment to restrict access to 
processes. A third possibility would be TSO CONSOLE & OPER commands where 
output flooding. Fourth, it might introduce problems with MPF processing & 
message suppression. It might also be an issue with syslog. It could also 
introduce bad habits in automation products.

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SDSF able to provide a display/panel for System Recovery Boost (SRB) for Middleware Subsystems on z16?

[Rob Scott]

I forgot to point out that the SDSF "SYS" command also shows the current boost 
status for z/OS 2.5+ as well.

For what it is worth, having a panel that showed historical boost activity was 
one of the driving reasons for the ELOG panel in SDSF 3.1 

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Roger Lowe
Sent: Sunday, February 4, 2024 7:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF able to provide a display/panel for System Recovery Boost (SRB) 
for Middleware Subsystems on z16?

EXTERNAL EMAIL





Hi,
   We have a z16 (3932-AGZ) running zOS 3.1 along with IBM Middleware 
subsystems of Db2 V12, CICS/TS 6.1, MQ 9..2.1, IIB V10 as well as CA- Datacom 
V15 and ADABAS V712.

We have now enabled SRB for these various Middleware Subsystems specifying 
BOOST=YES in WLM.

Other than invoking WLM (via ISPF or zOSMF) and then reviewing the 
Classifcation Rules, we can't find and easy way of what Middleware Subsystem(s) 
are firstly enabled for BOOST and secondly as easily identifying what 
subsystem(s) might have used BOOST.

Wouldn't it be nice if SDSF had a panel to show this information?

Looking at opening up an IBM Ideas, but thought I would post here, just in case 
someone has a suggestion(s) that we haven't considered.

Thanks, Roger

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SDSF able to provide a display/panel for System Recovery Boost (SRB) for Middleware Subsystems on z16?

[Rob Scott]

Roger

SDSF for z/OS 3.1 introduces the Event Log (ELOG) feature and one of the 
intercepted data points is boost activity. If boost is used while the SDSF 
server is active, we will notice it and add a record to the event log and you 
can view using the ELOG command.

Rob Scott
Rocket Software

Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
Roger Lowe <05313747ec35-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, February 4, 2024 7:26:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: SDSF able to provide a display/panel for System Recovery Boost (SRB) 
for Middleware Subsystems on z16?

EXTERNAL EMAIL





Hi,
   We have a z16 (3932-AGZ) running zOS 3.1 along with IBM Middleware 
subsystems of Db2 V12, CICS/TS 6.1, MQ 9..2.1, IIB V10 as well as CA- Datacom 
V15 and ADABAS V712.

We have now enabled SRB for these various Middleware Subsystems specifying 
BOOST=YES in WLM.

Other than invoking WLM (via ISPF or zOSMF) and then reviewing the 
Classifcation Rules, we can't find and easy way of what Middleware Subsystem(s) 
are firstly enabled for BOOST and secondly as easily identifying what 
subsystem(s) might have used BOOST.

Wouldn't it be nice if SDSF had a panel to show this information?

Looking at opening up an IBM Ideas, but thought I would post here, just in case 
someone has a suggestion(s) that we haven't considered.

Thanks, Roger

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



Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SDSF PS Command column

[Rob Scott]

The desire to avoid dubbing was purely down to requiring an OMVS segment for 
the SDSF user.

Of course, in today's environment decades later,  this seems a rather quaint 
reluctance as you can't do much on z/OS without one.

Rob Scott
Rocket Software

Sent from Samsung Mobile on O2
Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, February 3, 2024 3:25:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SDSF PS Command column

EXTERNAL EMAIL





On Sat, 3 Feb 2024 09:24:07 +0000, Rob Scott  wrote:

>... When the PS command was originally written OMVS segments were not 
> commonplace and the design goal was to provide the data without being dubbed  
> ...
>
What is the penalty associated with dubbing?

Would it be possible or even desirable to save and restore the "undubbed" 
status?
I know WJS has recommended against SYSCALLS OFF, which would undub a
pfocess.

(An earlier ply was pessimistic about seeing an expert followup.  I suspect3d 
otherwise.)

--
Thanks,
gil

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



Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Replacement for LMAC program in ISPF 3.1

[Rob Scott]

An unsupported tool using a point-in-time offset into a non-interface, 
non-public control block that fails years later due to architectural changes is 
neither poor programming by ISPF development or some nefarious scheme to break 
existing code.

It is just the unfortunate (and inevitable) consequence of using unsupported 
interfaces.

Rob Scott
Rocket Software

Sent from Samsung Mobile on O2
Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, February 3, 2024 12:20:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Replacement for LMAC program in ISPF 3.1

EXTERNAL EMAIL





On Fri, 2 Feb 2024 16:36:34 -0600, Michael Oujesky wrote:

>Presuming those control block revisions were made
>with the specific intent to cause existing coding to fail.
>
>Michael
>
>At 05:14 AM 2/1/2024, Lionel B. Dyck wrote:
>
>>This would work great if IBM hadn't also changed
>>some control block offsets ☹
>>
Didn't they make corresponding changes in the macros mapping
those data areas?  Did they hard-code those offsets?

Programming 101.

--
gil

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



Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SDSF PS Command column

[Rob Scott]

SDSF calls the BPXEKDA service to get this information and this only returns 
truncated command information. When the PS command was originally written OMVS 
segments were not commonplace and the design goal was to provide the data 
without being dubbed (which would have been required for calling something like 
BPX1GTH).

BPXEKDA is used by the operator command responses which probably explains the 
truncation length.

We are fully aware of the limitations on this implementation and have an 
existing RFE to provide more information.

Rob Scott
Rocket Software

Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, February 3, 2024 5:37:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SDSF PS Command column

EXTERNAL EMAIL





On Fri, 2 Feb 2024 15:55:26 -0600, Mark Zelden wrote:

>On Fri, 2 Feb 2024 19:30:39 +, Frank Swarbrick wrote:
>
>>Is there any way to get more than the first 40 characters of the associated 
>>command line for a job in the PS screen?
>
>Limited to 40 characters. regardless of what you put in arrange.   (someone 
>can open an enhancement request)
>
No, that should be a Support request  Some defects are simply too wrong to be
subjects for enhancement.

Regardless of documentation.

--
gil

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



Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Greg Dyck

[Rob Scott]

It is with great sadness that I have to report the sudden passing of Greg Dyck.

Greg has been working at Rocket Software for the last 8 years or so, but most 
of you will know him from decades spent working on the deep internals within 
both z/OS and DB2.

A brilliant developer and software architect, he will leave his fingerprints on 
many core components and also in the memories of the countless people who 
benefited from his kindness and willingness to help.

I came across Greg in the 1990s on IBM-Main and was amazed at the level with 
which he was prepared to educate and help the posters on the forum. I finally 
met him in person when he worked at Rocket and could actually shake his hand 
and thank him for everything he taught me over the years from reading his posts.

I know that generations of mainframers have benefitted from his assistance and 
that he helped make everyone he came across a better programmer.

He will be greatly missed.


Rob Scott
Principal Architect, Mainframe Systems Tools
Distinguished Engineer
Rocket Software
77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
Tel: +1.781.684.2305
Email: rsc...@rs.com<mailto:rsc...@rs.com>
Web: www.rocketsoftware.com<http://www.rocketsoftware.com/>



Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Any Recovery for RMODE64

[Rob Scott]

Please search the archives.

Peter Relson posted on IBM-Main back in 2020 on the restrictions on RMODE 64 in 
some detail, including recovery issues.

Rob Scott
Rocket Software



Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
Joseph Reichman 
Sent: Thursday, January 25, 2024 11:38:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Any Recovery for RMODE64

EXTERNAL EMAIL





Just wondering is there any recovery for a program running RMODE 64 don't
see that with ESTAE or SETFRR

As more and more services run above the bar

More so SDWAEC1 and SDWAEC2 are only 8 bytes

thanks

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



Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Looking to invoke abend in IBM PC call Service

[Rob Scott]

I would imagine that most PC routines would establish recovery and gracefully 
terminate with a "something bad was passed to me" RC+RSN for instances like 
this.

Perhaps forcing a well-known abend+rsn with a COND=NO style call might be 
better - maybe a flavour of STORAGE OBTAIN or IARV64 ?

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Binyamin Dissen
Sent: Friday, January 19, 2024 6:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking to invoke abend in IBM PC call Service

EXTERNAL EMAIL



On Thu, 18 Jan 2024 18:34:43 -0500 Joseph Reichman 
mailto:reichman...@gmail.com>>
wrote:

:>I am looking to cause an abend in IBM Service that is invoked by a PC call
:>(bad parameters) so as to test out Estate Type Recovery for CBT file 192

:>If anyone has an example would appreciate it

One would think placing x'' in R15-R1 should do it.

--
Binyamin Dissen mailto:bdis...@dissensoftware.com>>
http://www.dissensoftware.com<http://www.dissensoftware.com>

Director, Dissen Software, Bar & Grill - Israel

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


Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: CSVQUERY in ARR routine return code 8

[Rob Scott]

Joe

A couple of things that might help :

(o) Have you correctly told the CSVQUERY macro about the environment via 
SYSSTATE so that it generates the correct parameter list?
(o) Have you tested it with a known-good LPA address (or module name like 
"IEFBR14") to ensure that you have the basic plumbing correct?
(o) Have you dumped (or breakpointed)  the module to examine the parameter list 
and GPR/AR values just prior to CSVQUERY being invoked?

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Joseph Reichman
Sent: Friday, December 15, 2023 12:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CSVQUERY in ARR routine return code 8

EXTERNAL EMAIL





Hi

I noticed a lot of the info regarding to the abending programs in a ARR 
recovery routine( for a space switching pc rtn)  point to the Home address 
space such as SDWARBAD that address is from the home address space RB

Wanting to get info on the PC rtn running in Primary I coded a CSVQUERY using 
the INADDR parameter having the SDWANXT1 as it value I tried the a full word 
containing the address and a pointer to a fullword containing that address both 
times It returned R15 = 8

When I do a tso TEST where subcommand with this value it recognizes the address 
as Whitin the PC load module

thanks

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SQA overflow condition

[Rob Scott]

Peter,

SDSF has the “CSR” display (Common Storage Remaining) and on later releases you 
can even issue the “JCS” action (Job Common Storage) against a row on the CSR 
panel to drill down to each individual chunk of common storage (and browse it 
if you so wish).

For in-use common storage, see the SDSF “AS” display and you can use the “JCS” 
action against active jobs as well.

SDSF also has the “CS” common that shows common storage summarized by subpool 
and key, and then the “L” action drills down to each block of storage within 
that subpool+key to show who owns it.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Peter
Sent: Monday, December 11, 2023 4:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SQA overflow condition

EXTERNAL EMAIL



The ESQA usage has gone to 108%.

Is there any tool available in CBTTAPEA which can tell me or trace SQA
users and who are not releasing the storage?

On Mon, Nov 27, 2023, 5:37 PM Allan Staller <
0387911dea17-dmarc-requ...@listserv.ua.edu<mailto:0387911dea17-dmarc-requ...@listserv.ua.edu>>
 wrote:

> Classification: Confidential
>
> 100% concur w/Martin
>
> -Original Message-
> From: IBM Mainframe Discussion List 
> mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf
> Of Martin Packer
> Sent: Sunday, November 26, 2023 2:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
> Subject: Re: SQA overflow condition
>
> [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.]
>
> (This is not specific advice but a way of thinking about things.)
>
> SQA can, of course, overflow into CSA - with no real harm done. Unless it
> causes CSA to go short. (CSA can't overflow into SQA, of course.)
>
> The above statements are true for both 24-bit and 31-bit.
>
> 1409K below the line, though, is pretty extreme - for 24 bit. If you made
> SQA larger so that it only overflowed, say, by 100K there would be no
> wasted virtual storage.
>
> More importantly, check out the "free CSA" picture. You really don't want
> to run out of that. For 24-bit you want a few hundred K free. (But to
> achieve that might require losing 1MB of 24-bit private, which might not be
> consequence free.)
>
> For 31 bit I like to see at least 100MB free ECSA, preferably more. The
> reason is because ECSA is - in my experience - more volatile.
>
> Speaking of volatility, you need to plan defensively - as a problem can
> lead to surge in SQA and CSA usage .
>
> Final point: I would advocate using SMF 78-2 to build a picture of common
> storage usage - and how variable it is. Here is a blog post I wrote on the
> matter:
>
> htt ps://
> mainframeperformancetopics.com/2020/01/05/how-i-look-at-virtual-storage<http://mainframeperformancetopics.com/2020/01/05/how-i-look-at-virtual-storage>
>
> (Take out the space to follow the URL - as my mail client turned it into
> an attachment.) 
>
> Cheers, Martin
>
> Sent from my iPad
>
> > On 26 Nov 2023, at 05:40, Peter 
> > mailto:dbajava...@gmail.com>> wrote:
> >
> > Hello
> >
> > I am able to see the below alert condition under RMF postprocessor III
> >
> >
> >
> > Name Reason Critical val. Possible cause or action
> >
> > *STOR TSQAO > 0 1409K bytes SQA overflow into CSA 1409K.
> >
> >
> >
> >
> >
> > Our SQA and CSA set up in our IEASYSxx is as below
> >
> >
> >
> > CSA=(2000,30)
> >
> >
> >
> > SQA=(16,192)
> >
> >
> > Hardware: z14
> > LPAR : 16gb memory
> > zOS 2.4
> >
> > Do I have think about tunning the SQA parameter ?
> >
> > Regards
> > Peter
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the 
> > message: INFO IBM-MAIN
>
> Unless otherwise stated above:
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598 Registered office: PO
> Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the 
> message: INFO IBM-MAIN
> ::DISCLAIMER::
> 
> The contents of this e-mail and any attachment(s) ar

Re: Find the ASID type?

[Rob Scott]

If the OP is willing to call an interface instead, the use ERBSMFI and get 
SMF79-1 records and look at the values in R791TAS.

CHKTRID is a good place to start if you are trying to work this out from 
control blocks yourself, but there are a few nuances to consider (assuming you 
have the ASCB address for the ASID) :

(o) If ASCBJBNI is non-zero, you need to get the CSCB from CHCSCBP (based 
CHNAME on ASCBJBNI)
(o) If ASCBJBNI is zero, use ASCBCSCB
(o) If CHJOBID, then you might have a JOB, but it will be STC if ASCBJBNI=0
(o) CHTSID = TSU
(o) Otherwise you have an STC, but then you need to identity ASCH, OMVS and 
INITs from jobnames

If you then want to accurately populate fields like “STEPNAME” and “PROCSTEP”  
you need to be careful as they can come from different places depending on the 
logic above.

It is a bit messy TBH.

Also bear in mind that ASID(0001) is called “SYSLOG” 

Rob Scott
Rocket Software



From: IBM Mainframe Discussion List  On Behalf Of 
Binyamin Dissen
Sent: Friday, December 8, 2023 11:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Find the ASID type?

EXTERNAL EMAIL



CHTRKID ?

On Thu, 7 Dec 2023 21:32:27 -0600 Steve Horein 
mailto:steve.hor...@gmail.com>> wrote:

:>Hi!
:>Looking at messages CNZ4105I/CNZ4106I from an MVS DISPLAY ACTIVE command,
:>there is a tally of different address space types in the header:
:>
:>JOBS M/S TS USERS SYSAS INITS ACTIVE/MAX VTAM OAS
:>x x x x x x/x x
:>
:>NetView has a RECEDATA function that "Provides information about the origin
:>of a command that was transferred to the NetView environment by using a
:>NETVONLY action in a Command Revision Table", that includes "ASTYPE", that
:>would return one of the following:
:>
:>Value Description
:>D USS persistent procedure. The address space has a name for initiated
:>programs, appropriate for a JOB. However, the existence of an OpenMVS
:>address space block indicates a special purpose USS persistent procedure.
:>J The address space is a JOB.
:>N The address space is a system address space started during operating
:>system initialization (NIP) processing.
:>S The address space is a Started Task (STC).
:>T The address space is a Time-Sharing User (TSO).
:>U The address space is a USS forked or spawned procedure.
:>* Error: the address space where the command originated has closed or else
:>the message is not from the local LPAR.
:>? Error: inconsistent data (might be a transient condition).
:>! Error: inconsistent data.
:>> Error: the supplied ASID is larger than the allowed ASID limit for the
:>system
:>
:>With the DISPLAY ACTIVE command knowing how many of each type there is, and
:>the RECEDATA function knowing the type of address space that just issued a
:>command, there seems to be an indicator to provide that kind of
:>information. What I am curious about, and would like to make use of, is
:>where the address space "type" can be found, given only a job name or ASID?
:>
:>For example, the ISG343I results of D GRS,RES=(SYSDSN,) can
:>identify the following:
:>SYSNAME JOBNAME ASID TCBADDR EXC/SHR OWN/WAIT
:>
:>If I wanted to know that the JOBNAME was a TSO user, a USS process, STC, or
:>a batch job, is it possible to definitively find out?
:>I was looking at ASCBJBNI and ASCBJBNS, but it seems there is still
:>ambiguity. I'm not sure if I could tell the difference between a TSO user
:>and a Started task just from ASCBJBNS.
:>Where else can I look?
:>
:>Thanks in advance for any pointers!
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with 
the message: INFO IBM-MAIN

--
Binyamin Dissen mailto:bdis...@dissensoftware.com>>
http://www.dissensoftware.com<http://www.dissensoftware.com>

Director, Dissen Software, Bar & Grill - Israel

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rock

Re: Parameters to ARR routine

[Rob Scott]

As Binyamin points out ALET 1 does not mean "Home address space (HASN)" - it 
means "Secondary address space (SASN)".

It may well be actually the same value a lot of the time, but you cannot (and 
must not) assume that to be the case.

Consider a case where all THREE addresses can be different : (assuming PC-ss 
owned by two server ASIDs and ETDEF with SASN=OLD)

Caller ASID = X'00C0'
Your PC-ss owner = X'00A0'
Another PC-ss owner = X'00B0'

Caller logs on to TSO :
HASN = 00C0
SASN = 00C0
PASN = 00C0

Caller invokes "another" PC-ss routine :
HASN = 00C0
SASN = 00C0
PASN = 00B0


Code in "another" PC routine invokes your PC-ss :
HASN = 00C0 (ALET=2)
SASN = 00B0 (ALET=1)
PASN = 00A0 (ALET=0)


If you then reference something like TCB or RB control blocks using ALET=1 
thinking that you are looking at "home"  you might abend - but even worse it 
might "work" because (currently) TCB addresses tend to be the same address for 
the first few tasks in each address space but the data will be incorrect for 
your purposes.

Rob Scott
Rocket Software


From: IBM Mainframe Discussion List  On Behalf Of 
Binyamin Dissen
Sent: Wednesday, December 6, 2023 1:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Parameters to ARR routine

EXTERNAL EMAIL



You cannot guarantee that ALET 1 addresses the home address space. depending
on how the ETDEF is used, the ALET 1 at entry may point to the CP or the
primary at the time of the PC.

If you want HOME, use ALET 2. That is (almost - it appears that some SLIH /
SRB's do not have an ALET to the home address space) always placed in the DU
referring to the home address space.

Also, from a PC routine, the RB information is less useful than the
information in the current linkage stack entry.


On Tue, 5 Dec 2023 15:27:52 -0500 Joseph Reichman 
mailto:reichman...@gmail.com>>
wrote:

:>I just saw it you place the recover param the modifiable area of linkage
:>stack
:>
:>I'm updating file 192 part of the modifications is chaining the TCB/rb/cde
:>
:>In that case I would need at set the AR to 1 for home address space and do
:>sac 512 to reference the TCB/rb/cde chain
:>
:>Joe Reichman
:>
:>
:>On Tue, Dec 5, 2023 at 3:24?PM esst...@juno.com<mailto:esst...@juno.com> 
mailto:esst...@juno.com>> wrote:

:>> SET ETDEF has a parameter for an Associated Recovery Routine (ARR)
:>> If You develop an ARR, I would be interested in seeing what You do/
.
:>> I have an ARR , I like to see what others do in it .
:>> I can send You what 'Im playing with now and some documentation.
.
:>> -- Original Message --
:>> From: Joseph Reichman mailto:reichman...@gmail.com>>
:>> To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
:>> Subject: Parameters to ARR routine
:>> Date: Tue, 5 Dec 2023 14:36:06 -0500

:>> Doesn't seem like ETDEF has a param for the parameters list for ARR's

--
Binyamin Dissen mailto:bdis...@dissensoftware.com>>
http://www.dissensoftware.com<http://www.dissensoftware.com>

Director, Dissen Software, Bar & Grill - Israel

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


Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: zOSMF install - SDSF ISFPRMxx

[Rob Scott]

Mark

The original APAR (PH49811)  that introduced the ISFNTCNV tool and the ISFRACEX 
sample RACF starter set was rolled back to z/OS 2.4.

I am pleased to hear that the ISFRACEX starter set proved useful, we are 
strongly suggesting its use (along with reading the “SDSF Security – How does 
it work on z/OS 2.5+” presentation) to all customers attempting the migration.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Mark Zelden
Sent: Tuesday, December 5, 2023 9:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF install - SDSF ISFPRMxx

EXTERNAL EMAIL



A day late and a dollar short. :-) Although you did get me a REXX exec or two 
to help since
ISFACR would not work in my sysplexes at all except a small monoplex. I didn't 
end up
using them though as it turned out and starting from scratch and implementing
security was a much better approach for me than converting ancient ISFPRMxx
parms (that were originally assembled parms) into RACF definitions.

Shouldn't this APAR (or APARs) be rolled down to z/OS 2.4 considering z/OS 2.5
forces external security? The conversion / migration has to be done prior to
z/OS 2.5.

About about my experience with a large client environment:

Mostly I had to worry about SDSF class profiles since OPERCMDS was protected in 
all
my sysplexes. WRITER had a mix and JESSPOOL was protected on about half
of 9 sysplexes. However, everyone pretty much had read access to everything in
spool and only SYSPROGs and operators had "all" access, so that was not hard
to figure out. One system had payroll jobs protected and I was all set up to
implement that via RACF protection in JESSPOOL, but then I found out that 
payroll
was not run on the mainframe in 15 years and didn't do it.

For the SDSF part, I used ISF.SISFEXEC(ISFRAC) as a starting point and did 
everything
from scratch keeping in mind all the things I read from the migration manual 
and some
of the things I saw in ISFACR from the one monoplex it worked on. While this 
kept
me up at nights for months when I found out after I started working on z/OS 
2.5, after
the first sysplex was done it turned out to not be "a big deal" since I had a 
good templates
to work from. So I do recommend reading that migration manual and really 
understanding
what this conversion means.

One of my "lessons learned" for other or for future migrations, was to "read 
about
destination operator authority" because JESSPOOL rules will not work as you 
intend
and the ISFRAC sample enabled that for operators / sysprogs,

I went from as many as 60 groups in ISFPRMxx in on sysplex down to 3 per the 
samples,
but honestly you can get away one a single group as the parms are almost 
meaningless
once you are using full external security or at z/OS 2.5. My 3 groups look the 
exact
same in all my sysplexes except for DADFLT which I modeled after existing 
"sysprog",
"operator", "other" groups in ISFPRMxx prior to conversion.

Another thing I did was get rid of all hard coded panels / displays that were 
20+ years
old. Most were secondary displays so no one really noticed except that the 
defaults
have mixed case column headings. One sysplex did have some primary panels and
I had one group of users (print operators) complain right after the conversion 
that
removed the custom panels, but part of the implementation plan included
instructions on how to use "arrange", so in the end they were fine and agreed
to leave it as is after I explained the benefits and the 20 additional fields 
they
had their display now. (Even found a very old post from Skip Robinson explaining
the same thing I told them).

My only real complaint about all of this is that it caught me by surprise. The 
requirement
was announced at the last possible time it could - the last quarterly 
announcement for z/OS 2.4
enhancements (I think) as a statement of direction. I always look at those 
announcements
for enhancements but don't normally pay close attention to the statements of 
direction
if in there. I would have thought something "this big" would have been in the 
z/OS 2.4
announcement in the "Statements of direction" section and that would have given 
me 2 years
to plan and execute. As it was, for me it delayed z/OS 2.5 migrations for 6-9 
months
depending on the sysplex. Mostly in getting a game plan for all the sysplexes
I was supporting and doing the first migration in a big sysplex outside
of sandbox. Once I did the first one, the others were done within a few months.

BTW, I did have 2 ACF2 monoplex LPARs to migrate also. I translated the ISFACR 
sample
to ACF2 and Broadcom also had several documents / web pages about the migration.
In some ways, they did a better job explaining it and simplifying it than IBM 
did.

One last thing: I created all the RACF definitions and prep via PDS members to 
be
executed at migration time. The RACF admins just ha

Re: zOSMF install - SDSF ISFPRMxx

[Rob Scott]

Peter

The latest APAR for the new sample and REXX is :

PH55420

Included is a starter set sequence of RACF commands to implement a simple SDSF 
security setup assuming three types of users : sysprogs, operators and general 
users.
Also included is a REXX exec that takes SDSF “NTBL/NTBLENT” statements from 
ISFPRMxx and converts them to profile definitions for JESSPOOL resources.

We find that the above is sufficient for most customers to get started.

All SDSF presentations from Share and GSE can be found at the IBM education 
github :

https://github.com/IBM/IBM-Z-zOS/tree/main/zOS-Education/

Checkout the 2.5 and 3.1 folders and look for the “SDSF Security – How does it 
work on z/OS 2.5+” slide deck.

We also found that once customers understand what SDSF is doing under the 
covers for the various panels and actions, the migration makes much more sense.

I hope the above is helpful

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Peter
Sent: Sunday, December 3, 2023 4:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zOSMF install - SDSF ISFPRMxx

EXTERNAL EMAIL



Well I was able to find a utility developed by rocket software ISFACR and
it helped me to generate some commands which were required as part of my
migration

found that already my system had OPERCMDS enabled but other Classes were
not activated.

The generated command also deletes the existing OPERCMDS profile which I
will skip and run others if it is required



On Sun, Dec 3, 2023, 8:39 AM Peter 
mailto:dbajava...@gmail.com>> wrote:

> Hello Rob
>
> Thank you so much for your response
>
> Could you please point to your presentation on migrating off from ISFPRMXX
> to RACF ?
>
> Fortunately our shop is very small and we don't have any archiving tool or
> any automation tool.
>
> Peter
>
> On Sat, Dec 2, 2023, 9:55 PM Rob Scott 
> mailto:rsc...@rocketsoftware.com>> wrote:
>
>> Peter,
>>
>> Can I strongly suggest you instigate a project to activate OPERCMDS (and
>> JESSPOOL if not already active).
>>
>> ISFPRMx just controls actions within SDSF and does not preclude any
>> semi-capable programmer from writing code to issue operator commands (or
>> access SYSOUT using the JES SSI).
>>
>> Starting with z/OS 2 5, SDSF no longer uses ISFPRMxx to control security
>> as everything now only goes through SAF authority. We use the SDSF class
>> for product controls, and also make OPERCMDS and JESSPOOL checks on the
>> user's behalf when processing actions taken within the product.
>>
>> Please be aware that converting your systems to correctly use OPERCMDS
>> and JESSPOOL can be a lengthy process, and you should allow many weeks for
>> testing and validation.
>>
>> The OPERCMDS and JESSPOOL classes being activated can affect a broad
>> range of other products including sysout archiving and automated operations.
>>
>> I do have some presentations about SDSF security and can point you in the
>> right direction if you want.
>>
>> As a further note, the old ISFACR tool that was written 25+ years ago to
>> aid in SAF security migration is showing its age a bit. We have some more
>> recent (and much simpler) tools and processes now.
>>
>> Rob Scott
>> Rocket Software
>>
>> Sent from Samsung Mobile on O2
>> Sent from Outlook for Android<https://aka.ms/AAb9ysg<https://aka.ms/AAb9ysg>>
>> 
>> From: IBM Mainframe Discussion List 
>> mailto:IBM-MAIN@LISTSERV.UA.EDU>> on behalf
>> of Peter mailto:dbajava...@gmail.com>>
>> Sent: Saturday, December 2, 2023 9:31:26 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU> 
>> mailto:IBM-MAIN@LISTSERV.UA.EDU>>
>> Subject: zOSMF install - SDSF ISFPRMxx
>>
>> EXTERNAL EMAIL
>>
>>
>>
>>
>>
>> Hello All
>>
>> Good morning
>>
>> I have planned to install zOSMF in our test LPAR. Our SDSF uses its own
>> security features using ISFPRMXX and I can see zOSMF has its own IZUSEC
>> jobs where it activates OPERCMDS class. We never activated OPERCMDS
>> instead
>> we manage using ISFPRMXX PARMLIB member.
>>
>> Is there anyone who have installed zOSMF with above scenario?
>>
>> Peter
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with 
>> the message: INFO IBM-MAIN
>>
>>
>> 
>> Rocket Software, Inc. and subsidiaries ? 77 Fourth Aven

Re: zOSMF install - SDSF ISFPRMxx

[Rob Scott]

ISFACR was actually written decades ago, waaay before Rocket involvement in 
SDSF.

There is a SDSF security migration manual which has been  updated recently to 
refer customers to some alternate simpler tools introduced via PTF.

You have to be VERY careful with ISFACR as it does have a "cleanup" step that 
it runs before defining new rules and it could affect any existing profiles. It 
does come with plenty of disclaimers in the doc and the commands it generates. 
It really should not be used as a definitive oracle of the profiles required, 
and customer review and edit is expected. It most definitely is not a "run it 
once and you are done" thing.

When I get back into work tomorrow I will post the presentation links and the 
PTF you need for the new tools.

Rob Scott
Rocket Software


From: IBM Mainframe Discussion List  on behalf of 
Peter 
Sent: Sunday, December 3, 2023 4:10:16 pm
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: zOSMF install - SDSF ISFPRMxx

EXTERNAL EMAIL




Well I was able to find a utility developed by rocket software ISFACR and
it helped me to generate some commands which were required as part of my
migration

found that already my system had OPERCMDS enabled but other Classes were
not activated.

The generated command also deletes the existing OPERCMDS profile which I
will skip and run others if it is required



On Sun, Dec 3, 2023, 8:39 AM Peter  wrote:

> Hello Rob
>
> Thank you so much for your response
>
> Could you please point to your presentation on migrating off from ISFPRMXX
> to RACF ?
>
> Fortunately our shop is very small and we don't have any archiving tool or
> any automation tool.
>
> Peter
>
> On Sat, Dec 2, 2023, 9:55 PM Rob Scott  wrote:
>
>> Peter,
>>
>> Can I strongly suggest you instigate a project to activate OPERCMDS (and
>> JESSPOOL if not already active).
>>
>> ISFPRMx just controls actions within SDSF and does not preclude any
>> semi-capable programmer from writing code to issue operator commands (or
>> access SYSOUT using the JES SSI).
>>
>> Starting with z/OS 2 5, SDSF no longer uses ISFPRMxx to control security
>> as everything now only goes through SAF authority. We use the SDSF class
>> for product controls, and also make OPERCMDS and JESSPOOL checks on the
>> user's behalf when processing actions taken within the product.
>>
>> Please be aware that converting your systems to correctly use OPERCMDS
>> and JESSPOOL can be a lengthy process, and you should allow many weeks for
>> testing and validation.
>>
>> The OPERCMDS and JESSPOOL classes being activated can affect a broad
>> range of other products including sysout archiving and automated operations.
>>
>> I do have some presentations about SDSF security and can point you in the
>> right direction if you want.
>>
>> As a further note, the old ISFACR tool that was written 25+ years ago to
>> aid in SAF security migration is showing its age a bit. We have some more
>> recent (and much simpler) tools and processes now.
>>
>> Rob Scott
>> Rocket Software
>>
>> Sent from Samsung Mobile on O2
>> Sent from Outlook for Android<https://aka.ms/AAb9ysg<https://aka.ms/AAb9ysg>>
>> 
>> From: IBM Mainframe Discussion List  on behalf
>> of Peter 
>> Sent: Saturday, December 2, 2023 9:31:26 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU 
>> Subject: zOSMF install - SDSF ISFPRMxx
>>
>> EXTERNAL EMAIL
>>
>>
>>
>>
>>
>> Hello All
>>
>> Good morning
>>
>> I have planned to install zOSMF in our test LPAR. Our SDSF uses its own
>> security features using ISFPRMXX and I can see zOSMF has its own IZUSEC
>> jobs where it activates OPERCMDS class. We never activated OPERCMDS
>> instead
>> we manage using ISFPRMXX PARMLIB member.
>>
>> Is there anyone who have installed zOSMF with above scenario?
>>
>> Peter
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>
>> 
>> Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA
>> 02451 ? Main Office Toll Free Number: +1 855.577.4323
>> Contact Customer Support:
>> https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport<https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport>
>> Unsubscribe from Marketing Messages/Manage Your Subscription Preferences
>> - 
>> http://www.rocketsoftware.com

Re: zOSMF install - SDSF ISFPRMxx

[Rob Scott]

Peter,

Can I strongly suggest you instigate a project to activate OPERCMDS (and 
JESSPOOL if not already active).

ISFPRMx  just controls actions within SDSF and does not preclude any 
semi-capable programmer from writing code to issue operator commands (or access 
SYSOUT using the JES SSI).

Starting with z/OS 2 5, SDSF no longer uses ISFPRMxx to control security as 
everything now only goes through SAF authority. We use the SDSF class for 
product controls, and also make OPERCMDS and JESSPOOL checks on the user's 
behalf when processing actions taken within the product.

Please be aware that converting your systems to correctly use OPERCMDS and 
JESSPOOL can be a lengthy process,  and you should allow many weeks for testing 
and validation.

The OPERCMDS and JESSPOOL classes being activated can affect a broad range of 
other products including sysout archiving and automated operations.

I do have some presentations about SDSF security and can point you in the right 
direction if you want.

As a further note, the old ISFACR tool that was written 25+ years ago to aid in 
SAF security migration is showing its age a bit. We have some more recent (and 
much simpler) tools and processes now.

Rob Scott
Rocket Software

Sent from Samsung Mobile on O2
Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
Peter 
Sent: Saturday, December 2, 2023 9:31:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: zOSMF install - SDSF ISFPRMxx

EXTERNAL EMAIL





Hello All

Good morning

I have planned to install zOSMF in our test LPAR. Our SDSF uses its own
security features using ISFPRMXX and I can see zOSMF has its own IZUSEC
jobs where it activates OPERCMDS class. We never activated OPERCMDS instead
we manage using ISFPRMXX PARMLIB member.

Is there anyone who have installed zOSMF with above scenario?

Peter

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



Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: RACROUTE REQUEST=AUTH problem

[Rob Scott]

Yes - so you have a "4,4,0"  set of SAF_RC,RACF_RC and RACF_RSN

From the RACROUTE macro docs , the RACF-RC/RSN means :

04
The specified resource is not protected by RACF.
If PROTECTALL is active, no profile is found, and the user ID whose authority 
was checked does
not have the SPECIAL attribute, RACF returns a return code X'08' instead of a 
return code X'04'
and denies access.
Reason code
Meaning
00
One of the following has occurred:
• There is no RACF profile protecting the resource.
• RACF is not active.
• Specified class is not in the RACF class descriptor table.
• Specified class (other than DSNR) is not active.
• Specified class requires SETROPTS RACLIST option to be active and it is not.
• CLASS TEMPDSN was active and the data set is a temporary data set.
• A userid of *BYPASS* has been passed on the authorization check. No profile 
checking will
occur.

You have at least one of the above conditions

Rob

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John Blythe Reid
Sent: Wednesday, November 29, 2023 4:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACROUTE REQUEST=AUTH problem

EXTERNAL EMAIL





Rob,

I'm looking at SAFPRRET and SAFPRREA in a test on our LPAR. After checking a 
non-existent resource SAFPRRET contains X'0004' and SAFPRREA contains 
binary zeros. Is the value in SAFPRRET the RACF RC ? The RACROUTE macro return 
code in R15 is also X'04'.

Regards,
John.

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: RACROUTE REQUEST=AUTH problem

[Rob Scott]

John

The next step is to examine the RACF RC associated with the SAF RC=4 as that 
will help narrow down the reason.

Rob

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John Blythe Reid
Sent: Wednesday, November 29, 2023 2:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACROUTE REQUEST=AUTH problem

EXTERNAL EMAIL





Hi Rob,

Thanks a lot for your reply. However, we executed the SETR LIST command and we 
can see that the classes involved are indeed active.

By the way, this is a conversion from Top Secret to RACF.

Regards,
John.

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: RACROUTE REQUEST=AUTH problem

[Rob Scott]

Is the class active on customer system?

Use "TSO SETR LIST" to examine class status information.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John Blythe Reid
Sent: Wednesday, November 29, 2023 10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RACROUTE REQUEST=AUTH problem

EXTERNAL EMAIL





Hello,

We have a CICS module that issues a RACROUTE REQUEST=AUTH to query a user's 
access rights to a resource. We execute the module on our LPAR and it works 
fine returning RC=0 if the user has access.

When we put that same CICS module on our client's LPAR the RACROUTE 
REQUEST=AUTH always returns RC=04 as though the resources weren't defined to 
RACF. If we take one of the resources that the module didn't find and display 
it using 'TSO RL class resource' RACF displays the resource details ok. So the 
resources are correctly defined but the RACROUTE macro never appears to find 
them.

The z/OS level is the same: 2.4; and the RACF level in the RACROUTE macro is 
the same: 1.9.

It's a bit of a mystery. Anyone have any ideas ?

Regards,
John.

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Abend producing SDWARBAD

[Rob Scott]

I must admit to being quite twitchy at the thought of a general purpose 
recovery routine trying to be too clever.

I like to keep it as simple as possible and avoid making any recovery situation 
worse by going off the rails chasing unicorns during recovery logic.

FWIW - the recovery design goals I use :

(o) Locate the parm area passed by the routine that setup the recovery
(o) Copy the diagnostic grab bag from the SDWA and populate the recovery parm 
area output fields
(o) Decide if we are going to issue SDUMP/IEATDUMP based on caller provided 
options and/or the type of abend code
(o) Create good VRADATA so that DAE can suppress duplicates
(o) Restore registers using caller provided options and/or saved values in the 
parm area
(o) If retry is possible and asked for then do so otherwise percolate

The code I write normally has the recovery routine retry to a point in the 
mainline code that established the recovery.

The mainline will also have access to the recovery parm area that contains the 
diagnostic grab bag.

This mainline leaves breadcrumbs representing resources to release/handle 
during recovery and these can be processed by logic in the mainline.

I also use a stack of recovery blocks so that the code can nest recovery 
requirements as logic dictates using PUSH/POP without having to go through 
ESTAE/ARR/FRR setup each time.

Rob Scott
Rocket Software


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Wednesday, November 29, 2023 1:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Abend producing SDWARBAD

EXTERNAL EMAIL





Hi Joseph,

Just so everyone is clear, you're upgrading CBT192 (generic abend diagnostics / 
recovery - ESTAEX, FRR, ARR, ...) to include new diagnostic information. You're 
charged with mapping the abending address to a load module and the offset into 
that load module which will be displayed as part of the abend diagnostics. Ask 
yourself if this is useful except in the most basic scenarios.

There are flaws in using RB's (PRB, SVRB, IRB, ...)  to determine the load 
module.  It doesn't work for PC routine abends captured by a PRB ESTAE.  It 
assumes that all load modules are executed using (LINK, XCTL, ...) which 
creates an RB (PRB, SVRB, IRB, ...). It ignores the common practice of using 
LOAD with branch tables. What about RBs that have terminated with the abend 
percolated into the next RB? I'm sure there are more.

I suggest that you code macros for new diagnostics you add. This simplifies 
users' ability to choose, customize, replace and eliminate functionality 
instead of having a single large module. In this case, I suggest giving them a 
few options.

Always ask yourself, where you could be exposing a normal sysprog to some grief 
and how you should warn them of potential dangers. In my opinion, everyone 
ignores the danger in the single most dangerous z/OS exit, The WTO exit can be 
exposed to every possible z/OS restriction. Messages from RSM, IOS and others 
can be issued from problematic states. For example, device allocation because a 
disk volser is misspelled.

You were asked specifically to display load module name and offset. I 
personally find this useless because without a dump, you cannot identify the 
CSECT with offset. You have an abend at some unknown CSECT name that is linked 
in the load module. SMP/e complicates this further because it does not do a 
complete link. Instead, it replaces modules (CSECTs) that have been changed 
which changes the CSECT sequence. While you could provide this as an option, 
the question is why? You can't determine the cause in any way except that it 
was in a specific load module.

I personally would provide a second option that can determine CSECT name and 
offset using saveareas (possibly linkage stack).and base reg. You would need to 
document how to be compatible with what people call baseless code where a 
register points to literals. I don't know about how others implement it. My 
personal implementation starts the csect with a SAVE (14,12),,'module info' 
that never gets executed followed by the program constants. To avoid loading 
constants to the instruction buffer, I have an ENTRY statement where the 
executable code starts, followed by a SAVE (14,12) and LARL Rxx,csect_name. 
This eliminates the need to calculate offsets into the program.

From a diagnostic standpoint, it looks like a standard program where a J or B 
is followed by a length & eyecatcher. My recovery diagnostics find the reg (R12 
for my programs) that is within 12K of the failing address and verify there is 
a J or B.

A third option is to give sample code that requires user mods in the case they 
don't follow standard conventions.

You should ask the group because I suspect that others will have 
recommendations and preferences. Maybe ask the assembler group too.

On Tue, 28 Nov 2023 12:41:21 -0500, Joseph Reichman  
wrote:

>Sam asked me to update file 192 in cbttape
>
>

Re: ATTACHX/STIMERM WAIT=YES

[Rob Scott]

If the OP would like to see some example source for this sort of thing, I 
included simple task and timer interactions in the "Example Cross-Memory 
Server" code I wrote for Share Dallas.

You can download the code from :

https://github.com/rscott-rocket/mxe

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Harminc
Sent: Tuesday, November 14, 2023 2:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ATTACHX/STIMERM WAIT=YES

EXTERNAL EMAIL





On Mon, 13 Nov 2023 at 19:37, Paul Schuster  wrote:

> How to handle this situation: task ‘A’ attaches a subtask, task ‘B’.
>
> The ‘B’ task issues a STIMERM WAIT=YES
>
> Task ‘A’ terminates, but gets the A03 abend since task ‘B’ still active.
>
> How can task ‘A’ communicate to the subtask ‘B’ that it (task ‘B’)
> needs to terminate?  Task ‘B’ is in the STIMERM wait, so it can’t do anything.
>

The typical approach is to not use WAIT on the STIMERM in Task B, but rather 
specify a local ECB to be POSTed. Then do your own WAIT, specifying both that 
ECB and also an ECB that Task A passes to Task B as an argument on the 
ATTACH[X]. When Task A wants to shut things down, it POSTs the ECB it passed to 
B, and then in turn *it* WAITs on the other ECB that you specified on the 
ATTACH with ECB=. When Task B awakes from its WAIT, it checks which ECB was 
posted. If it's the STIMER one, it does whatever it does for that, and goes 
back and re-issues the STIMERM and the WAIT. If it's the one saying "A says to 
shut down", B cleans up and returns to the system, which then POSTs the ECB 
that A put on the ATTACH.

This assumes that in your description Task A *intends* to shut down B and then 
itself. If Task A instead terminates unexpectedly, then you need to figure out 
what you *want* it to do. You could put ESTAI= on the ATTACH, and catch B's 
abend there. But if A abended in the first place...

This isn't really as complex as I'm making it sound with a poorly organized 
description. Just don't do that WAIT on the STIMERM.

Tony H.

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: RACF, the FACILITY class, and z/XDC

[Rob Scott]

Although setting up your own SAF class is not difficult, it is another step in 
the installation/migration process and my instinct  (bearing in mind the 
squeeze on staffing resources) is always to tend to "zero-config" wherever 
possible.

If you stay within your lanes as far as the profile namespace is concerned 
,then XFACILIT makes sense in most cases.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Sunday, November 12, 2023 8:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF, the FACILITY class, and z/XDC

EXTERNAL EMAIL





Ed Jaffe recommended against creating a SAF class. I'll respectfully suggest 
that it's not that hard.

First, if you do, IBM told us, "Start the class name with a dollar sign-we'll 
never use those". Of course you could collide with another vendor, but that's 
unlikely.

We've had customers doing so for 13 years or so. Besides some folks who didn't 
understand how to use their own ESM, we've had no problems. ACF2 and TSS were 
easy, too.

Now, I admit that our usage is pretty simple: we have named data protection 
entities called Cryptids, and you can use them to protect 
(encrypt/tokenize/hash) or access (decrypt/detokenize) data. So if you have a 
Cryptid named BANANA, a user needs READ or greater authority to PROTECT.BANANA 
or ACCESS.BANANA, as appropriate to use BANANA to protect or access.

For something like EJES, with possibly dozens of subtleties, it would surely be 
harder. The complexity of SAF related to certificates comes to mind, though I 
suspect some of that is due to some historical mistakes. Still, once you've 
defined a scheme, it's just PERMITs, right?


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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: RACF, the FACILITY class, and z/XDC

[Rob Scott]

Another option is the XFACILIT class which supports much longer profile names ( 
up to 246 characters).

Rob Scott
Rocket Software

Sent from Samsung Mobile on O2
Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
Binyamin Dissen 
Sent: Sunday, November 12, 2023 11:02:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: RACF, the FACILITY class, and z/XDC

EXTERNAL EMAIL




You should make your own class.

Classes can be dynamically added by adding to the CDT class.

On Sun, 12 Nov 2023 05:40:03 -0500 David Cole  wrote:

:>I've got a problem. Decades ago, I made some assumptions about RACF's
:>FACILITY class that have turned out to be wrong.

:>Currently, I'm working on implementing a new security rule for z/XDC,
:>and the individual rules ("entities") can be up to 59 characters long.

:>Decades ago, when I was porting z/XDC's security rules from ACF2 to
:>RACF, I made the decision to piggy-back my security rules into RACF's
:>FACILITY class. I didn't know much about RACF then (and I still
:>don't), and it did not occur to me that rule length would be an
:>issue. I was wrong. It is an issue.

:>Yesterday, I was testing with an instance of the new rule that was 44
:>characters long. Boom! My "RACROUTE REQUEST=AUTH" (racheck) call
:>failed with "ICH409I 282-054 ABEND DURING RACHECK PROCESSING". This
:>basically means that the entity I passed (my 44-character rule) was
:>too long for its class (FACILITY).

:>Ouch!

:>So now I have several questions that I'm hoping someone here can
:>provide answers to.
:> * What is the longest entity the FACILITY class will accept?
:> * Where do I find that specific fact doc'd?
:> * Is there a command that will display that information?
:> * Is there a catch-all class that z/XDC can use for its rules
:>other than FACILITY?
:> * Where do other vendors put their rules?

--
Binyamin Dissen 
http://www.dissensoftware.com<http://www.dissensoftware.com>

Director, Dissen Software, Bar & Grill - Israel

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


Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SMF record for number of program executions?

[Rob Scott]

As others have pointed out, monitoring the "fetch" of a load module is very 
doable, whereas monitoring any subsequent usage of the executable is much more 
difficult.

In z/OS 3.1, SDSF introduced the "module fetch monitor" feature that was 
inspired by the previous Poughkeepsie tool "MFM". We sit on the CSVFETCH and 
CSVLLIX1 dynamic exits to capture both program fetch and VLF fetch events (no 
need to front-end SVCs).

This capability might provide some insight into what you require, however it 
cannot tell the whole story.

Rob Scott
Rocket Software


From: IBM Mainframe Discussion List  on behalf of 
Steve Thompson 
Sent: Thursday, November 9, 2023 10:15:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: SMF record for number of program executions?

EXTERNAL EMAIL





If you are willing to write an exit to get the info, you can get
it via a CSV exit (I forget its name, but ALL "LOAD"s go through
it). Understand, if you use that exit, it has to have a very
short code path, can't cause a wait of any kind, or you will
cause problems for all address spaces in that LPAR. The idea is
to capture the DSN & member and immediately write it to an SMF
buffer or similar so you can immediately return control.

But other than what others have said, there is no other way to
see all dynamically loaded subroutines or load-modules. You will
not capture static routines as the LNKEDT doesn't use that
interface.

I believe that IBM Products make use of that or another
undocumented path through VLF that is handling LLA and a bit of
caching of modules.

Regards,
Steve Thompson



On 11/9/2023 4:56 PM, Glenn Miller wrote:
> Hi Linda,
> When I have been requested to provide that information, I have used the IBM Z 
> Software Asset Management ( aka iZSAM ) software product, which was 
> previously known as IBM Tivoli Asset Discovery for z/OS ( aka TADz ).
>
> Glenn Miller
>
> --
> 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



Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: IEE342I MODIFY REJECTED-TASK BUSY - yet modify command is immediately processed

[Rob Scott]

Here is what I suspect is happening - note that I don't have access to the z/OS 
BCP code - so some of this is semi-educated guess :

(o) CONSOLE operator command processing is fairly simple and its main purpose 
here is to add a CIB to the appropriate queue for the responding address space

(o) IEE342I is issued when the queue is  full (or indeed when CIBCNT=0 - the 
effect is the same)

(o) When the modify command comes in, the CSCB chain is run and ANY match on 
the PROCNAME or ID (CHPROCSN and CHKEY for STC) triggers the logic to attempt 
to add the CIB to that address space queue

(o) CIB queue pointer and max number of queued CIBs maintained in CSCB

(o) Processing does not stop after first match - it will continue until end of 
CSCB chain

(o) So if any STC address space shares the same CHPROCSN/CHKEY as your STC 
PROCNAME and has NOT setup communications with the CONSOLE using QEDIT etc, you 
will get IEE342I

(o) Even if the above is true, your STC will process the CIB as expected.


For giggles, you can try this on a test system and see how many IEE342I 
messages you get in response :

"F INIT,XYZ"


Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Support, DUNNIT SYSTEMS LTD.
Sent: Wednesday, October 18, 2023 10:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEE342I MODIFY REJECTED-TASK BUSY - yet modify command is 
immediately processed

EXTERNAL EMAIL





Hi Rob,

Q1 : Is the jobname unique on the system?

A1 : Yes. BTW, STC, not JOB.

Q2 : What happens when you start the address space using "S PROCNAME.MYID" and 
then issue "F MYID,command" ?

A2 : with MYID, all's normal - no message IEE342I issued. Shut it down, 
restarted without ID and the problem is back.

Why is that?

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: IEE342I MODIFY REJECTED-TASK BUSY - yet modify command is immediately processed

[Rob Scott]

Q1 : Is the jobname unique on the system?

Q2 : What happens when you start the address space using "S PROCNAME.MYID" and 
then issue "F MYID,command" ?

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Support, DUNNIT SYSTEMS LTD.
Sent: Wednesday, October 18, 2023 10:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEE342I MODIFY REJECTED-TASK BUSY - yet modify command is 
immediately processed

EXTERNAL EMAIL





No z/OS Unix Services used.

Good ol' fashioned MVS assembler program.

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: IEE342I MODIFY REJECTED-TASK BUSY - yet modify command is immediately processed

[Rob Scott]

Does this program use z/OS Unix services to spawn child processes to handle 
modify commands?

There can be issues with IEE342I being issued when base jobname is 8 chars long 
and a different jobname cannot be formed by appending an extra character.

Rob Scott
Rocket Software



Sent from Samsung Mobile on O2
Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
Support, DUNNIT SYSTEMS LTD. 
Sent: Tuesday, October 17, 2023 3:54:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: IEE342I MODIFY REJECTED-TASK BUSY - yet modify command is immediately 
processed

EXTERNAL EMAIL





I don't recall this happening until relatively recent z/OS versions. Not sure 
when it began.

Program code, Assembler, has not been modified for ages.

Happens even when a single MODIFY command is issued even way after the program 
initialized and is waiting for commands. In any case, the modify command is 
processed.

QEDIT macros in program are set to CIBCTR=1.

After extracting and operator command's text, the CIB is freed and R15 is 
always zero.

TIA.

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


Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Question About IEFSSI REQUEST=QUERY

[Rob Scott]

Paul

My approach would be along the lines of :

(o) Zero the field that is to contain the output workarea address (to ensure no 
pollution)
(o) Prime the subpool input value
(o) Call IEFSSI
(o) Do your logic
(o) Test field that contains output workarea address - if non-zero release with 
subpool specified earlier.

Personally I would not check the RC+RSN from IEFSSI to dictate the storage 
release, and would rely on the service only populating the output workarea 
address when there is caller action required.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
esst...@juno.com
Sent: Thursday, October 12, 2023 3:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Question About IEFSSI REQUEST=QUERY

EXTERNAL EMAIL





Hello,.Looking at the IEFSSI REQUEST=QUERY - It is recommended to Free the 
WorkArea when he request completes -.
Is it safe (as in a good practice) to always release the workarea when the 
WORKAREA address returned is non-zero. ?
.
Meaning once the program has evaluated the return code, the program can RELEASE 
the WORKAREA storage if WORKAREA Address is non-zero.
.
The examples seem to always release the WORKAREA regardless of the address 
returned in workarea and regardless of the return code...What AM I miss 
understanding .Paul D'Angelo .

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SMP/E and PATH existence

[Rob Scott]

Jon

Obviously APPLY CHECK is standard practice, however this will only check the 
DDDEFs referenced by the FMID/PTF being applied in the current target zone.

The purpose of these "check DDDEF" utilities is to validate the entire CSI 
across multiple zones.

Back in the day, I used to run them after cloning a CSI or performing ZONEEDIT 
functions.

I found them especially useful at sites where the sysprog team might well be 
producing system software configurations for multiple customers.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Tuesday, October 10, 2023 5:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E and PATH existence

EXTERNAL EMAIL





On Fri, 6 Oct 2023 15:46:25 +, Rob Scott  wrote:

>This was precisely the reason for the original implementation of DDDEFCHK/PTH.
>
>Being able to quickly sniff-test the DDDEFs (across multiple
>target/dlib zones) before an APPLY that might take many minutes was
>deemed useful (well .. at least to me at the time...25 years ago)

Is APPLY CHECK no longer standard practice when installing a PTF or product? 
Quackenbush says checking DDDEF's externally is unnecessary and will only take 
take the time required for APPLY CHECK.

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SMP/E and PATH existence

[Rob Scott]

Phil

This was precisely the reason for the original implementation of DDDEFCHK/PTH.

It could be that you have cloned the CSI, or performed some updates via 
ZONEEDIT or just wanted to make sure that no-one had moved/deleted anything 
since last-known-good.

Being able to quickly sniff-test the DDDEFs (across multiple target/dlib zones) 
before an APPLY that might take many minutes was deemed useful (well .. at 
least to me at the time...25 years ago)

Rob
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Friday, October 6, 2023 1:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E and PATH existence

EXTERNAL EMAIL





Jon Perryman wrote:
>Kurt is saying that APPLY CHECK does exactly what you want. CHECK
>verifies SMP/e has everything expected and will run 100% through. If 3
>DD / DDDEF's are missing, then you should see those 3 errors and any
>other errors that SMP/e detects. APPLY CHECK only validates DD /
>DDDEF's that are needed for the apply and ignores all other DD /
>DDDEF's. I've never experienced missing DD / DDDEF's, so I'm basing
>this on Kurt's recommendation.

Yep, I got that, thanks. But understand that by that point, they're halfway 
through the install. Far better for it to fail first thing, so they can fix 
that and then run through the entire process. Remember how alien many z/OS 
folks think USS is.


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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SMP/E and PATH existence

[Rob Scott]

Phil,

A long time ago, I wrote a program called DDDEFCHK that used the SMP/E API to 
check if normal DDDEF data sets exist - there is also a DDDEFPTH companion 
program to handle paths.

I believe these programs still exist in the public domain in the CBT tape site 
(www.cbttape.org) - see files 411 and 412.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Thursday, October 5, 2023 4:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMP/E and PATH existence

EXTERNAL EMAIL





Is there a way to get SMP/E to validate the existence of a USS path on a DDEF? 
Thanks to y'all's help, I have externalized the USS path we use to a variable. 
However, if the directory doesn't exist, the user can get pretty far (to the 
RECEIVE step) before that's recognized. I've looked at the SMP/E doc but didn't 
find anything.

I realize I can do this with BPXBATCH:
//TESTDIR  EXEC PGM=BPXBATCH,PARM='SH test -d '

Or with IDCAMS:
//TESTDIR  EXEC PGM=IDCAMS,PARM='GRAPHICS(CHAIN(SN))'
//SYSINDD *,SYMBOLS=(JCLONLY,JESJCL)
ALLOCATE   DDNAME(VSHZFS1) PATH('')

But this seems like something SMP/E might reasonably also do "natively". Can it?


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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Utility to Read from JES2 spool

[Rob Scott]

To generate sample SDSF REXX - issue the "RGEN X" command and choose an example 
from the list - there are the following including :

Browse job output with EXECIO
Browse job output with ISFBROWSE
Browse job output with ISFBROWSE - groups of lines

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Roberto Halais
Sent: Friday, September 29, 2023 4:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Utility to Read from JES2 spool

EXTERNAL EMAIL





Thank you all. You have given me many options.
Back to the drawing board.

On Fri, Sep 29, 2023 at 11:09 AM Michael Babcock 
wrote:

> Programmatically or manually?  Manually,  in SDSF, you can always put
> a question mark next to the output and put an XDC next to the output you
> want. Or skip the question mark and XDC the entire job.   See the SDSF help
> for XDC.
>
> On Fri, Sep 29, 2023 at 9:10 AM Roberto Halais
> 
> wrote:
>
> > Listers:
> >
> > Is there an z/os utility that will allow the reading of a spool file
> > (in some class) and copy it to a sequential dataset?
> >
> > We need to read a report from spool and copy it o a sequential dataset.
> > Just a z/os utility or a CBT tape utility.
> > Thank you for any pointers.
> >
> > 
> > -- 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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Retrieve LPAR weight without BCPii HWIQUERY ?

[Rob Scott]

I am guessing they use the "diagnose" instruction to retrieve this information 
( Diag 204 if memory serves correctly).

There are other ways to get this information including intercepting SMF 70 
records, and calling RMF monitor III programming interfaces.

Rob Scott
Rocket Software.

Sent from Samsung Mobile on O2
Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
Boesel Guillaume 
Sent: Thursday, September 28, 2023 2:20:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Retrieve LPAR weight without BCPii HWIQUERY ?

EXTERNAL EMAIL





Hi,

With HWIQUERY, I'm able to retrieve the weight of a LPAR but, of course, it 
doesn't work if BCPii is not started.

Mainview (LPARACT view) or Sysview (PRISM command) are able to retrieve this 
information on LPARs without BCPii.

Is somebody could help me to understand how products like Mainview or Sysview 
are able to retrieve the weight of a LPAR without BCPii ?

Thank you for your help,
Regards

Guillaume

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



Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Bob Shannon

[Rob Scott]

It is with great sadness that I have to inform this forum that Bob Shannon 
passed away unexpectedly last week aged 75.

Bob was the systems programming manager at Rocket Software from 2003 until his 
retirement in 2016.

He was a real character, and anyone working at Rocket during that time will 
have memories of Bob that will make them smile.

During his long career he was also a developer at Compuware, however many 
people on this list probably know Bob from his work with Share on the MVS 
project track.

He leaves behind his wife of 50 years, Vicky, and two daughters.

A knowledgeable and helpful man, he will be fondly remembered and keenly missed.

Rob Scott
Principal Architect, Mainframe Systems Tools
Distinguished Engineer
Rocket Software
77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
Tel: +1.781.684.2305
Email: rsc...@rs.com<mailto:rsc...@rs.com>
Web: www.rocketsoftware.com<http://www.rocketsoftware.com/>



Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SDSF and JESSPOOL

[Rob Scott]

Michael

Although we strongly recommend JESSPOOL (and OPERCMDS) being active, you can 
use successfully use SDSF without it.

The big difference in z/OS 2.5 is that SDSF will no longer fall back to any 
legacy ISFPRMxx authority keywords on the GROUP statements when SAF returns 
RC=4.

How SDSF handles SAF RC=4 (returned when the ESM cannot make a determination - 
for example the class not active or no matching profile) is governed by the 
AUXSAF(FAILRC4/NOFAILRC4) keyword on the CONNECT statement in ISFPRMxx.

The default value of FAILRC4 means that SDSF will translate RC=4 from SAF into 
a "denied" response, whereas NOFAILRC4 will translate to "allowed".

So you could keep JESSPOOL inactive and use AUXSAF(NOFAILRC4) on your rescue 
system and this will help overcome most obstacles, however there is another way 
:

SDSF has the concept of "destination operator" within the product dating back 
decades to the time when companies had print operations staff that needed to 
manage individual destinations regardless of the output-creating userid.
Profiles in the SDSF class of ISFOPER.DEST.destname would allow print operators 
to manage output on individual destinations without specific authority to the 
spool object.

On top of individual destination authority, there is a profile 
ISFOPER.ANYDEST.jesname in the SDSF class which, when the user has READ 
authority, performs a RECVR handshake with JES on the JESSPOOL RACROUTE request 
to grant access to the output.  So you could permit your sysprogs on the rescue 
system to this profile and keep JESSPOOL class active while allowing you to 
implement other profiles so that it is consistent with non-rescue system (if so 
desired).

One thing to note is that JESSPOOL and OPERCMDS classes are not owned by SDSF, 
we check profiles in these classes on the user's behalf to enhance the user 
experience, however the owning components will make their own authority 
decisions when SDSF passes thru any request for data/action (and also when 
access is attempted outside of SDSF - for example from a SYSOUT archiving 
product or automated operations).

I do have a "How SDSF Security Works" presentation that is available on IBM 
Education github :
https://github.com/IBM/IBM-Z-zOS/tree/main/zOS-Education/zOS-V2.5-Education


Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Babcock
Sent: Wednesday, September 20, 2023 6:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF and JESSPOOL

EXTERNAL EMAIL





We have a rescue system that we just brought up on z/OS 2.5.   I
couldn't access SDSF so I defined the appropriate groups, modified ISFPRMxx and 
restarted SDSF, logged off and back on.  I could then get into SDSF.  I could 
NOT access ANY output whatsoever.  I kept getting NO DISPLAYABLE DATA.  We did 
not have the JESSPOOL class active on that system.  Now the SDSF security 
migration guide says that JESSPOOL class activation is not REQUIRED, but until 
I activated that class, I could
not access any output.   Is the book wrong or did I have something not
quite set right?

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Why it’s important to take Seymour’s advice

[Rob Scott]

Joe,

Once again, can I strongly suggest that you pause your functionality 
development for a while and invest some time into :

(O) A robust general purpose recovery routine that can be used in all modes 
(prob/sup and TCB/SRB).
This routine should focus on grabbing diagnostic information into a structure 
that your mainline code can understand and also modify its behaviour based on 
the program that established it. You can design a structure that the 
establisher passes as a parm on the ESTAE/ARR or FRR. Make it as generic as 
possible so that you can reuse in other projects.
This would include whether to retry , what regs to restore , whether to take 
SDUMP or TDUMP, whether to issue messages via WTO etc etc

(O) A comprehensive internal trace facility that can help you diagnose program 
flow issues and remove a lot of guesswork when issues arise. Even in its 
simplest form, adding a footprint into an internal circular memory buffer can 
greatly enhance your ability to debug. A few days writing IPCS rexx to locate 
and print out your trace buffer contents could save you weeks of 
head-scratching down the road.

Writing this stuff once and doing a good job on it can gain you years of 
benefit.

Rob Scott
Rocket Software.

Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
Joseph Reichman 
Sent: Friday, September 15, 2023 11:16:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Why it’s important to take Seymour’s advice

EXTERNAL EMAIL





Seymour

First let me wish you a good year

I did schedule the irb in the ikjeft01 TCB against Seymour’s advice for a 
return code of zero from schedirb

However the TMP Estae issued an SDUMP

I guess it didn’t like me scheduling an irb in its TCB

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



Rocket Software, Inc. and subsidiaries ¦ 77 Fourth Avenue, Waltham MA 02451 ¦ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Mysterious S0C4 pic 10

[Rob Scott]

Joe,

I know that you are writing a lot of assembler code in your spare time without 
access to debugging software like zXDC , so I would advise the following as a 
good investment of your time as working out errors in code just from dumps can 
be difficult:

(O) write yourself an internal trace tool that can dump out regs and named 
storage areas during runtime (maybe activated by special ddname or parameter). 
Make this code generic so that you can use it in all your projects.

(O) insert trace points before and after major logic points and any internal or 
external calls.

(O) consider improving your naming standards so that reading the code is easier 
and obvious typos appear more frequently. A good example is using something 
like "struct_field_name" for fields inside your own struct

(O) consider working storage as a struct and apply the same rules as above

(O) have a naming standard for constants (and this includes model list forms of 
macros that you prime parameter lists from)

Hope this helps

Rob Scott
Rocket Software

Sent from Outlook for Android<https://aka.ms/AAb9ysg>


From: IBM Mainframe Discussion List  on behalf of 
Joseph Reichman 
Sent: Monday, September 11, 2023 4:09:35 pm
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Mysterious S0C4 pic 10

EXTERNAL EMAIL





No it’s not the ESTAE but the code that populates the parameter list to it
 it when I comment that out

Later on the BASR to pars works

Is there some thing like setting a slip trap that might help me
Thanks

Joe Reichman


On Mon, Sep 11, 2023 at 11:05 AM Tony Harminc  wrote:

> On Mon, 11 Sept 2023 at 09:33, Joseph Reichman 
> wrote:
>
> > I have the following lines of code which basically sets up the parameter
> > list to an ESTAE and calls it
>
> > Later on when I populate Parse Parameter list   and call IKJPARS I get a
> > s0c4 pic 10 right after the BALR
>
> There's no BALR in the code snippets you've shown. I'll assume you mean
> BASR.
>
> > When  I comment out the code below (that sets up the ESTAE parameter
> list)
> > everything with PARS works great
> > I check and double checked there is no storage overlay, I am just looking
> > for guidance how to debug this
>
> Two basic approaches: Top Down and Bottom Up. Start at the bottom -
> what is the failing address causing your PIC 10? Does it look
> plausible for the AMODE you're in at the time? Which instruction
> actually failed? Is the failing address (or a near or left-truncated
> version of it) in a register?
>
> Etc...
>
> If that hasn't made the problem obvious, then you may have collected
> enough information to work from the top down. If it's true that the
> ESTAE is provoking the failure, then what does it change, i.e. how
> could anything it does affect the result of calling IKJPARS?
>
> Etc...
>
> 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




Rocket Software, Inc. and subsidiaries ¦ 77 Fourth Avenue, Waltham MA 02451 ¦ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SDSF REXX Question

[Rob Scott]

Lionel

isfreset("all") will drop all SDSF special variables.  It won't drop any column 
stems.

However, we are not sure if dropping a variable always releases the storage.  
We have seen cases where REXX just marks the SVB available but the storage is 
still allocated.

Rob Scott
Rocket Software


From: IBM Mainframe Discussion List  On Behalf Of 
Lionel B. Dyck
Sent: Wednesday, September 6, 2023 3:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF REXX Question

EXTERNAL EMAIL



After using the SDSF REXX API and issuing the "rc = isfcalls('off')" is
there a way to release/free the storage that the various calls to the API
have allocated. I know I can do a "drop isfulog." But is there a general
way?

TIA


Lionel B. Dyck <><
Website: https://www.lbdsoftware.com<https://www.lbdsoftware.com>
Github: https://github.com/lbdyck<https://github.com/lbdyck>

"Worry more about your character than your reputation. Character is what you
are, reputation merely what others think you are."   - - - John Wooden

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


Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: RACF for using SDSF

[Rob Scott]

Joseph,

I think you need to use the "CONNECT" command instead of ALTUSER :

CONNECT userid GROUP(group_name)

Afterwards a "LISTUSER userid" command should list all groups that the user is 
connected to.

As most sites run with "list of groups checking", there is normally no need to 
change the default group after a CONNECT.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Joseph Reichman
Sent: Monday, September 4, 2023 3:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RACF for using SDSF

EXTERNAL EMAIL





Hi



I am getting the following message on my ADCD system



ISF024I USER ADCDANOT AUTHORIZED TO SDSF, NO GROUP ASSIGNMENT



I tried  ALU ADCDA GROUP(SYS1) this is the group that my other tso Is which has 
access to SDSF



Regardless after I do the command and do a LU ADCDA the group still shows up as 
TEST



When doing ALU ADCDA DFLTGRP(SYS1) racf says its not connected



thanks


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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Copy Jes2 Joblog

[Rob Scott]

Munif

You could use SDSF REXX to achieve what you want quite easily. You could either 
insert a separator between each DD, or write to a new member of a PDS with 
(maybe) member name = DD name.

Sample SDSF REXX statements can be generated using the in-product "RGEN" 
command (which will produce the code to navigate to where you currently are in 
the product) or the "RGEN X" command which presents a list of samples to choose 
from.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Munif Sadek
Sent: 18 July 2023 14:25
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Copy Jes2 Joblog

EXTERNAL EMAIL





Is there a way (like sdsf XDC) to copy JES2  job output either to a dataset or 
ZFS with segregation of JESMSGLG JESJCL JESYSMSG SMPOUT SMPRPT SMPLOG SYSPRINT 
etc

rather as a PS.

regards
Munif.

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: which configuration members were used when a zos system ipl

[Rob Scott]

The SDSF command “SYSP” will show them – and if you are z/OS 2.5 you can use 
the “L” action against those that have member suffix specifications to show 
them in the logical PARMLIB concatenations.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: 18 July 2023 00:50
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: which configuration members were used when a zos system ipl

EXTERNAL EMAIL



You can specify most configuration members like LPA, PROG, OMVS as options on 
the D IPLINFO command. The response back will display what was used at IPL time.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com<https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com>


--- Original Message ---
On Monday, July 17th, 2023 at 7:14 PM, Jason Cai 
mailto:ibmm...@foxmail.com>> wrote:


> Hi all
>
> I need to know which configuration members were used when a zos system IPL, 
> of course I can confirm them one by one with my eyes, is there any other way 
> to find them faster such as tools, rexx code and what good ideas. Any 
> suggestions are greatly appreciated.
>
> Thanks a lot!
>
> Jason Cai
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu<mailto: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<mailto:lists...@listserv.ua.edu> with 
the message: INFO IBM-MAIN


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SSRB/SSRX and LOCAL locks question

[Rob Scott]

Dave

I will setup an offline conference call to discuss this with both you and my 
colleague.

He will be able to answer any/all questions in this area.

Rob

From: IBM Mainframe Discussion List  On Behalf Of 
David Cole
Sent: 31 May 2023 17:54
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SSRB/SSRX and LOCAL locks question

EXTERNAL EMAIL



Thanks Rob. That sounds rather definitive. And of course for
scheduling SRBs, that make perfect sense.

But let me change the question slightly. I'm actually more interested
in suspended local SRBs. I.E. SSRBs and SSRXs. Are they stabilized
when the LOCAL lock is held?

Thanks,
Dave






At 5/31/2023 09:52 AM, Rob Scott wrote:
>Dave
>The answer from a work colleague who knows a LOT about the dispatcher is :
>"The answer is no. SRB scheduling/dispatching does not use the local
>lock unless the SRB requests the local lock on dispatch. If so it
>is obtained (or suspended to wait for it) as the dispatch occurs."
>Rob Scott
>Rocket Software
>
>>From: IBM Mainframe Discussion List 
>>mailto:IBM-MAIN@LISTSERV.UA.EDU>> On
>>Behalf Of David Cole
>>Sent: 31 May 2023 11:01
>>To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
>>Subject: Re: SSRB/SSRX and LOCAL locks question
>>EXTERNAL EMAIL
>>
>>
>>I was enquiring specifically about SRBs, not RBs.
>>Dave Cole
>>
>>
>>
>>At 5/31/2023 05:25 AM, Binyamin Dissen wrote:
>>> >I don't see how that answers either question.
>>> >The need for SUSPEND RB caller to be disabled is to allow the
>>> resume process
>>> >to resume it. You cannot schedule the resume process until the suspend as
>>> >otherwise the resume may try resuming before the suspend
>>> completes, causing
>>> >the later suspend to never wake up. It works different than ECBs.
>>> >On Wed, 31 May 2023 18:38:58 +1000 Attila Fogarasi
>>> mailto:fogar...@gmail.com<mailto:fogar...@gmail.com%3cmailto:fogar...@gmail.com>>>
>>>  wrote:
>>>> >>:>It's documented as needing either LOCAL or CML lock. See
>>>> >>:>https://www.ibm.com/docs/en/zos/2.2.0?topic=processing-suspen<https://www.ibm.com/docs/en/zos/2.2.0?topic=processing-suspen>
>>>> ding-rb-until-event-completes-suspend<https://www.ibm.com/docs/en/zos/2.2.0?topic=processing-suspending-rb-until-event-completes-suspend<https://www.ibm.com/docs/en/zos/2.2.0?topic=processing-suspending-rb-until-event-completes-suspend>>
>>>>
>>>> >>
>>>> >>:>
>>>> >>:>On Wed, May 31, 2023 at 6:20?PM Binyamin Dissen
>>>> >>mailto:bdis...@dissensoftware.com<mailto:bdis...@dissensoftware.com%3cmailto:bdis...@dissensoftware.com>>>
>>>> >>:>wrote:
>>>>> >>>:>
>>>>> >>>:>> On Tue, 30 May 2023 16:42:00 -0400 David Cole
>>>>> >>>mailto:dbc...@colesoft.com<mailto:dbc...@colesoft.com%3cmailto:dbc...@colesoft.com>>>
>>>>> >>> wrote:
>>>>>> >>>:>>
>>>>>> >>>:>> :>Does any know if suspended SRB control blocks (SSRB/SSRX) are
>>>>>> >>>:>> :>stabilized by holding the LOCAL lock? (I'm
>>>>>> considering logic in
>>>>>> >>>:>> :>support of setting up TRAP2 debugging for SRBs.)
>>>>>> >>>:>>
>>>>> >>>:>> I am also curious to know what "owner serialized" means.

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


Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SSRB/SSRX and LOCAL locks question

[Rob Scott]

Dave

The answer from a work colleague who knows a LOT about the dispatcher is :

"The answer is no. SRB scheduling/dispatching does not use the local lock 
unless the SRB requests the local lock on dispatch.  If so it is obtained (or 
suspended to wait for it) as the dispatch occurs."

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
David Cole
Sent: 31 May 2023 11:01
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SSRB/SSRX and LOCAL locks question

EXTERNAL EMAIL



I was enquiring specifically about SRBs, not RBs.

Dave Cole




At 5/31/2023 05:25 AM, Binyamin Dissen wrote:
>I don't see how that answers either question.
>The need for SUSPEND RB caller to be disabled is to allow the resume process
>to resume it. You cannot schedule the resume process until the suspend as
>otherwise the resume may try resuming before the suspend completes, causing
>the later suspend to never wake up. It works different than ECBs.
>On Wed, 31 May 2023 18:38:58 +1000 Attila Fogarasi 
>mailto:fogar...@gmail.com>> wrote:
>>:>It's documented as needing either LOCAL or CML lock. See
>>:>https://www.ibm.com/docs/en/zos/2.2.0?topic=processing-suspending-rb-until-event-completes-suspend<https://www.ibm.com/docs/en/zos/2.2.0?topic=processing-suspending-rb-until-event-completes-suspend>
>>
>>:>
>>:>On Wed, May 31, 2023 at 6:20?PM Binyamin Dissen
>>mailto:bdis...@dissensoftware.com>>
>>:>wrote:
>>>:>
>>>:>> On Tue, 30 May 2023 16:42:00 -0400 David Cole
>>>mailto:dbc...@colesoft.com>> wrote:
>>>:>>
>>>:>> :>Does any know if suspended SRB control blocks (SSRB/SSRX) are
>>>:>> :>stabilized by holding the LOCAL lock? (I'm considering logic in
>>>:>> :>support of setting up TRAP2 debugging for SRBs.)
>>>:>>
>>>:>> I am also curious to know what "owner serialized" means.

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


Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: IOF End of Support Direction.....

[Rob Scott]

I am not familiar with IOF functionality, however I do know that many years ago 
SDSF added the ability to issue action commands using the "row number" of the 
panel object.

To enable this facility issue "SET ROWNUM ON" to see the row numbers on each 
panel to the right of the "NP" column,  and then you can issue primary commands 
like "13 S" or "1-5 P" to perform actions against one or more rows on the panel.

This functionality was added at the request of a customer who was migrating 
from IOF to SDSF.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: 22 April 2023 01:43
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IOF End of Support Direction.

EXTERNAL EMAIL



By the way, just to respond to that one feature you like about IOF, you can
simulate that in SDSF by writing a REXX. If you're not a programmer at
heart then it isn't as good, I realize.

---
Bob Bridges, robhbrid...@gmail.com<mailto:robhbrid...@gmail.com>, cell 336 
382-7313

/* The more sophisticated the technology, the more vulnerable it is to
primitive attack. People often overlook the obvious. -Dr Who, 1978 */

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of
Longnecker, Dennis
Sent: Friday, April 21, 2023 17:13

Please excuse me if this is been asked already, haven't seen it.

https://www.triangle-systems.com/End%20of%20IOF%20Support.shtml<https://www.triangle-systems.com/End%20of%20IOF%20Support.shtml>

We have used IOF for quite a awhile, and frankly it has some wonderful
functionality that I haven't seen in SDSF (like the ability to send the
output to email address).

Curious what sites that use that product plans are.

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


Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: SMP/E JCLIN processing for job updates

[Rob Scott]

SCLM has been functionality stabilized for many years now - I would suggest 
trying to find another alternative.

Perhaps use Git for z/OS ?

You could maintain the master JCL in zFS directories under Git control with a 
"deployment" method to copy to run-time PDS/Es.

There is also Lionel Dyke's "zigi" tool that might be of interest.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: 21 April 2023 12:57
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E JCLIN processing for job updates

EXTERNAL EMAIL





Hi Wayne,
I see SCLM now in ISPF. I wasnt aware of it.
Is the IBM online doc good enough for a SCLM newbie?
thanks
Bill
On Fri, 21 Apr 2023 06:48:00 -0500, Bill Giannelli  
wrote:

>hi wayne,
>what is SCLM?
>On Fri, 21 Apr 2023 21:43:25 +1000, Wayne Bickerdike  wrote:
>
>>I would use SCLM if you don't have another source management tool.
>>
>>On Fri, Apr 21, 2023 at 9:37 PM Bill Giannelli
>>
>>wrote:
>>
>>> Do many of you out there use SMP/E JCLIN processing to track and
>>> save job updates?
>>> Currently we do not make use of this and manually keep JCL up to date.
>>> It seems there is a value to have SMPe ke
>>>
>>> 
>>> -- For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO
>>> IBM-MAIN
>>>
>>
>>
>>--
>>Wayne V. Bickerdike
>>
>>--
>>For IBM-MAIN subscribe / signoff / archive access instructions, send
>>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: location of JCL for started task

[Rob Scott]

The PROC panel in SDSF can be used to show the JES2 PROCLIB concatenations and 
from there you can issue "SRCH mask" to hunt for a member name mask.

If the STC in question was started under JES2 subsystem, this might help the OP 
locate the source of the JCL.

Note that the SRCH command can be used on any panel that contains lists of data 
sets that might include PDS/E, including LNK, LPA, PARM and JDD.

Rob Scott
Rocket Software

Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
John McKown 
Sent: Saturday, March 18, 2023 11:51:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: location of JCL for started task

EXTERNAL EMAIL




I don't know IOF. In SDSF, I can select the STC and FIND for EXPANDED FROM
to see where it came from.


On Saturday, March 18, 2023, Bill Giannelli  wrote:
> I see in the system log is was submitted from STCINRDR
>
>
> On Sat, 18 Mar 2023 13:02:55 -0500, Paul Gilmartin 
wrote:
>
>>On Sat, 18 Mar 2023 12:26:19 -0500, Bill Giannelli wrote:
>>
>>>we have a PDS for job cards for started tasks, which reference our
system proclib.
>>>I have a started task that is executing, yet I can not find the actual
JCL (Jobcard, etc). I can find the proc.
>>>How can I find where the JCL is being read from?
>>>
>>Might it have been started from a console?:
>><
https://www.ibm.com/docs/en/zos/2.5.0?topic=command-starting-system-task-from-console<https://www.ibm.com/docs/en/zos/2.5.0?topic=command-starting-system-task-from-console>
>
>>(or by automation), in which case there might be no such member; only the
command
>>shown in the system log.
>>
>>The audit trail can be hard to follow when someone submits from an editor
>>a job created ab ovo.
>>
>>--
>>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


Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Clarification of SDSF CSR

[Rob Scott]

The lengths are decimal.

If you are on z/OS 2.5 you can issue the JCS action against the row to drill 
down to the individual memory blocks.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  on behalf of 
esst...@juno.com 
Sent: Friday, March 17, 2023 4:22:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Clarification of SDSF CSR

EXTERNAL EMAIL





 Hello
.
I need some clarity on SDSF CSR display Common storage remaining Memory
When I use CSR function I see job CSVDJOB listed with
CSVDJOB ECSA   ECSA%
   12288  0.0170
.
Its not clear to me if ECSA is a decimal or hex value ?
.
2nd
I look at the JOB CSVDJOB: it has three steps and each step
invokes CSVDYLPA REQUEST=ADD,MEMBERLIST=. So the JOB dynamically
defines three modules in LPA.
.
.
If I look at the load library in TSO 3.4 Browse the three modules,
I have the following Lengths:
.
PGM1  X'000500' = 1,280.
PGM2  X'000810' = 2,064.
PGM3  X'000B48' = 2,888.

Total   X'1858' = 6,232.
.
.
 I was expecting the total length of 6,232 to equal the value listed
 in SDSF CSR of 12288.
.
 Does TSO 3.4 list the length of modules in Half Words ?
.
I would like to get a better understanding as to the dfferences
in the lengths.
.
.
 paul d

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



Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Virtual Storage Manager - LDA.

[Rob Scott]

If you are z/OS 2.5, you can use the "L" action on the "JM" (Job Memory) screen 
in SDSF (JM action available on DA, AS or AD panels).

This will show you each block if memory for a specific subpool+key combination 
in any address space (assuming you have SAF authority to the SDSF resource that 
protects it).

Under the covers, SDSF schedules an SRB into the ASID and that uses VSMLIST.

Also note that the SDSF "AS" panel contains bird's eye view of Private and 
EPrivate storage usage of all ASIDs thanks to the rather handy LDAX control 
block (many thanks to whoever implemented that at Poughkeepsie).

Rob Scott
Rocket Software.


From: IBM Mainframe Discussion List  on behalf of 
Peter Relson 
Sent: Saturday, 4 March 2023, 09:13
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Virtual Storage Manager - LDA.

EXTERNAL EMAIL





Updates to the LDA are done synchronously with respect to the request. Fields 
such as LDALOAL, LDAHIAL, LDAELOAL, LDAEHIAL might be of interest depending on 
what you're doing (subpool and whether the virtual is above or below 16M, in 
particular). I don't recall, but those might reflect allocation of anything 
within a given page rather than indicating the exact number of bytes allocated.

If you want details from a program, use VSMLIST. Or take a dump and look at one 
of the IPCS VSMDATA reports.
And GTF tracing of getmain/freemain/storage requests is available to you.

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




Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Big z/OS Preview Announcement

[Rob Scott]

A quick FYI, I will also be spending 10-15mins in my "SDSF Hidden Treasures"  
Share session previewing the big ticket items we have in 3.1.

There are some very interesting SDSF features on the way.

Rob Scott
Rocket Software



From: IBM Mainframe Discussion List  On Behalf Of 
Lionel B. Dyck
Sent: 28 February 2023 14:38
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Big z/OS Preview Announcement

EXTERNAL EMAIL



Saw this post from Marna this morning:

Big z/OS Preview Announce day for our next release! A million great things
in there, but a couple of items of note: - z14 is the minimum level. - GA
will be 3Q2023, as is expected. - IBM Change Tracker (the newest priced
feature) will have a self-service 90-day trial if you want to give it a test
drive, with APAR PH51954, and you'll be able to also use the new z/OSMF
plug-in for it. - Several ISPF items in this announcement for pervasive
encryption, PDSE V2 member generations, UNIX directory.

Make sure you attend SHARE in Atlanta to hear all the latest news about what
is coming in z/OS 3.1! #IBMz #IBMzOS
https://www.ibm.com/downloads/cas/CA-ENUSA23-0017-CA/name/CA-ENUSA23-0017-CA<https://www.ibm.com/downloads/cas/CA-ENUSA23-0017-CA/name/CA-ENUSA23-0017-CA>
.PDF


Lionel B. Dyck <><
Website: https://www.lbdsoftware.com<https://www.lbdsoftware.com>
Github: https://github.com/lbdyck<https://github.com/lbdyck>

"Worry more about your character than your reputation. Character is what you
are, reputation merely what others think you are."   - - - John Wooden

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


Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Cant SPKA to PSW Key 4

[Rob Scott]

Joseph

>> I have gotten to a point where in my code I have written a number of SRB’s 
>> and other types of code that run in Supervisor state and / or key 0

>>To protect my control blocks I wanted to put them in key 4 so that 
>>inadvertent access would get a s0c4 pic 4

My gut feeling here is you should concentrate on executing in Key4 and avoid 
running in Key0 as much as possible.

(Having your control blocks in key4 does not prevent accidental reference or  
overlay from key0 code unless you take other measures to protect the memory).

Normal methods of running in key4 (or maybe key2) would involve an entry in 
SCHEDxx for your server jobstep program which would in turn own PC routines 
with ETDEF entries for any client caller that would declare the execution key.

(I do have some sample code on GitHub that demonstrates this)

Execution key switch would be made by the PC instruction – there would be no 
need to issue SPKAs unless you called a system service  within the server (or 
PC routine)  that explicitly only supported key0 (and there are not too many of 
those).


>> I have Zpdt personal edition

If this was me, I would still start a dialog with Cole Software.

Rob Scott
Rocket Software


From: IBM Mainframe Discussion List  On Behalf Of 
Joseph Reichman
Sent: 27 February 2023 12:51
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cant SPKA to PSW Key 4

EXTERNAL EMAIL



Rob

I have Zpdt personal edition

I have gotten to a point where in my code I have written a number of SRB’s and 
other types of code that run in Supervisor state and / or key 0

To protect my control blocks I wanted to put them in key 4 so that inadvertent 
access would get a s0c4 pic 4

I am not rocket software and I don’t have what I think is the yearly fee of XDC 
which about $10,000 which is a lot of money for a working stiff like me

I just wonder if anyone who have the Zpdt personal edition is running XDC

As far as this latest hurdle

The only time test / TESTAUTH has a problem with my code is when I am at a 
breakpoint and am not in key 8 or 0

I am first begging to think that right before I enter SVC 97 I could change 
back to key 8 and when I resume go back to key 4

Haven’t thought this through as I just read your email and I’m and starting my 
day

Thanks for your help

If Dave come gives me a discounted price I would be willing to listen

> On Feb 27, 2023, at 5:56 AM, Seymour J Metz 
> mailto:sme...@gmu.edu>> wrote:
>
> To expand on that, never throw out debug scaffolding after you go 
> production; keep the test cases and AIF out anything that you want to disable 
> rather than deleting it.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3<http://mason.gmu.edu/~smetz3>
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Rob Scott [rsc...@rocketsoftware.com]
> Sent: Monday, February 27, 2023 5:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
> Subject: Re: Cant SPKA to PSW Key 4
>
> Joseph
>
> As others might have suggested, if you are even semi-serious about writing 
> authorized code then I think it would be worth your time talking to Cole 
> Software about getting z/XDC.
>
> Independently of that discussion, it might be a good idea to take stock of 
> your current software’s own trace abilities (and I mean something more than 
> just putting the odd WTO out).
>
> It would be a very good investment in your time to build a comprehensive 
> internal trace capability for your software, something that can support all 
> environments that it can be executed in.
>
> Even if you are writing authorized code for your own interest/hobby, then 
> believe me that solving this issue is extremely interesting (and rewarding).
>
> The return on investment for this is huge if your code ever reaches a 
> customer site and you are trying to resolve a problem.
>
> Rob Scott
> Rocket Software
>
> From: IBM Mainframe Discussion List 
> mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
> Joseph Reichman
> Sent: 26 February 2023 22:36
> To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
> Subject: Re: Cant SPKA to PSW Key 4
>
> EXTERNAL EMAIL
>
>
>
> Jim
>
> How about IDF or tool debug I have been trying to get IDF running so I can 
> debug code running in key 4 but if you say I’m wasting my time ?
>
>> On Feb 26, 2023, at 5:18 PM, Jim Mulder 
>> mailto:d10j...@us.ibm.com<mailto:d10j...@us.ibm.com%3cmailto:d10j...@us.ibm.com>>>
>>  wrote:
>>
>> They do not support whatever is in TCBPKF. I have seen code in TSO which has
>> hardcoded x'80'.
>>
>> Jim Mulder
>>
>> -Original Message-
>> From: IBM Mainfra

Re: Cant SPKA to PSW Key 4

[Rob Scott]

Joseph

As others might have suggested, if you are even semi-serious about writing 
authorized code then I think it would be worth your time talking to Cole 
Software about getting z/XDC.

Independently of that discussion, it might be a good idea to take stock of your 
current software’s own trace abilities  (and I mean something more than just 
putting the odd WTO out).

It would be a very good investment in your time to build a comprehensive 
internal trace capability for your software, something that can support all 
environments that it can be executed in.

Even if you are writing authorized code for your own interest/hobby, then 
believe me that solving this issue is extremely interesting (and rewarding).

The return on investment for this is huge if your code ever reaches a customer 
site and you are trying to resolve a problem.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Joseph Reichman
Sent: 26 February 2023 22:36
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cant SPKA to PSW Key 4

EXTERNAL EMAIL



Jim

How about IDF or tool debug I have been trying to get IDF running so I can 
debug code running in key 4 but if you say I’m wasting my time ?

> On Feb 26, 2023, at 5:18 PM, Jim Mulder 
> mailto:d10j...@us.ibm.com>> wrote:
>
>  They do not support whatever is in TCBPKF. I have seen code in TSO which has
> hardcoded x'80'.
>
> Jim Mulder
>
> -Original Message-
> From: IBM Mainframe Discussion List 
> mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Ed 
> Jaffe
> Sent: Saturday, February 25, 2023 9:50 PM
> To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
> Subject: Re: Cant SPKA to PSW Key 4
>
>> On 2/23/2023 6:46 PM, Joseph Reichman wrote:
>> I am trying to change psw storage key from "Normal" key 8 to Key 4
>>
>> SPKA X'40'
>>
>> I have bit 15 of the psw 0 ,meaning I am in supervisor state and get a
>> s0c1 running this code under TESTAUTH
>>
>> I am able to get to PSW key 0 SPKA 0
>>
>> Don't get it
>
> ISTR discovering empirically 30+ years ago that TSO/E TEST and TESTAUTH 
> support only two execution keys: X'80' and X'00'.
>
> I wondered if in-fact they actually support whatever key is in TCBPKF and 
> X'00' but never experimented to see if that was the case.
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://www.phoenixsoftware.com/<https://www.phoenixsoftware.com>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu<mailto: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<mailto:lists...@listserv.ua.edu> with 
the message: INFO IBM-MAIN


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: An SDSF curiosity...

[Rob Scott]

SMF 79 records are handed back to a ERBSMFI caller-supplied buffer in contrast 
to the traditional “push” of SMFWTM/SMFEWTM, so you will not find them in the 
normal SMF record MANx or offload datasets.

If you are using RMF, then 79-1 records will be returned even if RMF is not 
active (other subtypes require RMF STC and various ERBRMFxx keywords in PARMLIB)

Without calling ERBSMFI, you might get some value from looking at the OUCBTMO 
field for the ASID in question.

If you are running z/OS 2.5, you can use the SDSF “AD” panel and then 
point-and-shoot on the “OUCB” column for an address space to be taken into a 
memory browse session.
If you then type “M” against the first row on the MEM panel, SDSF will map the 
memory contents against the OUCB DSECT.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Sean Gleann
Sent: 21 February 2023 13:45
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: An SDSF curiosity...

EXTERNAL EMAIL



Thanks, Rob - it all makes sense now.
I tried to have a look at my type-79 data, only to find there isn't any
being collected. It seems I have to set up RMF monitor II to collect that.
Maybe I'll think about that later.
Migration to z/OS 2.5 is something planned for later this year.

Regards
Sean

On Tue, 21 Feb 2023 at 13:07, Rob Scott 
mailto:rsc...@rocketsoftware.com>> wrote:

> The SDSF "TranAct" column is based entirely on the R791TTOD field returned
> by ERBSMFI (which in turn is based on OUCBTMO).
>
> This 32-bit value contains the number of milliseconds since the "last
> transaction".
>
> The meaning of "last transaction" varies with the workload, so for some
> address spaces in might reflect the initial program execution and could be
> used to estimate its "up-time".
>
> For TSO users, the "last transaction" will be updated each time ENTER is
> pressed and it is entirely possible that other workloads , for example z/OS
> Unix, have methods to inform WLM to update OUCBTMO.
>
> Note that R791TMO can only hold x'', so for systems that have not
> been IPLed for many months this figure is either going to wrap or stay
> static (I am not sure which happens).
>
> (For what it is worth, when SDSF detects that a job has been active for
> more than x'' milliseconds, then we show zeroes for the TRANACT and
> TRANRES columns)
>
> Note that SDSF "DA" now has the "Start Date" column in z/OS 2.5 to aid
> users trying to work out the up-time of the ASIDs.
>
> Rob Scott
> Rocket Software
>
> -Original Message-
> From: IBM Mainframe Discussion List 
> mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf
> Of Sean Gleann
> Sent: 21 February 2023 10:01
> To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
> Subject: An SDSF curiosity...
>
> EXTERNAL EMAIL
>
>
>
>
>
> This isn't a 'problem' per se, just an observation that someone else may
> be able to shed some light on...
>
> In SDSF, the DA panel presentation can be modified using the 'View' option.
> For my logon id I have brought the column named 'Tran-Act' in to view, and
> then sorted the display so that Tran-Act is in ascending sequence.
>
> An excerpt for a current display is: (hoping this doesn't get
> reformatted...)
> NP JOBNAME StepName ProcStep JobID Tran-Act CPU% CPU-Time
> BUILD5 *OMVSEX STC24665 0:00:00 0.34 0.01
> BUILD2 STEP1 STC23744 0:00:14 22.72 9.53
> OMVS OMVS OMVS 5:35:02 0.21 1228.64
> BUILD9 *OMVSEX STC23888 14:07:22 2.50 1458.22
> SSHD6 STEP1 STC23925 14:07:22 0.00 3.49
> IMS14J11 IMS14J11 JMPRGN JOB23674 34:44:13 0.00 0.44
> IMS14F11 IMS14F11 IFP JOB23671 34:44:21 0.00 0.01
>
> At the bottom of this excerpt, there are two tasks associated with an IMS
> region that was started shortly after the system was IPL'd, nearly 35
> hours ago. In the full display, there are a number of other tasks below
> this that all have Tran-Act times that are roughly the same.
>
> Above the IMS-related tasks, there are two tasks that have been running
> for a bit over 14 hours.
>
> The OMVS task above that has apparently been running for only five and
> half hours or so, and that is the curiosity...
>
> OMVS is started at IPL time, just like the IMS region in the example
> above, and it is never terminated until we shut the system down again. (in
> the shutdown sequence, it is the last thing to be terminated before JES can
> be stopped).
>
> So why isn't OMVS's "Tran-Act" time in the same ball park as the IMS tasks?
>
> Regards
> Sean
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu<mailto:lists...@

Re: An SDSF curiosity...

[Rob Scott]

The SDSF "TranAct" column is based entirely on the R791TTOD field returned by 
ERBSMFI (which in turn is based on OUCBTMO).

This 32-bit value contains the number of milliseconds since the "last 
transaction".

The meaning of "last transaction" varies with the workload, so for some address 
spaces in might reflect the initial program execution and could be used to 
estimate its "up-time".

For TSO users, the "last transaction" will be updated each time ENTER is 
pressed and it is entirely possible that other workloads , for example z/OS 
Unix, have methods to inform WLM to update OUCBTMO.

Note that R791TMO can only hold x'', so for systems that have not been 
IPLed for many months this figure is either going to wrap or stay static  (I am 
not sure which happens).

(For what it is worth, when SDSF detects that a job has been active for more 
than x'' milliseconds, then we show zeroes for the TRANACT and TRANRES 
columns)

Note that SDSF "DA" now has the "Start Date" column in z/OS 2.5 to aid users 
trying to work out the up-time of the ASIDs.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Sean Gleann
Sent: 21 February 2023 10:01
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: An SDSF curiosity...

EXTERNAL EMAIL





This isn't a 'problem' per se, just an observation that someone else may be 
able to shed some light on...

In SDSF, the DA panel presentation can be modified using the 'View' option.
For my logon id I have brought the column named 'Tran-Act' in to view, and then 
sorted the display so that Tran-Act is in ascending sequence.

An excerpt for a current display is: (hoping this doesn't get
reformatted...)
 NP   JOBNAME  StepName ProcStep JobID  Tran-Act   CPU%   CPU-Time
  BUILD5   *OMVSEX   STC246650:00:00   0.34   0.01
  BUILD2   STEP1 STC237440:00:14  22.72   9.53
  OMVS OMVS OMVS 5:35:02   0.211228.64
  BUILD9   *OMVSEX   STC23888   14:07:22   2.501458.22
  SSHD6STEP1 STC23925   14:07:22   0.00   3.49
  IMS14J11 IMS14J11 JMPRGN   JOB23674   34:44:13   0.00   0.44
  IMS14F11 IMS14F11 IFP  JOB23671   34:44:21   0.00   0.01

At the bottom of this excerpt, there are two tasks associated with an IMS 
region that was started shortly after the system was  IPL'd, nearly 35 hours 
ago. In the full display, there are a number of other tasks below this that all 
have Tran-Act times that are roughly the same.

Above the IMS-related tasks, there are two tasks that have been running for a 
bit over 14 hours.

The OMVS task above that has apparently been running for only five and half 
hours or so, and that is the curiosity...

OMVS is started at IPL time, just like the IMS region in the example above, and 
it is never terminated until we shut the system down again. (in the shutdown 
sequence, it is the last thing to be terminated before JES can be stopped).

So why isn't OMVS's "Tran-Act" time in the same ball park as the IMS tasks?

Regards
Sean

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

[Rob Scott]

Tom

Our current product trajectory is to compliment both Omegamon and RMF rather 
than attempt to replace either.

I see SDSF as a system information toolkit rather than a performance monitor. 
SDSF does not have the richness of data that Omegamon captures and does not 
really step into the threshold, alerting,  and performance history detail that 
is the core value of a MVS monitor.

Inspiration for new functionality comes from talking to users and sysprogs 
online, at conferences, and within our own company.

I spent 20 years as a MVS sysprog and no small part of what I do now is 
attempting to deliver something that my 30yo self would think was cool.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  on behalf of Tom 
Brennan 
Sent: Saturday, February 18, 2023 4:35:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

EXTERNAL EMAIL





I like what it's become of course, but I sometimes wonder why.  Are they
trying to be something like Omegamon?

On 2/18/2023 7:54 AM, Jay Maynard wrote:
> Am I the only one who remembers the original Sysout Display and Search
> Facility FDP and marvels at what SDSF has become?
>
> --
> 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



Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

[Rob Scott]

There is a recent APAR (OH49573) that addresses an issue with SDSF being 
started before CMF and it should mean that you should not have to restart 
SDSF/SDSFAUX in order for subsequent availability to be recognised.

RMF returns 79-1 records even when its address space is down, so the SDSF DA 
panel should be fully populated. Other SDSF panels that rely on RMF like DEV 
and PAG however do require RMF availability.

Note that should you need to restart SDSF data collection, you can do so 
without stopping the main SDSF server by using "F SDSF,P AUX" followed by "F 
SDSF,S AUX". There is normally no requirement to stop the SDSF main server 
after IPL.


Rob Scott
Rocket Software


From: IBM Mainframe Discussion List  on behalf of 
Mark Zelden 
Sent: Friday, 17 February 2023, 22:44
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

EXTERNAL EMAIL




Sorry I am late to the game with this one. First time I've had a breather to 
look
at IBM-MAIN all of February.

I suggest stopping / starting SDSF (which will stop/start SDSFAUX also) and 
that may
resolve the problem. I ran into similar issues with both RMF and CMF when 
working
on z/OS 2.5. The best indicator of this problem is to do "DA OJOB" and if you 
see
STCs, then recycling SDSF will resolve it. If you have to recycle CMF or RMF for
any reason, you'll likely run into the same thing again and have to recycle SDSF
also.

Change your automation to not start SDSF until after CMF tasks or RMF is started
at IPL time. Making CMF/RMF a pre-req of SDSF should also remind someone
to recycle SDSF even if CMF/RMF is "forced" recycled without SDSF.

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: 
http://www.mzelden.com/mvsutil.html<http://www.mzelden.com/mvsutil.html>

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



Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Sv: CLIST for APF and link list datasets

[Rob Scott]

Bill

My recommendation is to use SDSF or ISRDDN for this functionality as they are 
supported products.

MXI 4.3 has not been maintained for nearly 20 years. It is unsupported and to 
be brutally honest showing its age a bit.

(The fact that MXI 4.3 is still functional at all is a testament to IBM's z/OS 
backward-compatibility focus) .

Most of the z/OS information that MXI 4.3 shows is now part of SDSF and this 
has a roadmap to further enhance its sysprog-focused displays.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Giannelli
Sent: 15 February 2023 15:53
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sv: CLIST for APF and link list datasets

EXTERNAL EMAIL





IT's MXI!
thank you
I couldnt remember..

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Question on use of LPARNAME, SYSNAME and SMFID

[Rob Scott]

Matt

Of course the big difference is that SMFID is 4 characters and SYSNAME is 8 

I know that software vendors often run QA on systems where all three (incl 
LPARNAME) are deliberately different to catch any assumptions made in code or 
product sample JCL.

I have seen customers using different values for SMFID and when queried I am 
normally told that it relates to historical chargeback and accounting (and very 
possible that the reasons for it are forgotten/lost).

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Matt Hogstrom
Sent: 10 February 2023 16:16
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Question on use of LPARNAME, SYSNAME and SMFID

EXTERNAL EMAIL





I’m doing some research involving historical SMF data.  It’s caused me to 
wonder how engineers use the ,  and  symbols.  From what 
I can see is that in most instances they are the same.  LPARNAME appears to me 
to have little value in that if may or may not have an affinity for a z/OS 
guest in terms of naming.

 and  seem to generally correlate.  I’m curious if there are use 
cases where these are different and what the purpose might be?

Appreciate any insight  / best parties that people are using.

Matt Hogstrom
m...@hogstrom.org

A generalist knows less and less about more and more till he knows nothing 
about everything A specialist knows more and more about less and less till he 
knows everything about nothing


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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Goodbye and thanks for all the fish

[Rob Scott]

Rebecca

I interacted with Bob many times over the years in IBM-Main and via e-mail and 
he was a true gentleman.

He will be greatly missed.

Rob Scott
Rocket Software


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Rebecca Richards
Sent: 08 February 2023 23:52
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Goodbye and thanks for all the fish

EXTERNAL EMAIL





Hi All,
This is Rebecca Richards. My husband Robert Richards has been an member of this 
list for many years.I just wanted let you know he died of bladder cancer this 
past Friday. I wanted to let everyone know Rebecca Richards


Sent from Yahoo Mail for iPad


On Wednesday, February 8, 2023, 3:17 PM, Wayne Bickerdike  
wrote:

I retired in 2021 but I still maintain an interest here. Good for the brain 
cells.

Managed to lose 3Kgs and reduce my blood pressure :)

On Thu, Feb 9, 2023 at 2:11 AM Steve Thompson  wrote:

> Sorry to see you go. And I too am not a very active member. I read a
> lot and learn stuff.
>
> Hope you enjoy your retirement. Or, un-retirement if that is what you
> wish.
>
> Regards,
> Steve Thompson
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


--
Wayne V. Bickerdike

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




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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: RACF - SDSF question

[Rob Scott]

Bob makes some very good points here, however a small addition :

“The suggestions to lock down MVS cancel job commands won't help in this 
situation because SDSF is issuing JES2 commands instead of MVS commands, so the 
OPERCMDS MVS.CANCEL.JOB.jobname resources won't be checked.”

This is true for the action character in question, however be aware that SDSF 
also has actions like “K” from DA that generate MVS CANCEL commands rather than 
JES2.

Rob Scott
Rocket Software


From: IBM Mainframe Discussion List  On Behalf Of 
Robert S. Hansel (RSH)
Sent: 08 February 2023 13:00
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



Hi Terri,

Here are a couple of thoughts to add to what others have mentioned.

Since SDSF is issuing a JES2 cancel job $CJ command, the name of the OPERCMDS 
resource being checked is JES2.CANCEL.BAT. Profile JES2.CANCEL.BAT.C30TCI* is 
superfluous since the resource name never includes the jobname, so you can 
delete it. Profile JES2.CANCEL.BAT.** is guarding JES2.CANCEL.BAT because the 
.** generic suffix applies to zero or more qualifiers, and in this case it is 
zero qualifiers. The suggestions to lock down MVS cancel job commands won't 
help in this situation because SDSF is issuing JES2 commands instead of MVS 
commands, so the OPERCMDS MVS.CANCEL.JOB.jobname resources won't be checked.

As was mentioned, to cancel a job typically also requires ALTER access to the 
JESSPOOL resource guarding the job. Look into setting up appropriate JESSPOOL 
profiles to isolate and restrict ALTER access to these jobs. Also consider 
whether users have been (inadvertently) set up as Destination Operators. If 
they have READ access to SDSF resource ISFOPER.DEST.JES2 and ALTER access to 
SDSF resources prefixed ISFAUTH.DEST., they can cancel jobs while bypassing 
JESSPOOL profile checks.

If the CONSOLE class is active, you can permit ID(*) UPDATE access to 
JES2.CANCEL.BAT.** conditionally by adding operand WHEN(CONSOLE(SDSF)) to the 
PERMIT command so that users can only issue JES2 cancel job commands from 
within SDSF panels. This would prevent them from cancelling jobs outside of 
SDSF, to include when using the SDSF / command. You would need to remove 
UACC(UPDATE) or ID(*) UPDATE permission, whichever applies, for the conditional 
permission to take effect. Operations and Tech Support staff will need 
'regular' UPDATE access permission. (CONSOLE is a Default Return Code 8 class, 
so don't activate it without first creating a ** profile with UACC(READ).)

To see exactly what resource names are being checked that are allowing the 
unwanted job cancellations, issue the SDSF command SET SECTRACE ON, cancel the 
job, and then issue the SDSF command ULOG. ULOG will show you all the access 
checks SDSF is making along with the results of each of these checks. SECTRACE 
is a phenomenal diagnostic tool that we use often.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc. *** Celebrating our 30th Anniversary ***
617-969-8211
www.linkedin.com/in/roberthansel<http://www.linkedin.com/in/roberthansel>
www.rshconsulting.com<http://www.rshconsulting.com>

-Original Message-
Date: Tue, 7 Feb 2023 13:31:41 +
From: "Shaffer, Terri" 
mailto:terri.shaf...@aciworldwide.com>>
Subject: RACF - SDSF question

Hi,
I know there is a RACF group, but hopefully this is simple and I am just 
missing something I have done 100 times over with no issues.

We run our CICS regions as batch jobs, and I just found out a user instead of 
them issuing a CEMT PERF SHUT command, they are canceling it.

Which then causing a 100 vsam messages on startup with all the verifies, and if 
something goes wrong they call me...

So I tried to stop this habit, I know they are putting a C beside the CICS and 
a $CJ(x) command

So I have 2 rules in RACF under OPERCMDS

JES2.CANCEL.BAT.C30TCI* (G)
JES2.CANCEL.BAT.** (G)

If I restrict the BAT.** then they cant cancel even their own batch jobs, So I 
always thought more specific is looked at first?

One of my previous co-workers implemented SDSF-RACF rules converted from 
ISFPARMS.

Lastly, I understand this doesn’t stop them from canceling any other jobs, but 
since this is a development shop we allow more access than most.

But I don’t want users canceling a CICS or DB2 etc.

Any ideas how they are getting the access and not stopped with the more 
specific rule??


Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham 

Re: RACF - SDSF question

[Rob Scott]

Note that there is no jobname qualifier on the JES2.CANCEL.BAT profile. This is 
why SDSF has the extra JESSPOOL profile check that goes beyond vanilla JES2 
cancel command security.

This extra check is ONLY performed inside SDSF and is made before we build the 
operator command text.

Coincidentally I gave a presentation at virtual GSE today entitled "SDSF 
Security - How does it work under z/OS 2.5?" and the sequence of SAF checks is 
described with a few examples.

If you want, I can forward you the slide deck.

Rob Scott
Rocket Software

Sent from Samsung Mobile on O2
Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
Shaffer, Terri <017d5f778222-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, February 7, 2023 6:10:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL




Okay, so not sure I reall understand the way this works?

Under jesspool, checks nodeid.userid.jobname.jobid, so I could add my cics 
jobname like C30TCI* here? Is this the SDSF command like C, P etc?

Or under OPERCMDS I have

JES2.CANCEL.BAT.C30TCI* (G)
JES2.CANCEL.BAT.** (G)

And now.

MVS.CANCEL.BAT.C30TCI*.* (G)
MVS.CANCEL.** (G)

Where does the granularity take place, for certain jobs??

I want the users to be able to cancel some batch jobs and everything they 
submitted, but not CICS, DB2 or other system things.

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Scott
Sent: Tuesday, February 7, 2023 9:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Note that one of the "value add" functions of SDSF is that it can check for 
ALTER access to the JESSPOOL profile for the owner and jobname for destructive 
actions like "C" and "P".

Does not stop them using freeform "slash" to issue the raw operator command, 
but removes the convenience of the action character.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Roger W Suhr
Sent: 07 February 2023 14:22
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



Hi Ms. Terri,

The OPERCMDS JES2.CANCEL.** profiles protect the JES2 ($C...) cancel command.
I believe you also need to use the OPERCMDS MVS.CANCEL.STC.mbrname.id profile 
to protect the MVS CANCEL command.

So in your case, that would be something like this: (if your running CICS as an 
STC!)
MVS.CANCEL.STC.C30TCI* (G)
MVS.CANCEL.STC.** (G)


Roger W. Suhr

suhr...@gmail.com<mailto:suhr...@gmail.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Tuesday, February 7, 2023 8:32
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: RACF - SDSF question

Hi,
I know there is a RACF group, but hopefully this is simple and I am just 
missing something I have done 100 times over with no issues.

We run our CICS regions as batch jobs, and I just found out a user instead of 
them issuing a CEMT PERF SHUT command, they are canceling it.

Which then causing a 100 vsam messages on startup with all the verifies, and if 
something goes wrong they call me...

So I tried to stop this habit, I know they are putting a C beside the CICS and 
a $CJ(x) command

So I have 2 rules in RACF under OPERCMDS

JES2.CANCEL.BAT.C30TCI* (G)
JES2.CANCEL.BAT.** (G)

If I restrict the BAT.** then they cant cancel even their own batch jobs, So I 
always thought more specific is looked at first?

One of my previous co-workers implemented SDSF-RACF rules converted from 
ISFPARMS.

Lastly, I understand this doesn't stop them from canceling any other jobs, but 
since this is a development shop we allow more access than most.

But I don't want users canceling a CICS or DB2 etc.

Any ideas how they are getting the access and not stopped with the more 
specific rule??


Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>


[https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg<https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg><https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg<https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg>>]
 
<http://www.aciworldwide.com<http://www.aciworldwide.com><http://www.aciworldwide.com<http://www.aciworldwide.com>>>
 This email message and any attachments may contain confidential, proprietary 
or non-public informat

Re: RACF - SDSF question

[Rob Scott]

Note that one of the “value add” functions of SDSF is that it can check for 
ALTER access to the JESSPOOL profile for the owner and jobname for destructive 
actions like “C” and “P”.

Does not stop them using freeform “slash” to issue the raw operator command, 
but removes the convenience of the action character.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Roger W Suhr
Sent: 07 February 2023 14:22
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



Hi Ms. Terri,

The OPERCMDS JES2.CANCEL.** profiles protect the JES2 ($C...) cancel command.
I believe you also need to use the OPERCMDS MVS.CANCEL.STC.mbrname.id profile 
to protect the MVS CANCEL command.

So in your case, that would be something like this: (if your running CICS as an 
STC!)
MVS.CANCEL.STC.C30TCI* (G)
MVS.CANCEL.STC.** (G)


Roger W. Suhr

suhr...@gmail.com<mailto:suhr...@gmail.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Tuesday, February 7, 2023 8:32
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: RACF - SDSF question

Hi,
I know there is a RACF group, but hopefully this is simple and I am just 
missing something I have done 100 times over with no issues.

We run our CICS regions as batch jobs, and I just found out a user instead of 
them issuing a CEMT PERF SHUT command, they are canceling it.

Which then causing a 100 vsam messages on startup with all the verifies, and if 
something goes wrong they call me...

So I tried to stop this habit, I know they are putting a C beside the CICS and 
a $CJ(x) command

So I have 2 rules in RACF under OPERCMDS

JES2.CANCEL.BAT.C30TCI* (G)
JES2.CANCEL.BAT.** (G)

If I restrict the BAT.** then they cant cancel even their own batch jobs, So I 
always thought more specific is looked at first?

One of my previous co-workers implemented SDSF-RACF rules converted from 
ISFPARMS.

Lastly, I understand this doesn’t stop them from canceling any other jobs, but 
since this is a development shop we allow more access than most.

But I don’t want users canceling a CICS or DB2 etc.

Any ideas how they are getting the access and not stopped with the more 
specific rule??


Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>


[https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg<https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg>]
 <http://www.aciworldwide.com<http://www.aciworldwide.com>> This email message 
and any attachments may contain confidential, proprietary or non-public 
information. The information is intended solely for the designated 
recipient(s). If an addressing or transmission error has misdirected this 
email, please notify the sender immediately and destroy this email. Any review, 
dissemination, use or reliance upon this information by unintended recipients 
is prohibited. Any opinions expressed in this email are those of the author 
personally.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu<mailto: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<mailto:lists...@listserv.ua.edu> with 
the message: INFO IBM-MAIN


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

[Rob Scott]

Please check the DADFLT() keyword on the SDSF GROUP statement. This dictates 
the default address space types returned when the user omits any parameters on 
the DA command.

If the SDSF group omits the DADFLT keyword, it defaults to NONE. I believe 
there are historical reasons for this  behaviour.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  on behalf of 
Michael Babcock 
Sent: Monday, February 6, 2023 6:05:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

EXTERNAL EMAIL




Rob. We applied all available SDSF maintenance to our 2.5 system.
We’ve found that DA ALL works. Has something changed with respect to the
DA command/panel not defaulting to ALL?


On Fri, Feb 3, 2023 at 2:55 AM Rob Scott  wrote:

> Ross,
>
> First of all, I am glad you have opened a support case for this, our
> support team should be able to gather further diagnostic information to
> resolve the problem.
>
> A bit of background information for the archives :
>
> (o) In z/OS 2.4+, the SDSF "DA" information is gathered centrally by a
> subtask in the SDSFAUX address space.
> (o) This subtask uses the RMF programming service ERBSMFI (GRBSMFI) to
> collect this information and any ISV product that replaces RMF supplies an
> alias for this module.
> (o) The SDSFAUX address space dumps the first 256 bytes of the ERBSMFI
> load module in the HSFTRACE DD that is allocated to the SDSF started task
> (o) When the RMF address space is not active, ERBSMFI still returns the
> data we require (SMF 79-1 records), however in our experience other ISV
> products do not return data when their STC is inactive and instead pass
> back a non-zero return code. As a customer for an ISV that replaces RMF,
> you might want to consider raising an RFE with them to address this.
> (o) When we get a non-zero return code from ERBSMFI for 79-1 data, we
> fallback to our own internal data collector (HSFSMFI) that builds pseudo
> 79-1 records that reflect the columns that SDSF used to display prior to
> using ERBSMFI (many years ago). The SDSF client code will detect this
> condition and the number of columns shown on the DA panel will be greatly
> reduced from "full-RMF" function.
> (o) Error conditions calling ERBSMFI are normally reflected either by
> WTO-style messages and/or messages written to the HSFLOG DD that is
> allocated to the SDSF started task.
> (o) Other SDSF panels that depend on ERBSMFI include DEV and PAG, however
> they do not have internal fallback capability.
>
> Rob Scott
> Rocket Software
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Ross Vaughn
> Sent: 03 February 2023 04:07
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Missing Values For The 'SDSF DA' Panels - z/OS 2.5
>
> EXTERNAL EMAIL
>
>
>
>
>
> We are currently in the process of rolling out z/OS 2.5 and have hit an
> issue on a test LPAR that is not displaying any information in the SDSF DA
> panels.
> There are no messages in the syslog out of the IPL that would lead us in a
> certain direction. We think we may have an issue with CMF but can’t
> confirm. We are occasionally seeing error messages out of SDSFAUX as well.
>
> It looks like beginning with z/OS 2.4 the ’SDSF DA’ information is
> obtained by the SDSFAUX address space calling the BMC AMI Ops Monitor for
> CMF. We have verified we have the CX10GVID module in our linklist library
> that CMF uses to obtain the SDSF DA values.
> We have a ticket open with support as well, but curious if anyone has seen
> similar issues when rolling out z/OS 2.5? Same LPAR on z/OS 2.4 does not
> have the same issue.
>
> Thanks,
> Ross
>
>
>
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> 
> Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA
> 02451
> <https://www.google.com/maps/search/77+Fourth+Avenue,+Waltham+MA+02451?entry=gmail=g<https://www.google.com/maps/search/77+Fourth+Avenue,+Waltham+MA+02451?entry=gmail=g>>
> ■ Main Office Toll Free Number: +1 855.577.4323
> Contact Customer Support:
> https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport<https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport>
> Unsubscribe from Marketing Messages/Manage Your Subscription Preferences -
> http://www.rocketsoftware.com/manage-your-email-preferences<http://www.rocketsoftware.com/manage-your-email-preferences>
> Privacy Policy -
> http://www.rocketsoftware.com/company/legal/priva

Re: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

[Rob Scott]

Ross,

First of all, I am glad you have opened a support case for this, our support 
team should be able to gather further diagnostic information to resolve the 
problem.

A bit of background information for the archives :

(o) In z/OS 2.4+, the SDSF "DA" information is gathered centrally by a subtask 
in the SDSFAUX address space.
(o) This subtask uses the RMF programming service ERBSMFI (GRBSMFI) to collect 
this information and any ISV product that replaces RMF supplies an alias for 
this module.
(o) The SDSFAUX address space dumps the first 256 bytes of the ERBSMFI load 
module in the HSFTRACE DD that is allocated to the SDSF started task
(o) When the RMF address space is not active, ERBSMFI still returns the data we 
require (SMF 79-1 records), however in our experience other ISV products do not 
return data when their STC is inactive and instead pass back a non-zero return 
code. As a customer for an ISV that replaces RMF, you might want to consider 
raising an RFE with them to address this.
(o) When we get a non-zero return code from ERBSMFI for 79-1 data, we fallback 
to our own internal data collector (HSFSMFI) that builds pseudo 79-1 records 
that reflect the columns that SDSF used to display prior to using ERBSMFI (many 
years ago). The SDSF client code will detect this condition and the number of 
columns shown on the DA panel will be greatly reduced from "full-RMF" function.
(o) Error conditions calling ERBSMFI are normally reflected either by WTO-style 
messages and/or messages written to the HSFLOG DD that is allocated to the SDSF 
started task.
(o) Other SDSF panels that depend on ERBSMFI include DEV and PAG, however they 
do not have internal fallback capability.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Ross Vaughn
Sent: 03 February 2023 04:07
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

EXTERNAL EMAIL





We are currently in the process of rolling out z/OS 2.5 and have hit an issue 
on a test LPAR that is not displaying any information in the SDSF DA panels.
There are no messages in the syslog out of the IPL that would lead us in a 
certain direction.  We think we may have an issue with CMF but can’t confirm.  
We are occasionally seeing error messages out of SDSFAUX as well.

It looks like beginning with z/OS 2.4 the ’SDSF DA’ information is obtained by 
the SDSFAUX address space calling the BMC AMI Ops Monitor for CMF.  We have 
verified we have the CX10GVID module in our linklist library that CMF uses to 
obtain the SDSF DA values.
We have a ticket open with support as well, but curious if anyone has seen 
similar issues when rolling out z/OS 2.5?   Same LPAR on z/OS 2.4 does not have 
the same issue.

Thanks,
Ross







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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: JES2 z22 model privileged resources

[Rob Scott]

I can replicate this on my 2.4 system, whereas my 2.5 system in the same MAS 
reports this correctly.

Tracing the data returned from JES2 on 2.4, I can see that the values for 
LMDUPMAX and LMDUPUSE are the same (these are the fields that SDSF uses to 
populate those column values).

I suggest you open a PMR/Case with JES2 support as this appears to be an issue 
with the JES SSI request SSJILMOD.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
rpinion865
Sent: 09 November 2022 21:20
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JES2 z22 model privileged resources

EXTERNAL EMAIL



For z/OS 2.4, according to the SDSF JRI display, I see the following.

PREFIX=* DEST=(ALL) OWNER=* SYSNAME=

NP NAME NPrivMax NPrivUse NPrivUse% NPrivExhaust NPrivWarn% PrivSup ResPrivSup 
PrivMax PrivUse PrivUse%

BERT 20095 459 2 NO 80 ON ON 405 405 100

JOE 25257 1126 4 NO 80 ON ON 243 243 100

JQE 20308 1287 6 NO 80 ON ON 192 192 100

Spool 199932 7759 4 NO 80 ON ON 400 400 100

Which I interpret as saying the reserved resources are at 100%. Yet, the JES2 
command $DLIMITS displays the following.

Am I reading the SDSF JRI panel incorrectly?

-$DLIMITS

$HASP1490 LIMITS(1)

LIMITS(1)

PRIVILEGE SUPPORT IS ON

SPOOL PRIVILEGE SUPPORT IS ON

SPOOL UTILIZATION ON 9 NOV 2022 AT 15:06:44

-- NON-PRIVILEGED ---|--- PRIVILEGED

--

MAXIMUM WARN% IN-USE %| MAX AVAILABLE

199,932 80 7,758 4| 400 400

SPOOL EXHAUST: 12 MAY 2023 AT 22:17



$HASP1490 LIMITS(2)

LIMITS(2)

PRIVILEGE SUPPORT IS ON

JQE PRIVILEGE SUPPORT IS ON

JQE UTILIZATION ON 9 NOV 2022 AT 15:06:44

-- NON-PRIVILEGED ---|--- PRIVILEGED

--

MAXIMUM WARN% IN-USE %| MAX AVAILABLE

20,308 80 1,286 6| 192 192

JQE EXHAUST: 15 FEB 2023 AT 17:17



$HASP1490 LIMITS(3)

LIMITS(3)

PRIVILEGE SUPPORT IS ON

JOE PRIVILEGE SUPPORT IS ON

JOE UTILIZATION ON 9 NOV 2022 AT 15:06:44

-- NON-PRIVILEGED ---|--- PRIVILEGED

--

MAXIMUM WARN% IN-USE %| MAX AVAILABLE

25,257 80 1,126 4| 243 243

JOE EXHAUST: 20 FEB 2023 AT 01:13



$HASP1490 LIMITS(4)

LIMITS(4)

PRIVILEGE SUPPORT IS ON

BERT PRIVILEGE SUPPORT IS ON

BERT UTILIZATION ON 9 NOV 2022 AT 15:06:44

-- NON-PRIVILEGED --|--- PRIVILEGED

MAXIMUM WARN% IN-USE %| MAX AVAILABLE

20,095 80 458 2| 405 405

BERT EXHAUST: 21 SEP 2024 AT 16:16



Sent with [Proton Mail](https://proton.me/<https://proton.me>) secure email.

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Dynamic LPA Services

[Rob Scott]

Paul,

I very much doubt that the csvdylpa workarea is in common storage. It is much 
more likely to be in an authorised private subpool.

You can check by inspecting the output subpool value returned by the service.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  on behalf of 
esst...@juno.com 
Sent: Monday, October 31, 2022 5:06:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Dynamic LPA Services

EXTERNAL EMAIL





Hello
.
Regarding CSVDYLPA REQUEST=ADD
.
The documentation states:
.Modules added to the system via dynamic LPA processing are placed into CSA or 
ECSA storage.
.
Further more It is expected that the caller will free the work area, using 
either FREEMAIN or STORAGE RELEASE, after processing it.
.
Does this mean the work area used by CSVDYLPA is also acquired from CSA/ECSA 
storage since the caller is responsible for freeing the storage
occupied by the "work area" ?
.
Paul -

.

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



Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: 64 BIT ULUT list information missing

[Rob Scott]

Joseph,

A couple of points :

(1) The ULUT is not an intended interface. I suggest you use UCBSCAN instead.

(2) IIRC to get a list of shared and common memory objects, you have to invoke 
IARV64 twice, once with V64SHARED=NO and V64COMMON=YES followed by another with 
the parameters reversed.

Rob Scott

Principal Architect, Mainframe Systems Tools

Distinguished Engineer
Rocket Software
77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
Tel: +1.781.684.2305
Email: rsc...@rs.com<mailto:rsc...@rs.com>
Web: www.rocketsoftware.com<http://www.rocketsoftware.com/>


From: IBM Mainframe Discussion List  on behalf of 
Joseph Reichman 
Sent: Friday, October 28, 2022 9:47:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: 64 BIT ULUT list information missing

EXTERNAL EMAIL





The 64 bit ULUT address on my system is 1F0



I was looking for information on it returned by IARV64 REQUEST=LIST





I would assume its in common or shared and coded this macro to get more 
information



 IARV64 REQUEST=LIST,  X

V64LISTPTR=WRKPTR,  X

V64LISTLENGTH=F108, X

V64SHARED=YES,  X

V64COMMON=YES,  X

TRACKINFO=YES,  X

V64SELECT=NO,   X

RETCODE=RETURNC,X

RSNCODE=REASONC,X

PLISTVER=MAX,MF=(E,IARV64SRB,COMPLETE)

 *



The address returned started at 200 and increased on each call till I 
got a return code zero



It my understanding the way I coded the macro it would return both share and 
common for all address spaces



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



Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: possible RFE for V64WAENTRY

[Rob Scott]

Joseph

My advice would be to go ahead and raise the RFE as there seems to be nothing 
unreasonable in the request.

It's chances of being addressed will increase if you can get Share/GSE to vote 
for it as well.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Joseph Reichman
Sent: 24 October 2022 14:32
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: possible RFE for V64WAENTRY

EXTERNAL EMAIL





The  V64WAENTRY contains two flags and starting and ending address



Its 31 bit counterpart VSMLIST contains a lot more info though I know that 
there is no subpool about the bar would it be possible to add a TCB field to 
this layout



If Peter Relson reads this wonder if he would comment if this has a  chance for 
a RFE



thanks




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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: ICHEINTY, R_admin and RACROUTE EXTRACT

[Rob Scott]

All

The IBM RACF development team have just made the RACSEQ sample program for 
RAdmin/IRRSEQ00 available on GitHub.

Here is the link :

https://github.com/IBM/IBM-Z-zOS/tree/main/zOS-RACF/Downloads

Many thanks to Bruce Wells for making this happen.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pierre Fichaud
Sent: 11 October 2022 17:52
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ICHEINTY, R_admin and RACROUTE EXTRACT

EXTERNAL EMAIL





On Mon, 10 Oct 2022 at 14:06, Pierre Fichaud  wrote:

> To All,
> I want replace userid passwords in the RACF database.
> I have encrypted password in a flat file.
>

Where did you get such an encrypted password?
--> The password was encrypted using a CSNB*** call.


> I labored to get ICHEINTY working but finally did.
>
> R_admin was much easier than ICHEINTY.
>

Not surprisingly. ICHEINTY is a pretty low-level interface. R_Admin is similar 
to issuing an ALU command.


> For both ICHEINTY and R-admin, I get return and reason codes set to 0.
>
> But the password does not get changed.
>

Does not get changed (i.e. you can still logon with the old password), or isn't 
what you expect after your code runs?

--> Does not get changed.


> My SYSPROG temporarily made my userid RACF special and still
> neither worked.
> I don't know why.
> My load library is APF-authorized.
> I was in supervisor state for R_admin.
>

You wouldn't get RC=0 if you weren't suitably authorized. I don't believe 
SPECIAL makes a difference for this kind of thing.


> I turned to RACROUTE REQUEST=VERIFY,TYPE=REPLACE.
>

Do you mean REQUEST=EXTRACT,TYPE=REPLACE or REQUEST=VERIFY with NEWPASS= ?.

--> EXTRACT with REPLACE

The former is about the closest thing to ICHEINTY for this purpose, but 
generally easier to use.

The latter is essentially a user logon-with-password-change, so you have to 
supply the current password.

After fixing one thing, it ran cleanly and it worked..
> I was able to login into TSO with the new password.
>

Again, this is fine if you have an encrypted password to bang in there. But the 
use cases for this are on the rare side.

You may want to think about what you expect to happen to the user's password 
history when you do this.


> Is there something I missed with ICHEINTY and R_admin ?
>

Presumably. I do know that I have used ICHEINTY to replace passwords and 
phrases, and it works fine for me.


> Thanks to those who responded before, especially Peter Relson.
>
Regards, Pierre
>

 Tony H.

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: R_admin

[Rob Scott]

I can recommend the sample "RACSEQ" source that IBM provide on their FTP site 
for your initial foray into using R_admin

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pierre Fichaud
Sent: 07 October 2022 14:31
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: R_admin

EXTERNAL EMAIL





I am attempting to use R_admin instead of ICHEINTY to update the RACF database.
The mapping macro IRRPCOMP has the layout for R_admin (IRRSEQ00).
But what values do I put for ADMN_USRADM_FLAGS, ADMN_USRADM_SEG_FLAG and 
ADMN_USRADM_FLD_FLAG ?
I am getting SAF rc=8, RACF rc=8 and RACF rsn=16 (x'1`0').
I suspect that the flags need setting.

Thanks, Pierre.

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: ICHEINTY - RACF interface

[Rob Scott]

I am curious as to why you want to use ICHEINTY rather than one of the 
distinctly better documented (and easier to code) callable services like rAdmin 
?

Is there some functionality missing between the two?

Sent from Samsung Mobile on O2
Get Outlook for Android

From: IBM Mainframe Discussion List  on behalf of 
Pierre Fichaud 
Sent: Wednesday, October 5, 2022 7:55:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: ICHEINTY - RACF interface

EXTERNAL EMAIL





I have an update.
After an hour or so of juggling the various parameters for ICHEINTY, I got this 
:

20.26.08 JOB04490 *IRR401I 0C4 ABEND DURING RACF PROCESSING OF  236
   236   ALTER REQUEST FOR ENTRY T22TST1
20.26.08 JOB04490  IRR401I 0C4 ABEND DURING RACF PROCESSING

 I couldn't get the macro to work with DATAMAP=NEW and RELEASE 1.8.
 I let it default to 1.7 and played with the parameters.

Now I have an abend but I got no SYSMDUMP nor a SYSUDUMP.

My next step is to set a SLIP trap but I'm waiting to be APF-authorized to 
do this.

1) Why is it a guessing game as to which parameters apply ?

2) The examples are always coded in non-rent assembler programs.
 I code exclusively re-entrant, AMODE 31 and RMODE ANY.
 I rarely see IBM examples where the code is re-entrant.
 And I never see the flavor that I am using, in this case ICHEINTY 
ALTER, TYPE='USR'.
 Couldn't IBM use examples that work in 31-bit and are re-entrant ?

3) There is probably something in the generated parameter list that is 
wrong or missing.
 Unfortunately, there is no mapping for the ICHEINTY parameter list.
 Can IBM supply a mapping if it exists.
 The doc refers to fields at various offsets.
 I have no idea what to do to fix this problem.
 It's a guessing game - back to #1.
Regards, Pierre.

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



Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

SDSF Presentations now available on IBM Git Hub

[Rob Scott]

Just a quick FYI, we have now published past SDSF presentations from GSE and 
Share conferences on the IBM Git Hub.

Link for git hub : https://github.com/IBM/IBM-Z-zOS

The presentations can be found in the "zOS-Education" folder.

For the 2.5 release we have :

(o) SDSF Security - How does it work on z/OS 2.5?
(o) Learn to use SDSF Rexx
(o) More ways to manage your z/OS With SDSF for z/OS 2.5


Rob Scott
Rocket Software




Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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