Re: OVRPRTF to PDF

As with the original issue for which a review of the spooled joblog was suggested for the failing request, the same recommendation applies to the joblog of the CHKPRDOPT for the apparent non-failing request. In this case, review all of the data\messages immediately following the start of the CHKPRDOPT request message until the final logged message CPC0C20 "No errors detected by CHKPRDOPT." Was there a prior CPI0C28 logged?

As was noted in the archive message link, the CHKPRDOPT can complete without any apparent /error/ [i.e. no Escape message], yet the logged details might imply the product is not installed; e.g. see my comment that 'The logged diagnostic preceding the completion\indication of "no errors" suggests that the "product loads" of the LPP option are "only defined".' In that archived message the apparent effect of the CHKPRDOPT was to *first* log diagnostic CPI0C28 "All product loads checked are only defined." before concluding that the product was not in-error. That message further states in its "Cause" that "No previous messages were sent because DETAIL(*BASIC) was specified on the Check Product Option (CHKPRDOPT) command. Each product load that was checked is not installed." The output described as presented by the WRKLICINF request seems to confirm that the product is *not installed* just like the Check Product Options may have revealed.

Note: If actual message identifiers were included in the discussions, e.g. if the linked\archived message had included the message identifier for the "Required product option not available.", then finding similar discussions involving that same issue are much simpler and can effect much more encompassing results. Searching only on the English text of the message for example, will assist to locate a prior incident for which the same English text had been recorded, but excludes incidents encountered in other languages [installed on the server]... even if those discussions had actually been conducted in English. The actual spooled joblog for a LOG(4 0 *SECLVL) will contain those message identifiers and all of the text, *plus* the /context/ of each message is included, thus likely identifying what was the request and which programs\procedures communicated those messages.

So FWiW, perhaps there is some value in documenting what was the message identifier which was described only with the effective text "product 5761TS1 option 01 is not available.", as described in the message quoted below; like should have been done for the text "Required product option not available." as shown in the archived message.

Regards, Chuck

On 25 Jun 2013 12:01, PHIL_SATTLER@xxxxxxxxxxxxxx wrote:

I ran the job log. It says that product 5761TS1 option 01 is not
available. Yet when I take the command CHKPRDOPT, it says "No
errors detected by CHKPRDOPT." When I display installed licensed
programs, I don't see it.

I need to check this out. Thank you for your help.

CRPence on 06/25/2013 12:04 wrote:

<<SNIP>>
Issue a DSPJOBLOG OUTPUT(*PRINT) and then review all of the
spooled data\messages immediately following the start of the
failing request message until the logged CPF4182.

For possible reference, for whatever is likely to be determined
to be the preceding [diagnostic] message(s):
http://archive.midrange.com/midrange-l/201101/msg00110.html
<<SNIP>>