Re: SDSF NO DATA IN DATA SETS while on the same system
On 11/3/2020 10:05 AM, Paul Gilmartin wrote: One is based on JQE; the other on JQE (IIRC). -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDSF NO DATA IN DATA SETS while on the same system
Here is an example. Here are a series of WTO messages I write out in one of my address spaces. Same system: *13.00.49 JOB39680 +PRT405I Program manager is deleting program PORTSO04.* *13.00.49 JOB39680 +PRT406I Program load request for PORTSO04. * *13.00.49 JOB39680 +PRT404I Program manager is loading program CEEEV004.* *13.00.49 JOB39680 +PRT404I Program manager is loading program PORTSO04.* *13.00.49 JOB39680 +ASCII TRANSLATION * *13.00.49 JOB39680 +PRT406I Program load request for PORTAPI. * *13.00.49 JOB39680 +PRT405I Program manager is deleting program PORTSO04.* *13.00.49 JOB39680 +PRT406I Program load request for PORTSO04. * *13.00.49 JOB39680 +PRT404I Program manager is loading program PORTAPI. * *13.00.49 JOB39680 +PRT406I Program load request for PORTAP01. * *13.00.49 JOB39680 +PRT404I Program manager is loading program PORTSO04.* *13.00.49 JOB39680 +ASCII TRANSLATION * *13.00.49 JOB39680 +PRT404I Program manager is loading program PORTAP01.* *13.00.49 JOB39680 +PRT405I Program manager is deleting program PORTSO04.* *13.00.49 JOB39680 +PRT406I Program load request for PORTSO04. * *13.00.49 JOB39680 +PRT405I Program manager is deleting program PORTAP01.* *13.00.49 JOB39680 +PRT406I Program load request for PORTSO04. * *13.00.49 JOB39680 +PRT404I Program manager is loading program PORTSO04.* *13.00.49 JOB39680 +ASCII TRANSLATION * *13.00.49 JOB39680 +PRT404I Program manager is loading program PORTSO04.* *13.00.49 JOB39680 +PRT405I Program manager is deleting program PORTSO04.* *13.00.49 JOB39680 +PRT406I Program load request for PORTSO04. * * BOTTOM OF DATA ** Different system: *13.00.49 JOB39680 +PRT404I Program manager is loading program PORTSO04.* *13.00.49 JOB39680 +ASCII TRANSLATION * *13.00.49 JOB39680 +PRT406I Program load request for PORTAPI. * *13.00.49 JOB39680 +PRT405I Program manager is deleting program PORTSO04.* *13.00.49 JOB39680 +PRT406I Program load request for PORTSO04. * *13.00.49 JOB39680 +PRT404I Program manager is loading program PORTAPI. * *13.00.49 JOB39680 +PRT406I Program load request for PORTAP01. * *13.00.49 JOB39680 +PRT404I Program manager is loading program PORTSO04.* *13.00.49 JOB39680 +ASCII TRANSLATION * *13.00.49 JOB39680 +PRT404I Program manager is loading program PORTAP01.* *13.00.49 JOB39680 +PRT405I Program manager is deleting program PORTSO04.* *13.00.49 JOB39680 +PRT406I Program load request for PORTSO04. * *13.00.49 JOB39680 +PRT405I Program manager is deleting program PORTAP01.* *13.00.49 JOB39680 +PRT406I Program load request for PORTSO04. * *13.00.49 JOB39680 +PRT404I Program manager is loading program PORTSO04.* *13.00.49 JOB39680 +ASCII TRANSLATION * *13.00.49 JOB39680 +PRT404I Program manager is loading program PORTSO04. * *13.00.49 JOB39680 +PRT405I Program manager is deleting program PORTSO04. * *13.00.49 JOB39680 +PRT406I Program load request for PORTSO04.* *13.00.49 JOB39680 +PRT404I Program manager is loading program PORTSO04. * *13.00.49 JOB39680 +ASCII TRANSLATION * *13.00.49 JOB39680 +PRT405I Program manager is deleting program PORTSO04. * *13.00.49 JOB39680 +PRT405I Program manager is deleting program IGZXLPKA. * *13.00.49 JOB39680 +PRT405I Program manager is deleting program IGZXLPKD. * *13.00.49 JOB39680 +PRT405I Program manager is deleting program IGZXLPKF. * *13.00.49 JOB39680 +PRT405I Program manager is deleting program CEEEV004. * *13.00.49 JOB39680 +CHECKING SOCKET STATUS* *13.00.49 JOB39680 +REPLYING TO SOCKET* *13.00.49 JOB39680 +PRT406I Program load request for PORTSO05.* *13.00.49 JOB39680 +PRT404I Program manager is loading program PORTSO05. * *13.00.49 JOB39680 +EBCDIC TRANSLATION* *13.00.49 JOB39680 +PRT407I Program delete request for PORTSO05. * *13.00.49 JOB39680 +PRT405I Program manager is deleting program PORTSO05. * *13.00.49 JOB39680 +PRT406I Program load request for PORTSO02.* *13.00.49 JOB39680 +PRT404I Program manager is loading program PORTSO02. * *13.00.49 JOB39680 +PRT407I Program delete request for PORTSO02. * *13.00.49 JOB39680 +PRT405I Program manager is deleting program PORTSO02. *
Re: SDSF NO DATA IN DATA SETS while on the same system
On Tue, 3 Nov 2020 17:54:22 +, Seymour J Metz wrote:
>SDSF used to behave differently depending on what command you used to get to
>the dataset.
>
Ah, yes. I once noticed a disagreement between "DA" and "?". Went to SR; was
told, "Of course." One is based on JQE; the other on JQE (IIRC). I assessed
that
as WAD and gave up.
>
>From: Paul Gilmartin
>Sent: Tuesday, November 3, 2020 11:29 AM
>>
>It has been my experience that instream ("SYSIN"; input) data sets
>appear empty in SDSF until a job step actually opens or reads them.
>
>I don't know whether this is WAD.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDSF NO DATA IN DATA SETS while on the same system
SDSF used to behave differently depending on what command you used to get to
the dataset.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Tuesday, November 3, 2020 11:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF NO DATA IN DATA SETS while on the same system
On Tue, 3 Nov 2020 09:33:04 -0600, Carmen Vitullo wrote:
>
>Brian try using the SDSF primary command 'INPUT ON' first some address spaces
>will show records, but will not display for some reason.
>
It has been my experience that instream ("SYSIN"; input) data sets
appear empty in SDSF until a job step actually opens or reads them.
I don't know whether this is WAD.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDSF NO DATA IN DATA SETS while on the same system
On Tue, 3 Nov 2020 09:33:04 -0600, Carmen Vitullo wrote:
>
>Brian try using the SDSF primary command 'INPUT ON' first some address spaces
>will show records, but will not display for some reason.
>
It has been my experience that instream ("SYSIN"; input) data sets
appear empty in SDSF until a job step actually opens or reads them.
I don't know whether this is WAD.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDSF NO DATA IN DATA SETS while on the same system
On Tue, 3 Nov 2020 10:27:48 -0500, Brian Chapman wrote: >Carmen, > >There's definitely data on the DD, but for some reason I just can't see it >when on the same system. The data will be old (sometimes more than a day) > > > >Thank you, > >Brian Chapman > > >On Tue, Nov 3, 2020 at 10:23 AM Carmen Vitullo wrote: > >> On Tue, 3 Nov 2020 08:56:24 -0500, Brian Chapman >> wrote: >> >> >I have experienced this issue for years at my site, and I've had no luck >> >finding the solution. >> > >> >If I view a DD of an address space that is running on the same system that >> >I am logged into, then I will occasionally receive the 'NO DATA in DATA >> >SETS' message in SDSF when I select the output (it can be different DD's). >> >I also have similar behaviour when viewing WTO messages in the JESMSGLG. >> >I'm unable to see the most recent WTO's, but I can see older ones. If I >> log >> >onto a different system within the same Sysplex, then I can view all of >> the >> >output without issue. >> > >> >I assume this has something to do with viewing the SDSF buffers and some >> >setting that is ignoring the most recent buffer. Any help would be greatly >> >appreciated. >> > >> > >> > >> >Thank you, >> > >> >Brian Chapman >> > >> >-- >> >For IBM-MAIN subscribe / signoff / archive access instructions, >> >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> Brian I see that a lot with address spaces that have not written any data >> to a DD, for example, my TCPIP address space lists 8 DD's >> ALGPRINT DD for example - other DD's show zero for the record count but >> there's data to view. >> are you expecting data to be written? has it maybe been spun? >> Carmen >> >> -- >> 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 Brian try using the SDSF primary command 'INPUT ON' first some address spaces will show records, but will not display for some reason. Carmen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDSF NO DATA IN DATA SETS while on the same system
Carmen, There's definitely data on the DD, but for some reason I just can't see it when on the same system. The data will be old (sometimes more than a day) Thank you, Brian Chapman On Tue, Nov 3, 2020 at 10:23 AM Carmen Vitullo wrote: > On Tue, 3 Nov 2020 08:56:24 -0500, Brian Chapman > wrote: > > >I have experienced this issue for years at my site, and I've had no luck > >finding the solution. > > > >If I view a DD of an address space that is running on the same system that > >I am logged into, then I will occasionally receive the 'NO DATA in DATA > >SETS' message in SDSF when I select the output (it can be different DD's). > >I also have similar behaviour when viewing WTO messages in the JESMSGLG. > >I'm unable to see the most recent WTO's, but I can see older ones. If I > log > >onto a different system within the same Sysplex, then I can view all of > the > >output without issue. > > > >I assume this has something to do with viewing the SDSF buffers and some > >setting that is ignoring the most recent buffer. Any help would be greatly > >appreciated. > > > > > > > >Thank you, > > > >Brian Chapman > > > >-- > >For IBM-MAIN subscribe / signoff / archive access instructions, > >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > Brian I see that a lot with address spaces that have not written any data > to a DD, for example, my TCPIP address space lists 8 DD's > ALGPRINT DD for example - other DD's show zero for the record count but > there's data to view. > are you expecting data to be written? has it maybe been spun? > Carmen > > -- > 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: SDSF NO DATA IN DATA SETS while on the same system
On Tue, 3 Nov 2020 08:56:24 -0500, Brian Chapman wrote: >I have experienced this issue for years at my site, and I've had no luck >finding the solution. > >If I view a DD of an address space that is running on the same system that >I am logged into, then I will occasionally receive the 'NO DATA in DATA >SETS' message in SDSF when I select the output (it can be different DD's). >I also have similar behaviour when viewing WTO messages in the JESMSGLG. >I'm unable to see the most recent WTO's, but I can see older ones. If I log >onto a different system within the same Sysplex, then I can view all of the >output without issue. > >I assume this has something to do with viewing the SDSF buffers and some >setting that is ignoring the most recent buffer. Any help would be greatly >appreciated. > > > >Thank you, > >Brian Chapman > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Brian I see that a lot with address spaces that have not written any data to a DD, for example, my TCPIP address space lists 8 DD's ALGPRINT DD for example - other DD's show zero for the record count but there's data to view. are you expecting data to be written? has it maybe been spun? Carmen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
