IEC150I - 913-70 After
search cancel

IEC150I - 913-70 After

book

Article ID: 50797

calendar_today

Updated On:

Products

Cleanup Datacom DATACOM - AD CIS COMMON SERVICES FOR Z/OS 90S SERVICES DATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OS COMMON PRODUCT SERVICES COMPONENT Common Services CA ECOMETER SERVER COMPONENT FOC Easytrieve Report Generator for Common Services INFOCAI MAINTENANCE IPC UNICENTER JCLCHECK COMMON COMPONENT Mainframe VM Product Manager CHORUS SOFTWARE MANAGER CA ON DEMAND PORTAL CA Service Desk Manager - Unified Self Service PAM CLIENT FOR LINUX ON MAINFRAME MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME GRAPHICAL MANAGEMENT INTERFACE WEB ADMINISTRATOR FOR TOP SECRET Xpertware Top Secret Top Secret - LDAP Top Secret - VSE

Issue/Introduction

Description:

After applying CA Top Secret 14.0 fix RO12734, the following errors are occurring.

IEC150I - 913-70,module,jobname,stepname,ddname,device,volser,data.set.name

There are rules setup to allow FETCH for dataset.

XA DATASET = 'data.set.name' 
ACCESS = FETCH

This setting allows a user to submit a job and include the appropriate member in their jcl.

Why is the IEC150I occurring and why isn't there a CA Top Secret error message or violation?

Solution:

RO12734 ( CA Top Secret 14.0) (and RO10222 (CA Top Secret 12.0) ) closed a loophole where FETCH access allowed access when it should not have.

FETCH access is supposed to restrict the user to loading a program from a program library through standard operating system services, such as LOAD, LINK, or ATTACH. It should restrict the user so that the only access to the data is through these services, which generally means that the user can reference the library as a STEPLIB or set it up as a TASKLIB but should not be able to access it in any other way. If this is how FETCH access is being used, there should be no problems.

The old method of enforcing FETCH access was to install an I/O intercept at OPEN time. If any additional I/O was done to the dataset, CA Top Secret would evaluate at that time whether FETCH access was appropriate to the access taking place. This had 2 problems. The one that led to new maintenance being written was that the abends would occur on a subsequent I/O, not at OPEN time. Some recovery routines were unable to handle the abends, as they were not expecting abends at this point in the processing.

The other problem was that an OPEN for sequential processing will fill the buffers with data, and this was taking place before CA Top Secret installed the I/O intercept. Since the enforcement routine only got control on physical I/O, for a small dataset (or a small member in a library) there might not be any more physical I/O needed and our routine never got control. This doesn't mean that FETCH access was appropriate for the I/O that was taking place, but CA Top Secret never got control so no abend was ever issued.

The users will now need READ access to the dataset(s) in the instances where the S913-70 abends are occurring but FETCH access used to allow access. One option is to use PRIVPGM permits for READ access to allow the access in this instance, but prevent users from reading these datasets.

If the library the program resides comes from the linklist, a LIB operand is not necessary on the PRIVPGM permit.

If the library the program resides comes from a STELIB, JOBLIB, or TASKLIB, a LIB operand is necessary on the PRIVPGM permit. The LIB operand can have the fully qualified dataset name for the library or a prefix of the library.

With RO12734 or RO10222 applied, DFSMS is handling the fetch request as it will fail if your access is for fetch and are opening for read which is correct. The drawback to the change is that, while the results are always correct, CA Top Secret has no way of issuing any messages or logging the violation as we are not making the decision as to whether or not the call will fail. That decision is left to dfSMS code.

Environment

Release:
Component: AWAGNT