Re: CPF1241. Additional job completion data

On 02 Nov 2012 07:42, rob@xxxxxxxxx wrote:

DSPOBJD OBJ(QCPFMSG) OBJTYPE(*MSGF) DETAIL(*SERVICE)
doesn't log anything at
Licensed program . . . . . . . . . . : 5770SS1 V7R1M0
PTF number . . . . . . . . . . . . . :
APAR ID . . . . . . . . . . . . . . :

*BASIC shows this:
Change date/time . . . . . . . . . . : 09/08/12 08:32:29

Which just happens to be the date we put on a bunch of group PTFs
and IPL'd.

FWiW the message description itself has a date [and revision level of some sort]; i.e. the "Message level" as shown on DSPMSGD output.

A search of PTF cover letters for QCPFMSG was fruitless also.

Per the blank "PTF number" in the Service OIR data, no PTF included a replacement message file object; i.e. the *MSGF QCPFMSG was not shipped as an object, as part of any PTF. Even so, the actual "objects" as part of a PTF are not documented [within the search-enabled APAR\PTF database], and thus not directly able to be searched. If the object name is relevant beyond its inclusion as an object being replaced, one can only hope that the object name would appear as a token in the text of the APAR\PTF because the developer had decided that detail was worthwhile as a search\symptom keyword.

Presumably the update was provided via a CHGMSGD request [performed in a PTF exit program], so the Message Identifier itself would be a better choice for searching. Though as with many APAR\PTF, the most obvious and\or appropriate search [symptom] keywords are often not included :-( Inhibits the ability to learn if there are equivalent secondary language PTFs or if the /user/ is expected to take some specific action against all secondary language versions of the message file and if for those already installed and\or those installed later.

<<SNIP>>