I looked at IEAVID00, and I think it searches only LLEs, and not job pack queue. And also the CDE pointed to by the RB that issued the IDENTIFY.
Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY (845) 435-4741 D10JHM1@PLPSC (MVS) JMULDER@S390VM (VM) From: Peter Relson/Poughkeepsie/IBM@IBMUS To: [email protected] Date: 03/21/2018 02:03 PM Subject: Re: invalid ENTRY address for IDENTIFY macro There is not enough information provided to give a well-reasoned explanation. The rule is simple: the entry point address must fit within the range identified by the extent list (which has module start address and length) of some module on the job pack queue or your load list (where the load list might point to something in LPA which would not be represented in a CDE on your JPQ). What you need to do is to show the data that you are providing to IDENTIFY when it doesn't work, coupled with the complete job pack queue CDEs/XTLSTs (and, if your address is in common storage, the load list (TCBLLS). An SVC Dump or SYSMDUMP would capture this data. I'd watch out for whether you have the high bit on (or the low bit on, for that matter). The address you provide is expected not to be "pointer-defined" (i.e., not be suitable for use with BASSM). An AMODE 24 caller of IDENTIFY will have the high byte of the entry point address zeroed. Could you be off by a level of indirection? Reg 1 contains the address to be used, not the address of a word with the address to be used. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
