Re: SDSF & REXX & ULOG problem
Try using PGM=SDSF or Address SDSF "ISFSLASH ("command.") (WAIT)"
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Sean Gleann
Sent: Thursday, May 30, 2019 4:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF & REXX & ULOG problem
I've been struggling with this one for a couple of days now, without making
any headway.
I have a REXX that works through SDSF that is intended to issue 'D R,L'
and retrieve any outstanding console messages. It works fine when I invoke
it from ISPF option 6 with an EXEC... command, but when I invoke it via a
batch job or a started task it doesn't return the expected results.
After a considerable amount of manual bashing and web browsing, I've found
a couple of threads describing a similar problem on various web fora, the
most notable one having been raised back in 2011, and responded to by a
number of the regular contributors here on IBM-MAIN.
Unfortunately, I can't make the suggested modifications do anything for me,
and I'm hoping that someone here might be able to point me in a different
direction.
My REXX is:
/* REXX */
rc=isfcalls('ON')
rc=syscalls('ON')
isfcons="NODDY"
Address SDSF ISFEXEC "'/D R,L' (wait"
say "isfulog.0: "isfulog.0
if isfulog.0>0 then do
do i=1 to isfulog.0
say i isfulog.i
end
end
rc=isfcalls('OFF')
rc=syscalls('OFF')
When I run this via EXEC... in option 6, the result is:
isfulog.0: 6
1 S0W1 2019150 03:02:03.62 ISF031I CONSOLE NODDY ACTIVATED
2 S0W1 2019150 03:02:03.62-D R,L
3 S0W1 2019150 03:02:03.62 IEE112I 03.02.03 PENDING
REQUESTS 774
4RM=1IM=0 CEM=0
EM=0 RU=0IR=0NOAMRF
5ID:R/K T SYSNAME MESSAGE
TEXT
638 R S0W1 *38
DFS996I *IMS READY* IVP1
… which is exactly as expected.
If I use a console START command to invoke the REXX via some started task
JCL...
//RUNEXEC EXEC PGM=IKJEFT01,PARM='%'
//SYSEXEC DD DSN=REXXLIB.SYSEXEC,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
...the SYSTSPRT output on the hold queue is;
IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED
isfulog.0: 0
READY
END
As can be seen, the isfulog stem has simply gone west.
The same occurs if I modify the JCL to turn it into a batch job and invoke
the REXX that way instead.
I've tried a large number of variants of the REXX logic to trace it's
progress, and in the hope of forcing something different to happen, all to
no avail.
Any ideas, anyone... please?
Regards
Sean
--
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 & REXX & ULOG problem
For what it's worth, an earlier modification of the REXX featured the use
of the WHO command to retrieve that sort of information.
The user is STCOPER, which doesn't have a TSO segment, it's true, even
though - per Itschak - one isn't necessary.
As part of pursuing this problem, I PERMITted both CONSOLE and SPECIAL
attributes for this user, as well as READ access to all resources inn the
SDSF class.
(have since backed those changes out, because they didn't move things
forward at all).
Regards
John
On Thu, 30 May 2019 at 13:48, ITschak Mugzach wrote:
> Msg IKJ56644I is always issued. Tso batch does not requires tao segment.
> However, as John noticed this is not the same user. Has a look at the first
> message of the stc job log to see which user associated with your task and
> make sure it has permission to command ulog in sdsf resource class.
>
> ITschak
>
> בתאריך יום ה׳, 30 במאי 2019, 15:33, מאת John McKown <
> john.archie.mck...@gmail.com>:
>
> > This is probably your problem:
> >
> > KJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED
> >
> > What RACF ID is the job running under? It must have a TSO segment and be
> > authorized to use SDSF.
> >
> > On Thu, May 30, 2019 at 3:14 AM Sean Gleann
> wrote:
> >
> > > I've been struggling with this one for a couple of days now, without
> > making
> > > any headway.
> > >
> > > I have a REXX that works through SDSF that is intended to issue 'D R,L'
> > > and retrieve any outstanding console messages. It works fine when I
> > invoke
> > > it from ISPF option 6 with an EXEC... command, but when I invoke it
> via a
> > > batch job or a started task it doesn't return the expected results.
> > >
> > > After a considerable amount of manual bashing and web browsing, I've
> > found
> > > a couple of threads describing a similar problem on various web fora,
> the
> > > most notable one having been raised back in 2011, and responded to by a
> > > number of the regular contributors here on IBM-MAIN.
> > >
> > > Unfortunately, I can't make the suggested modifications do anything for
> > me,
> > > and I'm hoping that someone here might be able to point me in a
> different
> > > direction.
> > >
> > > My REXX is:
> > > /* REXX */
> > > rc=isfcalls('ON')
> > > rc=syscalls('ON')
> > > isfcons="NODDY"
> > > Address SDSF ISFEXEC "'/D R,L' (wait"
> > > say "isfulog.0: "isfulog.0
> > > if isfulog.0>0 then do
> > > do i=1 to isfulog.0
> > > say i isfulog.i
> > > end
> > > end
> > > rc=isfcalls('OFF')
> > > rc=syscalls('OFF')
> > >
> > > When I run this via EXEC... in option 6, the result is:
> > > isfulog.0: 6
> > > 1 S0W1 2019150 03:02:03.62 ISF031I CONSOLE NODDY
> > > ACTIVATED
> > > 2 S0W1 2019150 03:02:03.62-D R,L
> > > 3 S0W1 2019150 03:02:03.62 IEE112I 03.02.03 PENDING
> > > REQUESTS 774
> > > 4RM=1IM=0 CEM=0
> > > EM=0 RU=0IR=0NOAMRF
> > > 5ID:R/K T SYSNAME
> > MESSAGE
> > > TEXT
> > > 638 R S0W1 *38
> > > DFS996I *IMS READY* IVP1
> > > … which is exactly as expected.
> > >
> > > If I use a console START command to invoke the REXX via some started
> task
> > > JCL...
> > > //RUNEXEC EXEC PGM=IKJEFT01,PARM='%'
> > > //SYSEXEC DD DSN=REXXLIB.SYSEXEC,DISP=SHR
> > > //SYSTSPRT DD SYSOUT=*
> > > //SYSTSIN DD DUMMY
> > >
> > > ...the SYSTSPRT output on the hold queue is;
> > > IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED
> > > isfulog.0: 0
> > > READY
> > > END
> > >
> > > As can be seen, the isfulog stem has simply gone west.
> > > The same occurs if I modify the JCL to turn it into a batch job and
> > invoke
> > > the REXX that way instead.
> > > I've tried a large number of variants of the REXX logic to trace it's
> > > progress, and in the hope of forcing something different to happen, all
> > to
> > > no avail.
> > >
> > > Any ideas, anyone... please?
> > >
> > > Regards
> > > Sean
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> >
> >
> > --
> > This is clearly another case of too many mad scientists, and not enough
> > hunchbacks.
> >
> >
> > Maranatha! <><
> > John McKown
> >
> > --
> > 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 acce
Re: SDSF & REXX & ULOG problem
On Thu, May 30, 2019 at 7:48 AM ITschak Mugzach wrote: > Msg IKJ56644I is always issued. Tso batch does not requires tao segment. > However, as John noticed this is not the same user. Has a look at the first > message of the stc job log to see which user associated with your task and > make sure it has permission to command ulog in sdsf resource class. > Hum, must be some difference between our systems. I submitted a TSO batch job from ISPF and did not see that message anywhere in my output. > ITschak > > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDSF & REXX & ULOG problem
Msg IKJ56644I is always issued. Tso batch does not requires tao segment.
However, as John noticed this is not the same user. Has a look at the first
message of the stc job log to see which user associated with your task and
make sure it has permission to command ulog in sdsf resource class.
ITschak
בתאריך יום ה׳, 30 במאי 2019, 15:33, מאת John McKown <
john.archie.mck...@gmail.com>:
> This is probably your problem:
>
> KJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED
>
> What RACF ID is the job running under? It must have a TSO segment and be
> authorized to use SDSF.
>
> On Thu, May 30, 2019 at 3:14 AM Sean Gleann wrote:
>
> > I've been struggling with this one for a couple of days now, without
> making
> > any headway.
> >
> > I have a REXX that works through SDSF that is intended to issue 'D R,L'
> > and retrieve any outstanding console messages. It works fine when I
> invoke
> > it from ISPF option 6 with an EXEC... command, but when I invoke it via a
> > batch job or a started task it doesn't return the expected results.
> >
> > After a considerable amount of manual bashing and web browsing, I've
> found
> > a couple of threads describing a similar problem on various web fora, the
> > most notable one having been raised back in 2011, and responded to by a
> > number of the regular contributors here on IBM-MAIN.
> >
> > Unfortunately, I can't make the suggested modifications do anything for
> me,
> > and I'm hoping that someone here might be able to point me in a different
> > direction.
> >
> > My REXX is:
> > /* REXX */
> > rc=isfcalls('ON')
> > rc=syscalls('ON')
> > isfcons="NODDY"
> > Address SDSF ISFEXEC "'/D R,L' (wait"
> > say "isfulog.0: "isfulog.0
> > if isfulog.0>0 then do
> > do i=1 to isfulog.0
> > say i isfulog.i
> > end
> > end
> > rc=isfcalls('OFF')
> > rc=syscalls('OFF')
> >
> > When I run this via EXEC... in option 6, the result is:
> > isfulog.0: 6
> > 1 S0W1 2019150 03:02:03.62 ISF031I CONSOLE NODDY
> > ACTIVATED
> > 2 S0W1 2019150 03:02:03.62-D R,L
> > 3 S0W1 2019150 03:02:03.62 IEE112I 03.02.03 PENDING
> > REQUESTS 774
> > 4RM=1IM=0 CEM=0
> > EM=0 RU=0IR=0NOAMRF
> > 5ID:R/K T SYSNAME
> MESSAGE
> > TEXT
> > 638 R S0W1 *38
> > DFS996I *IMS READY* IVP1
> > … which is exactly as expected.
> >
> > If I use a console START command to invoke the REXX via some started task
> > JCL...
> > //RUNEXEC EXEC PGM=IKJEFT01,PARM='%'
> > //SYSEXEC DD DSN=REXXLIB.SYSEXEC,DISP=SHR
> > //SYSTSPRT DD SYSOUT=*
> > //SYSTSIN DD DUMMY
> >
> > ...the SYSTSPRT output on the hold queue is;
> > IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED
> > isfulog.0: 0
> > READY
> > END
> >
> > As can be seen, the isfulog stem has simply gone west.
> > The same occurs if I modify the JCL to turn it into a batch job and
> invoke
> > the REXX that way instead.
> > I've tried a large number of variants of the REXX logic to trace it's
> > progress, and in the hope of forcing something different to happen, all
> to
> > no avail.
> >
> > Any ideas, anyone... please?
> >
> > Regards
> > Sean
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
> --
> This is clearly another case of too many mad scientists, and not enough
> hunchbacks.
>
>
> Maranatha! <><
> John McKown
>
> --
> 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 & REXX & ULOG problem
This is probably your problem:
KJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED
What RACF ID is the job running under? It must have a TSO segment and be
authorized to use SDSF.
On Thu, May 30, 2019 at 3:14 AM Sean Gleann wrote:
> I've been struggling with this one for a couple of days now, without making
> any headway.
>
> I have a REXX that works through SDSF that is intended to issue 'D R,L'
> and retrieve any outstanding console messages. It works fine when I invoke
> it from ISPF option 6 with an EXEC... command, but when I invoke it via a
> batch job or a started task it doesn't return the expected results.
>
> After a considerable amount of manual bashing and web browsing, I've found
> a couple of threads describing a similar problem on various web fora, the
> most notable one having been raised back in 2011, and responded to by a
> number of the regular contributors here on IBM-MAIN.
>
> Unfortunately, I can't make the suggested modifications do anything for me,
> and I'm hoping that someone here might be able to point me in a different
> direction.
>
> My REXX is:
> /* REXX */
> rc=isfcalls('ON')
> rc=syscalls('ON')
> isfcons="NODDY"
> Address SDSF ISFEXEC "'/D R,L' (wait"
> say "isfulog.0: "isfulog.0
> if isfulog.0>0 then do
> do i=1 to isfulog.0
> say i isfulog.i
> end
> end
> rc=isfcalls('OFF')
> rc=syscalls('OFF')
>
> When I run this via EXEC... in option 6, the result is:
> isfulog.0: 6
> 1 S0W1 2019150 03:02:03.62 ISF031I CONSOLE NODDY
> ACTIVATED
> 2 S0W1 2019150 03:02:03.62-D R,L
> 3 S0W1 2019150 03:02:03.62 IEE112I 03.02.03 PENDING
> REQUESTS 774
> 4RM=1IM=0 CEM=0
> EM=0 RU=0IR=0NOAMRF
> 5ID:R/K T SYSNAME MESSAGE
> TEXT
> 638 R S0W1 *38
> DFS996I *IMS READY* IVP1
> … which is exactly as expected.
>
> If I use a console START command to invoke the REXX via some started task
> JCL...
> //RUNEXEC EXEC PGM=IKJEFT01,PARM='%'
> //SYSEXEC DD DSN=REXXLIB.SYSEXEC,DISP=SHR
> //SYSTSPRT DD SYSOUT=*
> //SYSTSIN DD DUMMY
>
> ...the SYSTSPRT output on the hold queue is;
> IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED
> isfulog.0: 0
> READY
> END
>
> As can be seen, the isfulog stem has simply gone west.
> The same occurs if I modify the JCL to turn it into a batch job and invoke
> the REXX that way instead.
> I've tried a large number of variants of the REXX logic to trace it's
> progress, and in the hope of forcing something different to happen, all to
> no avail.
>
> Any ideas, anyone... please?
>
> Regards
> Sean
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
This is clearly another case of too many mad scientists, and not enough
hunchbacks.
Maranatha! <><
John McKown
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SDSF & REXX & ULOG problem
Please ignore my previous post. I've manged to create a solution via a different method. Using ADDRESS SDSF "ISFLOG READ TYPE(SYSLOG) (WTOR)" gives me what I need to progress this work. Regards Sean -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SDSF & REXX & ULOG problem
I've been struggling with this one for a couple of days now, without making
any headway.
I have a REXX that works through SDSF that is intended to issue 'D R,L'
and retrieve any outstanding console messages. It works fine when I invoke
it from ISPF option 6 with an EXEC... command, but when I invoke it via a
batch job or a started task it doesn't return the expected results.
After a considerable amount of manual bashing and web browsing, I've found
a couple of threads describing a similar problem on various web fora, the
most notable one having been raised back in 2011, and responded to by a
number of the regular contributors here on IBM-MAIN.
Unfortunately, I can't make the suggested modifications do anything for me,
and I'm hoping that someone here might be able to point me in a different
direction.
My REXX is:
/* REXX */
rc=isfcalls('ON')
rc=syscalls('ON')
isfcons="NODDY"
Address SDSF ISFEXEC "'/D R,L' (wait"
say "isfulog.0: "isfulog.0
if isfulog.0>0 then do
do i=1 to isfulog.0
say i isfulog.i
end
end
rc=isfcalls('OFF')
rc=syscalls('OFF')
When I run this via EXEC... in option 6, the result is:
isfulog.0: 6
1 S0W1 2019150 03:02:03.62 ISF031I CONSOLE NODDY ACTIVATED
2 S0W1 2019150 03:02:03.62-D R,L
3 S0W1 2019150 03:02:03.62 IEE112I 03.02.03 PENDING
REQUESTS 774
4RM=1IM=0 CEM=0
EM=0 RU=0IR=0NOAMRF
5ID:R/K T SYSNAME MESSAGE
TEXT
638 R S0W1 *38
DFS996I *IMS READY* IVP1
… which is exactly as expected.
If I use a console START command to invoke the REXX via some started task
JCL...
//RUNEXEC EXEC PGM=IKJEFT01,PARM='%'
//SYSEXEC DD DSN=REXXLIB.SYSEXEC,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
...the SYSTSPRT output on the hold queue is;
IKJ56644I NO VALID TSO USERID, DEFAULT USER ATTRIBUTES USED
isfulog.0: 0
READY
END
As can be seen, the isfulog stem has simply gone west.
The same occurs if I modify the JCL to turn it into a batch job and invoke
the REXX that way instead.
I've tried a large number of variants of the REXX logic to trace it's
progress, and in the hope of forcing something different to happen, all to
no avail.
Any ideas, anyone... please?
Regards
Sean
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
