On Wed, 9 Nov 2016 11:51:59 -0500, Tony Harminc <t...@harminc.net> wrote:
>On 8 November 2016 at 22:04, Jim Mulder <d10j...@us.ibm.com> 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
