# AEY7: NOTAUTH not handled Source: https://wndsoftware.com/mainframe-errors/aey7 ### AEY7: NOTAUTH not handled An AEY7 abend means a CICS command failed a security check, CICS returned the NOTAUTH condition, and the program didn't handle it. The user ID running the task isn't authorized for the resource or command it asked for. #### Other names for this code Also written as `AEY7 abend`, `CICS AEY7`, `abend AEY7`, `NOTAUTH`, `CICS NOTAUTH`, `AEY7 NOTAUTH`, `not authorized CICS`. ### What it means When CICS security is active, CICS can check the task's user ID against the external security manager before it runs a command. Resource security checks access to things the command touches, such as files, TS and TD queues, programs and started transactions. It applies to transactions defined with RESSEC(YES). Command security checks the system programming commands, such as INQUIRE and SET, for transactions defined with CMDSEC(YES). The SIT options RESSEC and CMDSEC can force these checks for every transaction. If a check fails, the command returns NOTAUTH. The same condition comes back from sign-on and password commands such as SIGNON, VERIFY PASSWORD and CHANGE PASSWORD when the credentials aren't accepted. IBM's response code table for the ENABLE, DISABLE and EXTRACT EXIT commands lists NOTAUTH as RESP value 70 with abend code AEY7. The default action for NOTAUTH is to abend the task with AEY7. A program that codes `RESP(WS-RESP) RESP2(WS-RESP2)`, which implies NOHANDLE, gets control back and can test for `DFHRESP(NOTAUTH)`. Older programs use `HANDLE CONDITION NOTAUTH(paragraph)`. ### Common causes - The user ID has no access, or too little access, to the resource profile. A user with READ to a file profile in the FCICSFCT class can read the file but gets NOTAUTH on a WRITE or REWRITE, which need UPDATE. - A transaction was moved into a region with security active, or changed to RESSEC(YES) or CMDSEC(YES), and nobody granted the access its commands need. - The task runs under a different user ID than before. IBM's notes describe a CPSM transaction getting AEY7 after CICS TS 5.4 began running PLT programs under the region user ID, which lacked some access. - A system program issues INQUIRE or SET under a user who lacks command authority. APAR PH17198 describes the CESL sign-on transaction abending AEY7 on SET TERMINAL for exactly this reason. - A rule in a non-RACF security product, such as ACF2 or Top Secret, rejects the request. ### How to find the problem - Look in the CICS log for message DFHXS1111. It names the user ID, the resource and the security class that failed. - Check the z/OS console or job log for RACF message `ICH408I`, which shows the profile, the access asked for and the access allowed. - In the transaction dump, EIBFN shows the command, EIBRSRCE the resource name, and EIBRESP2 the reason. - Display the profile with `RLIST FCICSFCT name AUTHUSER`, or the class that matches the resource, to see who has which access. Classes include SCICSTST for TS queues, DCICSDCT for TD queues, MCICSPPT for programs, ACICSPCT for started transactions and CCICSCMD for commands. Your site may use its own class names. ### How to fix it - Grant the access the task really needs, for example `PERMIT name CLASS(FCICSFCT) ID(group) ACCESS(UPDATE)`, then refresh the class with `SETROPTS RACLIST(FCICSFCT) REFRESH`. Depending on the release and setup, the user may need to sign off and on before CICS sees the change. - Handle NOTAUTH where it can be expected. Sign-on code should test for it and show a clear message, and other programs should log the resource and RESP2 before ending cleanly. - Don't turn off RESSEC or CMDSEC to make the abend go away. Fix the access instead. - The security administrators usually make the fix. The application team supplies the resource name and the access the transaction needs. ### What it looks like ```text DFHDU0203I 10/18/2026 08:31:17 CICSPRD1 A transaction dump was taken for dumpcode: AEY7, Dumpid: 1/0011. DFHAC2206 08:31:17 CICSPRD1 Transaction PAY1 failed with abend AEY7. Updates to local recoverable resources backed out. ``` ### IBM documentation [IBM documentation: AEY7](https://www.ibm.com/docs/en/cics-ts/6.x?topic=codes-aey7). Use the documentation for your installed release. [Report a correction to WND Software](https://wndsoftware.com/contact#message). Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s CICS documentation for your release. ### Related codes [ICH408I RACF denied access Read →](https://wndsoftware.com/mainframe-errors/ich408i) [S913 Security access denied Read →](https://wndsoftware.com/mainframe-errors/s913) [AEIL DSIDERR (FILENOTFOUND) not handled Read →](https://wndsoftware.com/mainframe-errors/aeil) [AEI0 PGMIDERR not handled Read →](https://wndsoftware.com/mainframe-errors/aei0) [AEIP INVREQ not handled Read →](https://wndsoftware.com/mainframe-errors/aeip) ### Questions #### Why does the transaction work in test but abend AEY7 in production? Test regions often run with security off or with wide access. Production checks the real profiles, so missing access only shows up there. #### Is there always an ICH408I message with AEY7? Not always. The security manager's logging options decide whether a failure is written to the console. Message DFHXS1111 in the CICS log is the more reliable place to look. #### What is the difference between AEY7 and S913? Both are security failures. S913 is a z/OS abend when a batch job or TSO user can't open a data set. AEY7 is a CICS task failing a CICS resource or command check. [CICS transaction abends](https://wndsoftware.com/mainframe-errors/cics-abends) · [AEXY](https://wndsoftware.com/mainframe-errors/aexy) · [AEY9](https://wndsoftware.com/mainframe-errors/aey9) [← All error codes](https://wndsoftware.com/mainframe-errors/)