CL RESTART Violations.

Document created by Chris_Williams Employee on Sep 25, 2015
Version 1Show Document
  • View in full screen mode

Normally, when RESTART=<stepname> is used in Jobcards, Steps before <stepname> are skipped and execution begins with Step <stepname>.  But, security failures occur on skipped steps and the Userid, running the Job, is suspended due to excess violations.

 

This situation can occur if a Programmer copies production JCL, and updates just the Steps they intend to rerun, using RESTART=<stepname> to skip to those steps.  So, the question here is: Is there an option to check security only on the Steps that are actually being run?

 

The answer to this question is:

==========================================================================================================

For an SMS Dataset, SMS attempts to PRE-VALIDATE security access to create a Dataset before a Job Step runs, even in the case where a

Step is not actually run due to 'RESTART=******' in the Jobcard.  Top Secret has no control over it, or the option to bypass security checking

for Steps that are not actually run, i.e. working as designed.

==========================================================================================================

 

Now for further details, into resolving this Case, from the Joblog:

===================================================

1 //SS010BCT JOB (0,0,0,0,0,PRODUCTION),ICOMS, JOB05134

// MSGCLASS=R,NOTIFY=SS010BC,

// class="A",RESTART=STEP040

 

18 //STEP020 EXEC PGM=STMR620,COND=(0,NE)

 

26 //ITEMEXT DD DSN=PICSQ.ICMR625.STEP020.EXTRACT,

// DISP=(NEW,CATLG,DELETE),

// RECFM=FB,LRECL=1200,

// SPACE=(TRK,(600,150),RLSE),

// UNIT=SYSWRK

 

27 //STEP030 EXEC SORTD,COND=(0,NE)

 

37 //SORTOUT DD DSN=PICSQ.ICMR625.STEP030.EXTRACT.SORTED,

// DISP=(NEW,CATLG,DELETE),

// RECFM=FB,LRECL=1200,

// SPACE=(TRK,(600,150),RLSE),

// UNIT=SYSWRK

 

39 //STEP040 EXEC PGM=STMR625,COND=(0,NE)

...

 

TSS7227E CREATE Access Not Granted to Dataset

PICSQ.ICMR625.STEP020.EXTRACT

 

TSS7227E CREATE Access Not Granted to Dataset

PICSQ.ICMR625.STEP030.EXTRACT.SORTED

 

26 IGD308I DATA SET ALLOCATION REQUEST FAILED -

RACF FUNCTION: RACDEF FOR

DATA SET: PICSQ.ICMR625.STEP020.EXTRACT WITH

RETURN CODE 08 REASON CODE 00

 

37 IGD308I DATA SET ALLOCATION REQUEST FAILED -

RACF FUNCTION: RACDEF FOR

DATA SET: PICSQ.ICMR625.STEP030.EXTRACT.SORTED WITH

RETURN CODE 08 REASON CODE 00

===================================================

 

With RACF, instead of the TSS7227E message, you would get:

=========================================

** ICH408I USER(ADCDA ) GROUP(TEST ) NAME(ADCDA )

** ADCDB.BR14 CL(DATASET ) VOL(*BLANK)

** DEFINE - INSUFFICIENT AUTHORITY

=========================================

...and the Job would fail the same way.

 

SMS will get involved for any DD Cards that shows 'DISP=NEW' or 'DISP=MOD', even if they are not going to be used, as documented in IBM APAR OY44270:

=======================================================

COMMENTS:

IT IS THE CURRENT DESIGN OF DFSMS THAT AUTHORIZATION CHECKING

IS DONE DURING CONVERTER/INTERPRETER TIME. ALL THE STEPS IN A

JOB WILL BE EXAMINED. THE RESTART KEYWORD HAS NO MEANING AT

THIS TIME. SOME USERS IN FACT UTILIZE THIS DESIGN

SPECIFICATION TO 'PRE-SCAN' THEIR JCL FOR AUTHORIZATION ERRORS

WHILE NOT ACTUALLY RUNNING THE STEPS. THIS APAR IS BEING

CLOSED SUG SO THAT SOME ACCOMMODATION OF THESE TWO USER GROUPS

MAY BE CONSIDERED FOR INCLUSION IN A FUTURE RELEASE OF THE

PRODUCT.

=======================================================

 

If required, you can replace the 'DISP=NEW' or 'DISP=MOD' with 'DISP=OLD' in the earlier Steps.  This should allow the Job to execute from the RESTART Step.

Attachments

    Outcomes