We are trying to convert from SNA to TCP/IP for DB2 DRDA access. Why do we get message ACF01030 LOGONID xxxxxxx HAS THE STC ATTRIBUTE AND CANNOT BE USED FOR NORMAL ACCESS when we use the DB2 DRDA connection to do loads from one DB2 subsystem to another?
Article ID: 38626
Updated On:
Products
Issue/Introduction
Question:
We are trying to convert from SNA to TCP/IP for DB2 DRDA access. Why do we get message ACF01030 LOGONID xxxxxxx HAS THE STC ATTRIBUTE AND CANNOT BE USED FOR NORMAL ACCESS when we use the DB2 DRDA connection to do loads from one DB2 subsystem to another?
Answer:
To address the ACF01030 message sites can define GSO STC records for the propagator tasks to assign the task it's own logonid. This GSO record allows you to assign a different logonid(without the STC privilege) to a started task different from the procname.
Another feature of this GSO record is that the new logonid you associate with the started task does not have to have the STC bit, yet ACF2 will still allow it to be used (this is the only place ACF2 makes an exception).
For example if the propagator's address space logonid is D2PROP you can create a GSO STC record that assigns the D2PROP lid to the D2PROP address space:
SET CONTROL(GSO)
INSERT STC.DRDA STCID(D2PROP) LOGONID(D2PROP)
Then:
F ACF2,REFRESH(STC)
What this does is assign the D2PROP logodid to the propagator's address space so the STC has a lidrec that does not contain the STC attribute and you won't
get the ACF01030 message when a VERIFY call with a passticket is issued.
The GSO STC record bypasses the check to ensure a started task lid has the STC attribute.
Additional Information:
Details on the ACF2 GSO STC record can be found in the CA ACF2 for z/OS Administration Guide, Chapter 14: Maintaining Global System Options Records, section 'Started Task (STC)'.
Environment
Component: ACF2MS
Feedback
