It's remotely possible that the exit itself is failing the logon. According to System Exits, RC 4 from IEFUJI denies the task. I don't know what that would look like to the user, but 'JCL error' is displayed for various logon failures that are not literally JCL. Since the exit is the only thing new/changed according to OP, it's the first smoking gun to vet.
. . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [email protected] From: John Eells <[email protected]> To: [email protected], Date: 06/26/2014 10:28 AM Subject: Re: IEFUJI problem, preventing TSO logon Sent by: IBM Mainframe Discussion List <[email protected]> Skip Robinson wrote: > Do you have NJE connection to another system that you can logon to? Cook > up a totally vanilla logon proc with no data sets. Ship it over and GENER > it into SYS1.PROCLIB > This is a great suggestion. Although I know most people do have one already, *everybody* should have a TSO-only logon proc with *no* data sets allocated in it. Also, everyone should have a rudimentary understanding of TSO EDIT and OUTPUT commands and subcommands. You don't need or want to be a pro (who'd want to be really proficient in TSO EDIT and OUTPUT when ISPF and SDSF are there?). Just play with them enough that you know how to list, edit, and save a data set or member; and to display job output. Then, when events like this one occur, you can: - Log on when the regular proc doesn't work - Edit the logon proc member - Change it to submit it as a batch job, save it with a new member name, and submit the job - See what happened (missing data set is the usual problem but there can be others) - Fix the problem (for example, allocate or catalog the data set, edit the proc to point to the right one) To expand on this a bit more, consider at least one UADS-only recovery user ID, to be used only when the external security manager (e.g., RACF) must be recovered in some fashion to work. Consider what would happen if your backup security database were corrupted and, before you discovered it or could fix it, you lost the primary. Being able to log on to recover would be a most convenient thing were that to happen. (You can trust me that the opposite is a most inconvenient thing.) Recovery when only one system is available is harder. But thinking about how to do it in advance and planting recovery seeds here and there--things like TSO-only logon procs--will save you gobs of time if you ever have to do it. In the meantime, that same NJE connection, if the OP has one, could be used to retrieve a copy of the proc, submit it as a job, retrieve the output, list catalog entries, etc., or even (rename and) replace the proc if necessary with an updated copy. -- John Eells z/OS Technical Marketing IBM Poughkeepsie [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
