Ben, You are correct on both points. When it works (PROGRAM1 is not in the LPA), the second IDENTIFY gets a return code of four, which I treat as okay. I should have simplified my question by asking why does the IDENTIFY get a RC=4 if PROGRAM1 is not in the LPA and a RC=8 if PROGRAM1 is in the LPA. In both cases, I'm running unauthorized, so I would have expected the same return code for the second IDENTIFY (RC=4) regardless of whether or not PROGRAM1 is in LPA. Should I treat RC=4 and RC=8 the same, or are there other reasons that will cause a RC=8. I don't always know that it is the non-zero RC occurs on a second/subsequent IDENTIFY. Also, you were correct on the ATTACH plist not being cleared. Thanks, Ira In a message dated 1/25/2006 2:00:36 A.M. Central Standard Time, [EMAIL PROTECTED] writes:
On Wed, 25 Jan 2006 01:40:28 EST Ira Broussard <[EMAIL PROTECTED]> wrote: :>PROGRAM1 is in LPA (actually, dynamically added to the MLPA in this case :>during testing, but it the sequence also fails if it is in LPA) and is marked as :>"RF RN RU", amode31, rmode any. The following sequence is executed by an :>unauthorized, key 8 program... :>1. LOAD EP=PROGRAM1 This works correctly. :>2. IDENTIFY EP=PROGRAMA,ENTRY=(entry point returned from LOAD) This works. :>3. ATTACH EP=PROGRAMA This works. A subtask is attached and PROGRAM1 runs. :>If I use XDC at this point to display the TCB's (L TASKS), it shows a :>subtask named PROGRAMA, which is what I expected. :>4. PROGRAMA is subsequently detached correctly. XDC says the subtask is gone. :>5. LOAD EP=PROGRAM1 Again, this works correctly. Same entry point :>returned. No rule against loading a module multiple times. :>6. IDENTIFY EP=PROGRAMA,ENTRY=(entry point returned from LOAD) This fails :>with R15=8. Because it is still there. I would have expected a 4, though. :>In the above steps, the results of both LOADs (step 1 and step 5) return the :>identical entry point, and that entry point is used for both IDENTIFY :>macros. There are no intervening DELETEs. I don't understand why the IDENTIFY macro :>in step 6 fails. It fails because you already did an IDENTIFY. :> Also, if after the IDENTIFY fails, I try to attach PROGRAM1 :>(instead of PROGRAMA) which is in PLPA, it fails with a S806-C. 806-C indicates that you supplied a DCB address and the specified DCB was closed. Perhaps you did not clear the ATTACH plist? :>Last oddity...All of this works correctly, i.e., second IDENTIFY works and I :>can subsequently do another ATTACH of PROGRAMA, if I take PROGRAM1 out of :>PLPA and move it into the STEPLIB concatenation. IDENTIFY works differently if an unauthorized routine creates an alias of an LPA module. :>FYI...PROGRAM1 is actually the CICS program DFHSKTSK, and PROGRAMA is just :>another name I want to be able to "call" it. This is all running in a :>"controlled" CICS region, so the task doing the above sequence is not the job step :>task. -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
