APF is not the issue. Unless the entire ISPLLIB concatenation was specifically APF authorized, the entire DD name is considered unauthorized.
SYS1.AOST4 is a DLIB dataset. As such, it contains individual MODs, not complete LMODs. In this environment, any reference to an external entry point is unresolved and usually points to location 0. When that reference is actually branched to, the system attempts to execute the instruction at 0 which usually results in an 0C1. DLIB datasets should "never" be used in this manner. I have no idea why IBM included a DLIB in this concatenation but you probably don't want to use it. Not all delivered material is meant to be used as is. Much of it is intended to provide a starting point for you to customize. This appears to be such a case. -----Original Message----- From: Nasuh KARAHALLI [mailto:snip] Sent: Friday, April 13, 2007 4:09 AM To: [email protected] Subject: Re: Rexx LISTDSI problem on z/OS 1.7 ** SOLVED ** Good news, focused on the datasets in our logon procedure and clists and been tracking every dataset one by one. In logon clist ISPPDF delivered in CPAC.CMRPROC there exists a tso related load module dataset called SYS1.AOST4 in ISPLLIB section, once I removed this dataset logged off and logged on back the problem has been resolved. Since this dataset was not in APF list, I added it to APF and added it to ISPPDF member back again but the problem still persists. By removing this dataset from logon clist we also happened to resolve 0C1 problems while entering ICSF and BOOKMANAGER etc.. Any ideas for this ? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
