Re: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

2023-02-18 Thread Seymour J Metz 
No. And I once saw Werner Buchholz (z"l) posting on this list; I'd be surprised 
if anybody here goes further back than him.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jay 
Maynard [jaymayn...@gmail.com]
Sent: Saturday, February 18, 2023 10:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

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

Re: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

2023-02-18 Thread rpinion865 
I remember, and remember using the output TSO command to sysout.

Sent from Proton Mail mobile

 Original Message 
On Feb 18, 2023, 10: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

Re: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

2023-02-18 Thread Tom Brennan 
And just to be clear, I wasn't complaining.  This stuff is super helpful 
and I think it started in SDSF long before Rocket got hold of it.


Another one (again no complaints) is the PDS command which has various 
functions unrelated to a PDS.  It's like the most popular programs have 
expanded to include utilities that in the past might have to be 
installed separately.


On 2/18/2023 10:01 AM, Rob Scott wrote:

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




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

2023-02-18 Thread 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

2023-02-18 Thread Tom Brennan 
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

Re: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

2023-02-18 Thread Mike Shaw 
I meant Brian Westerman...sorry.

Mike

On Sat, Feb 18, 2023, 11:25 AM Mike Shaw  wrote:

> Everyone,:
>
> Brian Western, who is active on this forum, did some of the coding on SDSF
> in its infancy when he was still a teenager.  He has a good story to tell
> about it if you can get it out of him.
>
> Mike Shaw
> MVS/ QuickRef Support
> Chicago-Soft, Ltd
>
> On Sat, Feb 18, 2023, 10: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

Re: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

2023-02-18 Thread Mike Shaw 
Everyone,:

Brian Western, who is active on this forum, did some of the coding on SDSF
in its infancy when he was still a teenager.  He has a good story to tell
about it if you can get it out of him.

Mike Shaw
MVS/ QuickRef Support
Chicago-Soft, Ltd

On Sat, Feb 18, 2023, 10: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

Re: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

2023-02-18 Thread Jay Maynard 
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

Re: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

2023-02-18 Thread 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: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

2023-02-17 Thread Mark Zelden 
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

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

2023-02-06 Thread Michael Babcock 
Rob, we didn’t have DADFLT coded for our group in ISFPRMxx member.   It
still worked under 2.4 so that hole must have been closed with 2.5.

Oddly enough, our test LPAR for the SYSPROG group was the only group DADFLT
wasn’t coded on.   It was coded on all other groups and all other LPARs.

Thanks!

On Mon, Feb 6, 2023 at 12:50 PM Rob Scott  wrote:

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

Re: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

2023-02-06 Thread 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

2023-02-06 Thread Michael Babcock 
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
> 
> ■ 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
>
-- 
Michael Babcock
OneMain Financial
z/OS Systems Programmer, Lead

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

2023-02-03 Thread Ross Vaughn 
Hi Rob,

I opened a case with IBM but they are referring me to Rocket support for SDSF.  
So we will open a case there Rocket as well.
We did not include any of the SYS1.SGRB* datasets into our LPA, APF, LINKLIST 
etc. because we didn't think we needed the z/OS Data Gatherer piece and we're 
not licensed for the advanced piece of it. 
Tried adding the SYS1.SERBLNKE to our APF & LNKLST but no change.   We run CMF 
only.   No RMF in our shop.
Thanks,
Ross Vaughn


> On Feb 3, 2023, at 2:54 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 ■ 
> 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


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

2023-02-03 Thread John Wallin 
Can you confirm that SYS1.SERBLNKE and SYS1.SGRBLINK come after BMCLINK and 
BMCLNKE (assuming you have RMF)?
The IBM data sets are new in z/OS V2R5, replacing SYS1.SERBLINK, when RMF was 
split into RMF Reporter and z/OS Data Gatherer.

Regards,
John

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

2023-02-03 Thread Shelia Chalk 
We use cmf instead of rmf. I had the same problem on lpar was on z/os 2.5 and 
the lpar was on z/os 2.3. We open a ticket with the great BMC and they couldn't 
figure it out for months.  So, we cross our fingers and converted the other 
lpar to z/os 2.5 and CMF started working correctly.  

Thanks
Shelia Chalk

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Scott
Sent: Friday, February 3, 2023 2:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.rocketsoftware.com%2FRocketCommunity%2FRCEmailSupport=05%7C01%7CSChalk%40TRUSTMARK.COM%7C9fee4e95286b4ba37e7008db05c451a1%7C518d66eacb8948c8a7b903cba11cde91%7C1%7C0%7C638110112997402092%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=TaEPQe3ZKhwjoNfVdW3afGVdIQxf9uG2JXFsZyPjWfQ%3D=0
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fmanage-your-email-preferences=05%7C01%7CSChalk%40TRUSTMARK.COM%7C9fee4e95286b4ba37e7008db05c451a1%7C518d66eacb8948c8a7b903cba11cde91%7C1%7C0%7C638110112997402092%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=v2tFNx8MDTuKpwGkg9f5HsA17edn9fAnu%2F5L5y0V2Js%3D=0
Privacy Policy - 
https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policy=05%7C01%7CSChalk%40TRUSTMARK.COM%7C9fee4e95286b4ba37e7008db05c451a1%7C518d66eacb8948c8a7b903cba11cde91%7C1%7C0%7C638110112997558301%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL

Re: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

2023-02-03 Thread 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: Missing Values For The 'SDSF DA' Panels - z/OS 2.5

2023-02-02 Thread Gibney, Dave 
1st guess would be that the named BMC module isn't 2.5 ready and shouldn't be 
located where SDSF  can try to use it.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Ross Vaughn
> Sent: Thursday, February 02, 2023 8:07 PM
> 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

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