×
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 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.
midrange.com
