Re: DAIR error 0470 allocating internal reader

[Jim Mulder]

  I was only trying to answer the question of how OA50565 allows this 
to work for IDCAMS.   I don't know if there was any "rational for 
newly restricting JCL permission in a batch job".  I would guess that 
the original design of IKJTSOEV did not consider PSCBJCL or PSCBVMNT,
so they always were off in a PSCB built by IKJTSOEV.  When IDCAMS 
later started using IKJTSOEV, some tactical accommodations were 
added to meet only the needs of IDCAMS. 

  The issue of MOUNT or JCL authority for other users of IKJTSOEV 
remains unsolved, as far as I know.  You can as always feel free 
to submit a requirement through the usual mechanism, or engage 
via the support process. 

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

> > The  OA50565 fix changed  the TSO/E environment service to turn on 
PSCBJCL
> > when running in an APF authorized jobstep (i.e. when JCSBAUTH is on).
> > IDCAMS is linked in SYS1.LINKLIB with AC(1), so an EXEC PGM=IDCAMS 
jobstep
> > is APF authorized.
> 
> One might expect that to keep behaviour as much the same as possible,
> IKJTSOEV would check for a TSO segment in RACF and honour the JCL (and
> MOUNT and even OPER etc.) setting in that. If there is no TSO segment,
> then why not fall back to standard batch job behaviour? What is the
> rational for newly restricting JCL permission in a batch job? JCL has
> not historically depended on being APF authorized in a non-TSO batch
> job.



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

Re: DAIR error 0470 allocating internal reader

[Jim Mulder]

  Upon further investigation of the code, APF authorization by itself is 
not sufficient.
There is also an internal undocumented part of the IKJTSOEV interface 
which 
IDCAMS uses.

  There is no way to remove the environment created by IKJTSOEV (other 
than
job step termination).   There is no mechanism in TSO/E to serialize 
against deletion
of control blocks created by IKJTSOEV, so it is not safe to delete them. 
 
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


> Jim-
> Thanks, so we need to apply the PTF. I will changes my code to check for
> PSCBJCL and only force it on if necessary.
> 
> Cheers
> Robin
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jim Mulder
> Sent: 09 November 2016 10:05
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DAIR error 0470 allocating internal reader
> 
> The  OA50565 fix changed  the TSO/E environment service to turn on 
PSCBJCL 
> 
> when running in an APF authorized jobstep (i.e. when JCSBAUTH is on). 
> IDCAMS is linked in SYS1.LINKLIB with AC(1), so an EXEC PGM=IDCAMS 
jobstep
> is APF authorized. 
> 
> 
> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
> Poughkeepsie NY
> 
> 
> > A venerable STC started getting 0470 ("user unauthorized for
> > subsystem") when trying to allocate an INTRDR after we added a lot of 
> > new function in a separate subtask. Disabling the new subtask allowed 
> > the allocation to work as before.
> > Searching I found OA50565 which describes the same thing happening to 
> > IDCAMS. The problem was the new subtask was calling IKJTSOEV and that 
> > causes the PSCBJCL flag to be turned off so the task cannot submit 
> > jobs. The apar states that IDCAMS now establishes a TSF with the 
> > PSCBJCL on without saying how. I tried forcing the PSCBJCL flag on 
> > after the call to IKJTSOEV but that resulted in an LE exception when I 

> > tried the allocation in the other task. Toggling the flag in the task 
> > that does the allocation seems to work OK so far: I set the flag on, 
> > allocate the INTRDR, turn it off and nobody seems to notice.
> > 
> > I am not too happy with this arrangement! Does someone know how to 
> > establish the TSF with the PSCBJCL flag on as in IDCAMS, or equally 
> > good, how to cancel the TSF once it is established. I could find no 
> > function call that does that.



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

Re: DAIR error 0470 allocating internal reader

[Walt Farrell]

On Wed, 9 Nov 2016 11:51:59 -0500, Tony Harminc  wrote:

>On 8 November 2016 at 22:04, Jim Mulder  wrote:
>> The  OA50565 fix changed  the TSO/E environment service to turn on PSCBJCL
>> when running in an APF authorized jobstep (i.e. when JCSBAUTH is on).
>> IDCAMS is linked in SYS1.LINKLIB with AC(1), so an EXEC PGM=IDCAMS jobstep
>> is APF authorized.
>
>One might expect that to keep behaviour as much the same as possible,
>IKJTSOEV would check for a TSO segment in RACF and honour the JCL (and
>MOUNT and even OPER etc.) setting in that. If there is no TSO segment,
>then why not fall back to standard batch job behaviour? What is the
>rational for newly restricting JCL permission in a batch job? JCL has
>not historically depended on being APF authorized in a non-TSO batch
>job.

Historically, an APF-authorized program could not make use of IKJTSOEV to 
establish a TSO environment. IKJTSOEV was usable only in a non-APF environment.

They apparently relaxed that IKJTSOEV restriction when IDCAMS (which typically 
runs APF-authorized) decided to create a full TSO environment to run the 
ALLOCATE command rather than simply ATTACHing the command processor itself. But 
in relaxing the restriction the environment that IKJTSOEV established did not 
allow for JCL (nor MOUNT) authority.

I don't recall what happens (i.e., what PSCB settings are established) for a 
batch job that runs IKJEFT01 when the user running the job has neither a TSO 
segment nor a UADS entry. I agree, though, that having IKJTSOEV establish its 
environment in a way compatible with batch IKJEFT01 (including checking the 
RACF TSO segment or UADS) would be the best approach. 

-- 
Walt

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

Re: DAIR error 0470 allocating internal reader

[Tony Harminc]

On 8 November 2016 at 22:04, Jim Mulder  wrote:
> The  OA50565 fix changed  the TSO/E environment service to turn on PSCBJCL
> when running in an APF authorized jobstep (i.e. when JCSBAUTH is on).
> IDCAMS is linked in SYS1.LINKLIB with AC(1), so an EXEC PGM=IDCAMS jobstep
> is APF authorized.

One might expect that to keep behaviour as much the same as possible,
IKJTSOEV would check for a TSO segment in RACF and honour the JCL (and
MOUNT and even OPER etc.) setting in that. If there is no TSO segment,
then why not fall back to standard batch job behaviour? What is the
rational for newly restricting JCL permission in a batch job? JCL has
not historically depended on being APF authorized in a non-TSO batch
job.

Tony H.

Tony H.

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

Re: DAIR error 0470 allocating internal reader

[Robin Atwood]

Jim-
Thanks, so we need to apply the PTF. I will changes my code to check for
PSCBJCL and only force it on if necessary.

Cheers
Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Mulder
Sent: 09 November 2016 10:05
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DAIR error 0470 allocating internal reader

The  OA50565 fix changed  the TSO/E environment service to turn on PSCBJCL 

when running in an APF authorized jobstep (i.e. when JCSBAUTH is on). 
IDCAMS is linked in SYS1.LINKLIB with AC(1), so an EXEC PGM=IDCAMS jobstep
is APF authorized. 


Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


> A venerable STC started getting 0470 ("user unauthorized for
> subsystem") when trying to allocate an INTRDR after we added a lot of 
> new function in a separate subtask. Disabling the new subtask allowed 
> the allocation to work as before.
> Searching I found OA50565 which describes the same thing happening to 
> IDCAMS. The problem was the new subtask was calling IKJTSOEV and that 
> causes the PSCBJCL flag to be turned off so the task cannot submit 
> jobs. The apar states that IDCAMS now establishes a TSF with the 
> PSCBJCL on without saying how. I tried forcing the PSCBJCL flag on 
> after the call to IKJTSOEV but that resulted in an LE exception when I 
> tried the allocation in the other task. Toggling the flag in the task 
> that does the allocation seems to work OK so far: I set the flag on, 
> allocate the INTRDR, turn it off and nobody seems to notice.
> 
> I am not too happy with this arrangement! Does someone know how to 
> establish the TSF with the PSCBJCL flag on as in IDCAMS, or equally 
> good, how to cancel the TSF once it is established. I could find no 
> function call that does that.



--
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: DAIR error 0470 allocating internal reader

[Jim Mulder]

The  OA50565 fix changed  the TSO/E environment service to turn on PSCBJCL 

when running in an APF authorized jobstep (i.e. when JCSBAUTH is on). 
IDCAMS is linked in SYS1.LINKLIB with AC(1), so an EXEC PGM=IDCAMS jobstep
is APF authorized. 


Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


> A venerable STC started getting 0470 ("user unauthorized for 
> subsystem") when trying to allocate an INTRDR after we
> added a lot of new function in a separate subtask. Disabling the new
> subtask allowed the allocation to work as before.
> Searching I found OA50565 which describes the same thing happening 
> to IDCAMS. The problem was the new 
> subtask was calling IKJTSOEV and that causes the PSCBJCL flag to be 
> turned off so the task cannot submit jobs. The apar 
> states that IDCAMS now establishes a TSF with the PSCBJCL on without
> saying how. I tried forcing the PSCBJCL flag on after 
> the call to IKJTSOEV but that resulted in an LE exception when I 
> tried the allocation in the other task. Toggling the flag in the
> task that does the allocation seems to work OK so far: I set the 
> flag on, allocate the INTRDR, turn it off and nobody seems to
> notice. 
> 
> I am not too happy with this arrangement! Does someone know how to 
> establish the TSF with the PSCBJCL flag on as in IDCAMS, or equally 
> good, how to cancel the TSF once it is established. I could find no 
> function call that does that.



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

Re: DAIR error 0470 allocating internal reader

[Binyamin Dissen]

I wonder if using JSTCB=YES and providing a different PSCB address in the new
JSCB.

 Of course this will require a subtasks to be jobstep tasks as well ...

On Tue, 8 Nov 2016 17:56:45 +0700 Robin Atwood  wrote:

:>A venerable STC started getting 0470 ("user unauthorized for subsystem") when 
trying to allocate an INTRDR after we
:>added a lot of new function in a separate subtask. Disabling the new subtask 
allowed the allocation to work as before.
:>Searching I found OA50565 which describes the same thing happening to IDCAMS. 
The problem was the new 
:>subtask was calling IKJTSOEV and that causes the PSCBJCL flag to be turned 
off so the task cannot submit jobs. The apar 
:>states that IDCAMS now establishes a TSF with the PSCBJCL on without saying 
how. I tried forcing the PSCBJCL flag on after 
:>the call to IKJTSOEV but that resulted in an LE exception when I tried the 
allocation in the other task. Toggling the flag in the
:>task that does the allocation seems to work OK so far: I set the flag on, 
allocate the INTRDR, turn it off and nobody seems to
:>notice. 
:>
:>I am not too happy with this arrangement! Does someone know how to establish 
the TSF with the PSCBJCL flag on as in IDCAMS, or equally good, how to cancel 
the TSF once it is established. I could find no function call that does that.
:>
:>Thanks
:>Robin
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: DAIR error 0470 allocating internal reader

[Robin Atwood]

Thanks for the suggestion but the point of the exercise was to reduce the 
number of ASIDs that must be managed!
Otherwise a very sensible idea.

Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: 08 November 2016 19:13
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DAIR error 0470 allocating internal reader

I don't know the answer to your question, but I appreciate the problem.  It 
sounds like you might be headed into a Catch-22 rabbit-hole (to mix some 
metaphors).  Have you considered putting some function in an auxiliary address 
space?  I think it's the ASCRE macro that lets you do this easily, at the cost 
of having to do some AR-mode (or other means) to share information.

sas

On Tue, Nov 8, 2016 at 5:56 AM, Robin Atwood <abend...@gmail.com> wrote:

> A venerable STC started getting 0470 ("user unauthorized for 
> subsystem") when trying to allocate an INTRDR after we added a lot of 
> new function in a separate subtask. Disabling the new subtask allowed 
> the allocation to work as before.
> Searching I found OA50565 which describes the same thing happening to 
> IDCAMS. The problem was the new subtask was calling IKJTSOEV and that 
> causes the PSCBJCL flag to be turned off so the task cannot submit 
> jobs. The apar states that IDCAMS now establishes a TSF with the 
> PSCBJCL on without saying how. I tried forcing the PSCBJCL flag on 
> after the call to IKJTSOEV but that resulted in an LE exception when I 
> tried the allocation in the other task. Toggling the flag in the task 
> that does the allocation seems to work OK so far: I set the flag on, 
> allocate the INTRDR, turn it off and nobody seems to notice.
>
> I am not too happy with this arrangement! Does someone know how to 
> establish the TSF with the PSCBJCL flag on as in IDCAMS, or equally 
> good, how to cancel the TSF once it is established. I could find no 
> function call that does that.
>
> Thanks
> Robin
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



--
sas

--
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: DAIR error 0470 allocating internal reader

[Steve Smith]

I don't know the answer to your question, but I appreciate the problem.  It
sounds like you might be headed into a Catch-22 rabbit-hole (to mix some
metaphors).  Have you considered putting some function in an auxiliary
address space?  I think it's the ASCRE macro that lets you do this easily,
at the cost of having to do some AR-mode (or other means) to share
information.

sas

On Tue, Nov 8, 2016 at 5:56 AM, Robin Atwood  wrote:

> A venerable STC started getting 0470 ("user unauthorized for subsystem")
> when trying to allocate an INTRDR after we
> added a lot of new function in a separate subtask. Disabling the new
> subtask allowed the allocation to work as before.
> Searching I found OA50565 which describes the same thing happening to
> IDCAMS. The problem was the new
> subtask was calling IKJTSOEV and that causes the PSCBJCL flag to be turned
> off so the task cannot submit jobs. The apar
> states that IDCAMS now establishes a TSF with the PSCBJCL on without
> saying how. I tried forcing the PSCBJCL flag on after
> the call to IKJTSOEV but that resulted in an LE exception when I tried the
> allocation in the other task. Toggling the flag in the
> task that does the allocation seems to work OK so far: I set the flag on,
> allocate the INTRDR, turn it off and nobody seems to
> notice.
>
> I am not too happy with this arrangement! Does someone know how to
> establish the TSF with the PSCBJCL flag on as in IDCAMS, or equally good,
> how to cancel the TSF once it is established. I could find no function call
> that does that.
>
> Thanks
> Robin
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
sas

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