Charles,
I know almost nothing about "Contents Supervision" functions but I do see a
possible explanation for the difference between the LPA case and the STEPLIB
case. In the case of LPA the module is formally in storage all the time
whereas in the case of STEPLIB, the module is *logically* loaded again even
if it isn't physically loaded again so that may be a difference.
5.1.3 Return Codes (under "5.1 Description" under "5.0 IDENTIFY -- Add an
Entry Name" in "MVS Assembler Services Reference")
When control is returned, register 15 contains one of the following return
codes:
Hexadecimal Return Code Meaning
00 Successful completion of requested
function.
04 Entry name and address already
exist.
08 Entry name duplicates the major
name of a load module currently in virtual storage;
entry address was not added.
Chris Mason
----- Original Message -----
From: "Charles Mills" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <[email protected]>
Sent: Wednesday, 25 January, 2006 3:50 PM
Subject: Re: IDENTIFY macro question
> The second LOAD does not somehow "abolish" the first, it just ups the
usage
> count and returns the same address. You are simply trying to name the same
> address (the address in LPA of PROGRAM1) the same thing twice. (The ATTACH
> part is irrelevant to the story.)
>
> I'm surprised the STEPLIB scenario you describe works, but it may be
because
> the second LOAD does somehow undo the first, and Contents Supervision is
> smart enough to get rid of your IDENTIFY also.
>
> Charles
>
>
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf
> Of Ira Broussard
> Sent: Tuesday, January 24, 2006 10:40 PM
> To: [email protected]
> Subject: IDENTIFY macro question
>
>
> Here is the scenario...
>
> 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.
>
> 6. IDENTIFY EP=PROGRAMA,ENTRY=(entry point returned from LOAD) This
> fails
> with R15=8.
>
> 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. Also, if after the IDENTIFY fails, I try to attach
> PROGRAM1
> (instead of PROGRAMA) which is in PLPA, it fails with a S806-C.
>
> 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.
>
> 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.
----------------------------------------------------------------------
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
