Re: the CMPPFM cmd in QPDA is not showing V7R1

On 13 May 2013 07:18, Voris, John wrote:

When I run the CMPPFM command on our V7R1 machine, I am seeing in the
report header a reference to V6R1, not the normal "V7R1" . . . In the
report file QSYSPRT output from the command and CPP pgm QPDA/QUECPP1
" IBM COMPARE V6R1M0 080215 " is at the top of the report

The printer file being used is program-described, so the data written is not from either literal or message text compiled into the PRTF that was updated\re-created for the release. So the data likely comes from either a constant in the code or is derived within the code. I know of one feature for example, that extracted that type of information from the OIR of a program in its product library. The CMPPFM feature may do that. I would review output from the following script of a CL request and an SQL request, for a potential source for the information being presented:

DSPOBJD QPDA/*ALL *ALL *FULL OUTPUT(*OUTFILE) OUTFILE(QTEMP/ODPDA)
;
SELECT ODOBNM, ODOBTP, ODOBAT, ODPPNM, ODPVRM
FROM QTEMP/ODPDA
WHERE ODPVRM<>'V7R1M0'
;

If nothing obvious is found, then seems reasonable enough to report the issue as defect... and then IBM can determine where the information is derived and effect correction.

But running other reports from QPDA, they show V7R1
Example: WRKOBJPDM and F21 to print: In the printfile QPUOPRTF
" 5770WDS V7R1M0 100416 CROWN3 Programming Development Manager - Object list"

That PRTF is created externally described, but instead of some header text having been built into the object, it appears fields are defined in a record format TITLE. Again, the code that writes to the printer file is responsible to obtain the data to be set in the variables that populate those fields [PRODUCT, VRMINFO, RELDATE].

Seeing this raises doubts, and it seems to me to not be a proxy
command problem . . .
So were all QPDA objects refreshed by our operations-team during
their upgrade to V7R1 . . .
or is this just an instance of how disjointed pieces of PDA - now a
frozen legacy product of IBM - will now appear . . .

Use DSPSFWRSC to see the level of the WDS product. When the product was re-created for the release, then the release level will match the OS. When a product is no longer getting refreshed because the product is /decoupled/ from the OS and is thus allowed to /skip ship/ for a release, then the release level will reflect a prior value and be marked with "*COMPATIBLE" [within the list available from GO LICPGM] to indicate the lower-release is compatible on the current\higher OS release. The command CHKPRDOPT can be used against the product to ensure its object levels are properly recognized.