Well, the exit was not the problem. The Monitor function was
being set in COMMND00 using a "MN JOBNAMES,T" command. With z/OS 1.9,
this comes from console 0 (since the L= option was not used) and errors
out with CNZ0005I message, so it was not set initially. Later, a sysprog
entered "/MN JOBNAMES,T" from a SDSF session. This set the function on
the EMCS console created for that command. When he logged off, the EMCS
console went offline, and the Monitor function was dropped. They went
through several iterations of this, with the function going on and off,
so it appeared that the MPF exit might be the culprit. Later, trying to
schedule a recurring job to set the Monitor function as a workaround,
they used the L=<consolename> parameter, which set the function for a
console that was not going offline...this was about the same time as
they refreshed my reassembled exit. They are going to update the
COMMND00 member to use the SETCON command instead of MN for the next
IPL.
This was a good exercise, I learned more than I ever wanted to
know about MVS console handling!
Again, many thanks for your inputs.
George Sproull
DECC Mechanicsburg GS4B14
DSN 430-3525 Comm (717) 605-3525
Cell (717) 773-3781
[EMAIL PROTECTED]
-----Original Message-----
From: Sproull, George CTR DISA GS4B14
Sent: Friday, May 30, 2008 10:46
To: IBM Mainframe Assembler List
Subject: RE: Re: MPF Exit Code Mystery
Thanks for the inputs. The old module was AMODE 31 RMODE ANY just like
the new module. Kevin's mail got me to start digging a little more. I
tried invoking the old exit on a 1.7 test LPAR, and the IEF403E messages
continued to come out. I was not the only one working on the problem, so
I now suspect "somebody else" was doing "something" that both broke and
fixed the messages. I am currently reviewing the logs to try to solve
it, I'll let you know the outcome!
George Sproull
DECC Mechanicsburg GS4B14
DSN 430-3525 Comm (717) 605-3525
Cell (717) 773-3781
[EMAIL PROTECTED]
-----Original Message-----
From: IBM Mainframe Assembler List
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Schmidt
Sent: Thursday, May 29, 2008 13:17
To: [EMAIL PROTECTED]
Subject: Re: MPF Exit Code Mystery
On Wed, 28 May 2008 16:05:02 -0400, Sproull, George CTR DISA GS4B14
wrote:
>Hi,
> We run a simple MPF exit specified in MPFLST00 that sets a
>couple of bits in the CTXT DSECT pointed to by R1 at entrance. We also
>include COM='MN JOBNAMES,T' in COMMND00 to require that the IEF403I
>message is produced at job startup (required by our job scheduler).
>Everything worked fine until we upgraded from z/OS 1.7 to 1.9, at which
>point an invocation of the exit would turn off the JOBNAMES switch and
>the IEF403I message would stop. We could reset it manually, but the
>exit would again turn it off. OK....so the CTXT DSECT in IEZVX100 (the
>only DSECT in the code) must have changed and we are setting bits
>dealing with JOBNAMES. I reassembled it, refreshed the link list, etc.
>and the problem went away....good! However, trying to understand the
>problem, I looked at the differences of the DSECT between z/OS 1.7 and
>1.9 and there were indeed flags added dealing with JOBNAMES monitoring,
>but the displacement within the control block of the bits we were
>setting had not changed. So, being a short program, I compared the
>reassembled load module with the 1999 load module that had been causing
>the problem, and, except for differences in the load module headers
>(assembler version, link date, etc), the code was EXACTLY THE SAME.
>What am I missing? I know it is normal practice to reassemble exits
>with OS upgrades, but I can't see how doing it in this case fixed the
problem.
>Is it more likely that reloading the module fixed a corrupted module in
>core?
>
>Here is the entire source:
>
>STM R14,R12,12(R13) SAVE CALLERS REGS
>BASR R12,0 ESTABLISH MODULE BASE
>USING *,R12 REGISTER
>L R5,0(R1) ESTABLISH ADDRESSABILITY
>USING CTXT,R5 TO THE CTXT
>OI CTXTRFB2,CTXTRDTM NO HARDCOPY/NO DISPLAY
>OI CTXTERF3,CTXTESJL SUPPRESS FROM JOBLOG
>OI CTXTERF3,CTXTNWTP SUPPRESS FROM WTP
>LM R14,R12,12(R13) RESTORE CALLERS REGISTERS
>BR R14 RETURN TO CALLER
>IEZVX100
Hi George,
What were the old load module's AMODE/RMODE settings? What was the
AMODE + RMODE for your newly assembled module?
The z/OS 1.9 Installation Exits pub says that it should be AMODE=31 /
RMODE=ANY. Perhaps your old module was AMODE=24 and somewhere between
then and now the data structure was moved above the line?
--
Tom Schmidt
----------------------------------------------------------------------
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
