×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 08-Nov-2011 17:49 , Sam_L wrote:
We're going from V6R1 to V7R1 and part of the post upgrade task list
from prior upgrades is "Check Reply List entries". <<SNIP>>
1) I guess IBM provides a basic set of RPYLEs.
Sequence numbers 10, 20, 30, and 40 for as long as I can remember, to
force the D=Dump default reply for the various HLL default unmonitored
exception inquiry handlers.
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rbam6/ussrl.htm
Do they add many in new releases?
Rarely. I recall one specific to iNav Database [CPA32B2, though with
suspect compare data; presumably processing implemented directly within
the MH Message Handler component] and another for a Performance Monitor
product. Each entry added for a feature of the respective product,
either when installed or when a user has activated the feature which
/requires/ that specific reply override.
2) Is there any easy way to tell which, if any, of the RPYLEs we've
added? (I haven't found any records.)
Good system change management would allow knowing what customizations
were made to a system [and when], and thus which customizations may need
to be made again; e.g. after a DR or upgrade. Scripted requests in a CL
stream can both easily enable tracking\inquiring and effecting a
reapplication of any changes; each recorded as a CL command request.
For example, one of the following would record a system reply list
customization, and could reapply that change after an upgrade or whenever:
/* perhaps record dated comment about why this change exists */
addrpyle seqnbr(3701) msgid(CPA3701) +
rpy(I) dump(*no) ccsid(*hex) cmpdta(*none)
_or_
/* perhaps record dated comment about why this change exists */
rmvrpyle seqnbr(3701) /* more thorough, to ensure full reset */
addrpyle seqnbr(3701) msgid(CPA3701) +
rpy(I) dump(*no) ccsid(*hex) cmpdta(*none)
3) Have you added some/many RPYLEs? Is it a good or bad idea?
I avoid using INQMSGRPY(*SYSRPYL) and thus avoid updates to the
RPYLE. I will continue awaiting a user reply list object type to enable
the use of INQMSGRPY(mylib/myusrrpyl). I would typically use an
alternate message file with a preferred default reply, then run with
inquiry message reply handling of *RQD or *DFT. I considered possibly
implementing an effective *UsrRpyL object using the Reply Handling Exit
Program for Exit Point Name: QIBM_QMH_REPLY_INQ with Exit Point Format
Name: RPYI0100 [Exit program introduced: V5R2], but I figured since the
OS had never stepped-up to provide one, there must have been and remains
too little interest in that capability. That exit can provide an
alternative or an enhancement to the inquiry reply handling
[system-wide], irrespective of origin for the reply; as default,
user-entered, or sysrpyle.
_Ways of handling replies to inquiry messages _
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rbam6/rpyexit.htm
_Using the reply handling exit program_
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rbam6/msghandlereplies.htm
_Reply Handling Exit Program_
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/apis/XREPLY.htm
<<SNIP>>
Regards, Chuck
midrange.com
