I don’t know where the build JCL came from cuz it was here before I got
here. I’ll keep that in mind too, thanks!
On Fri, Sep 22, 2023 at 2:35 PM Mark Zelden wrote:
> On Thu, 21 Sep 2023 06:50:01 -0500, Michael Babcock
> wrote:
>
> >Thanks Rob! That’s the explanation I needed! However, I d
On Thu, 21 Sep 2023 06:50:01 -0500, Michael Babcock
wrote:
>Thanks Rob! That’s the explanation I needed! However, I did create a
>ISF*.** profile with a UACC of ALTER but it still didn’t work because I
>didn’t have NOFAILRC4 (I assume).
>
>On Thu, Sep 21, 2023 at 2:52 AM Rob Scott wrote:
>
Thanks Rob! That’s the explanation I needed! However, I did create a
ISF*.** profile with a UACC of ALTER but it still didn’t work because I
didn’t have NOFAILRC4 (I assume).
On Thu, Sep 21, 2023 at 2:52 AM Rob Scott wrote:
> Michael
>
> Although we strongly recommend JESSPOOL (and OPERCMDS)
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 han
We did not previously convert this one pack rescue system to SDSF external
security. This is the first time IPLing it with z/OS 2.5. I defined the
GROUP.SYSPROG.* profile in SDSF, refreshed the SDSF class, made the
necessary ISFPRMxx member and refreshed SDSF. I could not browse any
output in
W dniu 20.09.2023 o 19:49, Michael Babcock pisze:
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
SDSF is SAF controlled
Sent from my iPhone
No one said I could type with one thumb
> On Sep 20, 2023, at 12:49, Michael Babcock wrote:
>
> 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
> r
