ICH408I , HASP105 and IEFC621I during Dataquery Batch Submission,

Products

• Datacom

Issue/Introduction

When logged on to Dataquery on CICS and attempting to submit a batch job to z/OS, the continued JOB card statement is not being recognized. This issue causes the job to fail with various JCL errors.

The symptoms include the following error messages in the job output:

HASP105 EXPECTED CONTINUATION NOT RECEIVED
IEFC621I EXPECTED CONTINUATION NOT RECEIVED
IEFC006I POSITIONAL PARAMETERS MUST BE SPECIFIED BEFORE KEYWORD PARAMETERS


Also found in the CICS region where the DQRY batch query was being submitted from the following:15.24.44 STCXXXXX  ICH408I USER(user) GROUP(group) NAME(xxxx,xxxx)

   737               userid.SUBMIT CL(SURROGAT)

   737               INSUFFICIENT ACCESS AUTHORITY

   737               ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )

15.24.44 JOB07956  $HASP100 <jobname> ON INTRDR      P1 DATAQUERY-A041194  FROM S

15.24.44 JOB07956  $HASP105 <jobname> -- EXPECTED CONTINUATION NOT RECEIVED

15.24.44 JOB07956  $HASP119 <jobname> DELETED - MISSING CONTINUATION, RC=3

Environment

z/OS

Cause

The errors point to a situation where the JCL stream is interrupted during the submission process from CICS, leading to a missing or truncated JOB card continuation. The issue is caused by a RACF security violation (ICH408I) in the CICS region where the batch query is submitted. Specifically, the user or group lacks sufficient "READ" access to the SURROGAT class resource required for the batch submit ID (e.g., userid.SUBMIT). This security violation interrupts the internal processing of the JCL, preventing the continuation of the JOB card from being processed correctly.

Resolution

To resolve this issue, ensure that the appropriate users or groups have the necessary security permissions to perform batch submissions via the designated functional ID.

Additional Information

Verify Security Permissions Review the CICS job log or system log for security violations occurring at the time of the submission. Look for messages similar to: ICH408I USER(<userid>) GROUP(<group>) NAME(<name>) <resource> CL(SURROGAT) INSUFFICIENT ACCESS AUTHORITY

Grant Surrogat Authority If a security violation is identified, the security administrator must grant the submitting user or their group the required access. For example, in RACF:

Identify the group or user lacking access (e.g., <groupname>).
Grant READ access to the SURROGAT resource for the batch ID being used: PERMIT <functional_id>.SUBMIT CLASS(SURROGAT) ID(<groupname>) ACCESS(READ)
Refresh the SURROGAT class if necessary: SETROPTS RACLIST(SURROGAT) REFRESH
Confirm Batch User ID Configuration Ensure that the correct functional ID is being used for submissions. If a different ID than usual is being utilized , verify that all relevant groups (such as DBAs or specific application groups) have been granted the same permissions for the new ID.