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 [email protected] with the message: INFO IBM-MAIN
