On Wed, 25 Jan 2006 11:07:46 EST Ira Broussard <[EMAIL PROTECTED]> wrote:
:> :>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. Perhaps that is because of the differences on how an IDENTIFY works from an unauthorized program to LPA. It appears to build a major CDE rather than a minor one. :>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. 4 or 8 means that the name is already known. Your only concern is if something else might create the same name. You can use a LOAD against the alias and see if it returns the same address. :>Also, you were correct on the ATTACH plist not being cleared. :>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
