MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » August 2014

Re: Attempting to remove message CPI2201 from joblog



fixed

On 31-Jul-2014 09:51 -0500, John Allen wrote:
We have a long running job that generates unnecessary
messages in the joblog.

So I am starting at the top and working my way through the
program and removing as many unnecessary messages from the
joblog as possible.

The program issues a

GRTOBJAUT OBJ(QTEMP/WORKFILEA) OBJTYPE(*FILE) USER(*PUBLIC)
AUT(*ALL)

Side note: Unless that work file is /moved/ into a permanent library, that Grant Object Authority work is often for naught; i.e. the objects in the library QTEMP would not require any authorizations to be added outside of those for the group\owner, mostly because *PUBLIC will rarely have the opportunity or even ability [irrespective of authority] to access the object in the temporary library for the job. Of course, perhaps the example is contrived and not representative of the work more generally, or the job will be operating under a switched user that either is not known until later or can not be known in advance, to whom authority might be granted specifically.

This generates 2 messages in the joblog:

CPI2201 "Authority given to user *PUBLIC for object WORKFILEA in
QTEMP object type *FILE."

Notably, the program [message queue] to which that informational message CPI2201 was sent, is *not* the CL program issuing the Grant request. That is the origin for the difficulty. The program QSYGRAUT to which the message was sent, is no longer active on the stack, thus the Program Message Queue (PGMQ) of the system program QSYGRAUT is no longer accessible to the CL program that requested the GRTOBJAUT; that message is no longer addressable to any program by a _combination of_ both the named Program Message Queue and the specified Message Type. Note: The message is available by the Message Key, irrespective of the Program Message Queue; learning the value of the message-key is another story.

CPC2201 "Object authority granted."

Notably, the program [message queue] to which that completion message CPC2201 was sent, *is* the CL program issuing the Grant request. That is the reason the message _can be_ accessed; the program message queue where the message is located is the PGMQ() of that currently active program, and that program message queue is identified with the special value *SAME on RCVMSG and RMVMSG.

Note: The F9=Display Message Details after F1=Help is chosen against a Message appearing in an [inter]active joblog will show to which program a message was sent, thus enabling learning whether the message will be available to the program that made the request for which the message was logged. The spooled joblog will also reveal that same information.


Immediately after the GRTOBJAUT there is

CALL PGM(QMHRMVPM) PARM('*' 0 ' ' '*NEW' ' ')
CALL PGM(QMHRMVPM) PARM('*' 0 ' ' '*NEW' ' ')

Warnings about the above CALL requests: the parameter definitions [documented for the API] do not match the data types of the data being passed [as literals] in the corresponding arguments.
<http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/apis/QMHRCVPM.htm>

Warning 1: The 5th argument incorrectly informs the API that there is an unbelievably large amount of storage available in which to return exception data; i.e. the INPUT portion for the Error Code suggests that there were x'40404040' Bytes provided for the OUTPUT portion of that parameter; when in fact, a literal specification provides implicitly only 32-bytes of reserved storage, although as a literal, effectively there is no storage provided for return data per the parameter being inherently input-only to the invoked program.

Warning 2: The 2nd parameter is functional, albeit deceptively, and possibly only accidentally. Although the decimal value zero [shown as the digit 0 for the second argument in the above CALL requests] will be understood by the API to be the value x'00000000', the actual value being passed to the API for that parameter would actually be the value x'000000000000000F', the value of the PackedDecimal(15,5) with value of zero. However, purposely coding in that manner to both coincidentally and somewhat deceptively achieve that effect, is discouraged. Another programmer who does not understand how that result is achieved only with subterfuge might /copy/ that line of code, and then deciding a relative call stack entry should be /one/ for their purposes, they may think simply changing the decimal digit zero to the decimal digit one will suffice, but of course that change would do nothing; any of the legitimate possible _decimal values_ that would be functional [beyond the zero-value] would be nonsensical as compared with an appropriately specified binary\integer value, per having to increment by (N*100) instead of just increment solely by (N) to direct the API to the Nth relative Call Stack Entry.

Additionally, the '*NEW' specification is a generic, such that *if* the invocation was able to do what was desired, then only one invocation would be required. That is because after the first invocation, there would be no _new_ messages; well, unless the API was both allowed to and did, issue new message(s) to that call stack entry.


These two calls only remove message CPC2201 from the joblog,
message CPI2201 remains in the joblog


Although not a helpful response, the effect is proper and expected, given what the messaging effects were from the request, with regards to where the messages are stored and how those messages are located. The appropriate /corrections/ to the API invocation [those alluded earlier] would not change that effect. The invocation removed the /new/ message from the specified program message queue, as requested.

The special value '*' [asterisk] as the first argument indicates that the Program Message Queue (PGMQ) to be processed is the currently active program; "The message queue of the current call stack entry (that is, the call stack entry removing the messages)." The value of zero as the second argument indicates the relative offset from the currently active program identified by the first argument; "Remove the messages from the message queue of the call stack entry specified in the Call stack entry parameter." Any value specified for the fourth parameter except '*BYKEY' [which is a request to operate on the key specified in the third parameter] can act only against "messages in the call message queue"; together, the specifications in the first two arguments ask the API to process only the messages located within the program message queue of the active program as the requester of the Remove Message API. But because [as noted earlier] the Information message CPC2201 is not in [was not sent to] the program message queue of that active program [which is where the API was asked to look, per the combination of values specified for the 1st and 2nd arguments], the info message can not be accessed using that invocation of the Remove Program Message API.

Note: The duplicate API invocations are effectively the equivalent of:
RMVMSG PGMQ(*SAME (*)) MSGQ(*PGMQ) CLEAR(*NEW) MSGKEY(*N)

FWiW, while the value '*NEW' that was specified for the 4th argument signifies in terms of IBM i messaging the equivalent of not "*OLD" whereby '*OLD' signifies "already received\processed", and although the message CPI2201 was never _received_ such that the message should remain "*NEW", because the informational message is not in an\the active program message queue, the info msg is not available to a request to process the active program message queue PGMQ(*SAME (*)). For the same reason, the specification of CLEAR(*ALL) also would not assist to remove those info messages.

If the system program QSYGRAUT had sent [or moved] the informational message(s) to the invoker of the GRTOBJAUT, then the RMVMSG [or RCVMSG] or equivalent API invocation would have had little difficulty removing those messages along with the completion messages. Unfortunately there is no parameter [nor an environment variable or anything else] that can be specified to influence\persuade the Grant request to /move/ those messages to the PGMQ of the requester :-( Nothing that I am aware of is available, that would force the informational messages to be available [sent or moved] directly to the invoker, rather than being left in an inactive program message queue.


I tried replacing the two calls to QMHRMVPM with

RCVMSG MSGTYPE(*LAST) RMV(*YES)
RCVMSG MSGTYPE(*LAST) RMV(*YES)

With the same results

FWiW: For a replacement, the command Remove Message (RMVMSG) might be expected instead, as described earlier; i.e. use of Receive Message (RCVMSG) as an effective /replacement/ for an API call might be considered more likely, had the previous API invocation been to the Receive Program Message (QMHRCVPM) API.

No matter, the /same results/ [though actually they may not have been] is of no surprise, because the PGMQ(*SAME (*)) [as the default for RCVMSG (and RMVMSG)] has the same effects and limitations as the '*' and zero specifications on the Remove Message API [or similar RMVMSG request].

As with the API invocations shown, the duplicate RCVMSG requests are also suspect. In this case however, they are a potential issue; as contrasted with being simply redundancy of a generic request for the two API requests, the two RCVMSG requests might cause problems. Those two CL command requests performed consecutively will either remove two messages [the completion and some prior message] or remove just the completion msg such that the second invocation would receive no message. For lack of any return values [esp. on the second request], what or if a message was returned can not be easily determined within the CL program. Having included a parameter specification like KEYVAR(&RTNKEY), the condition of (&RTNKEY *EQ ' ') indicates that no message was found using the specified criteria to locate a message; having included a parameter specification like MSGID(&MID), the value of &MID could be reviewed [in testing] to determine if the expected message identifier was being received.

What needs to be done to remove the message CPI2201 from the
joblog?


The typical resolution is to use the technique [for which an example is provided in the documentation] to /remove inactive messages/ from the job message queue. Various searches for such terms in the archives should reveal many past discussions with alternate examples and the link to the docs. On a second try, but I do not recall the search tokens, I finally found the KnowledgeCenter link:
<http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/rbam6/rcvmsgpgm.htm>


FWiW: The Remove Program Messages (QMHRMVPM) API does enable removing /all/ of the /inactive/ messages. The /scope/ for the definition of /all/ however, is comprehensive; i.e. all of the messages within the entire _job message queue_ will be removed, not just those inactive since some particular request\invocation or some message key. I do not recall ever using that invocation in my code due to the effects being so drastic; instead I have found usefulness only in the technique of obtaining a message key and then looping to remove successive messages by key, to remove the inactive messages since a particular message key.

There are probably few scenarios whereby the extreme effect of removing _all inactive messages_ from the job message queue will be desirable. Nonetheless, here is a simple CL invocation using the Remove Message API [with appropriately data typed literal values for the arguments, matched to the parameter definitions; though CLP variables often are good\better choices for passing the values]:

call qsys/qmhrmvpm ('*ALLINACT ' x'00000000' +
' ' '*ALL ' x'0000000800000000')

What should be the equivalent request, and much simpler coded within a CLP, is the following Remove Message (RMVMSG) request:

rmvmsg pgmq(*allinact) msgq(*pgmq) clear(*all)






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact