Re: Three PTF questions

Wrong field name used, as has been pointed out. With proper field
name, there are a paltry 316 PTFs for 5722999.

I did not count PTFs from display screen. Ran to outfile. Left other
parameters as supplied. LICPGM(*ALL) SELECT(*ALL) RLS(*ALL)
COVERONLY(*NO)

The PTFs that are perm applied and indicate on the screen that IPL is
required are for 5722999, as is indicated in the outfile, when proper
field is used.

For both suggested commands, TEXT() is empty.

John McKee

On Mon, Jun 24, 2013 at 11:34 AM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 24 Jun 2013 09:36, John McKee wrote:

1) System has 867 PTFs temporarily applied.

The text of the second question seems to call-into-question that
claim.? Does that 867 reflect a total, having counted those PTFs
displayed at each of the interactive panels successively presented by
having pressed Enter to review the PTFs for each LICPGM?

Since they are already installed, is there any danger of a link
loader issue when they are permanently applied? I am unclear as to
whether the link loader error manifested itself on temporarily or
permanently applying PTFs.

The LL is relevant only to the LIC PTFs. Only those PTFs in\for the
product 57xx999, for the product library identified with\as QGPL, are
processed via the Link Loader. AFaIK any Link Loader space issues
should arise only with the loading and\or temporarily applying of the
PTFs in that product; i.e. if any LL space error occurred during
perm-apply processing in that product, the error message would be a
diagnosis of an existing\prior problem, because permanent application
should only reduce the required space.

<<SNIP>> A bit odd, but there are two PTFs with status of "On order
only".

I am unsure of why that is considered odd, because that is a valid
status. The system is awaiting the order to result in a load of the PTF
into service. The means of effecting that loading, the effective or
explicit LODPTF activity, depends on the delivery method that was chosen
when the order was placed.

2) I did DSPPTF OUTPUT(*OUTFILE) OUTFILE(QTEMP/PTF). The command
has a default of *ALL for Product.

Not that it applies in the scenario, but... there are two positional
parameters and two other parameters, each with a default value. Those
were unspecified, and thus the reader can only assume what that request
might actually effect.

The outfile lists 5722SS1 for every PTF. A DSPPTF to screen shows all
products. I thought this was unusual. Is it?

Seems unexpected from my recollection. The interactive
output-to-display of the Display PTF feature would require Enter be
pressed to see each different product, but output to either spool\print
or to an output file should list everything selected according to the
various parameters on DSPPTF that effect that selection criteria; i.e.
the first four parameters, LICPGM, SELECT, RLS, and COVERONLY. I would
recommend reviewing to ensure the default invocation effects, or the
explicit invocation effects:
DSPPTF LICPGM(*ALL) SELECT(*ALL) RLS(*ALL) COVERONLY(*NO)
OUTPUT(*OUTFILE) OUTFILE(QTEMP/PTF)

I do not recall if the displayed-output interface may ignore the
selection implied by those other parameters; there is no obvious
statement implying a difference, in the newest docs. But if on the
*OUTFILE request, if RLS(V5R4M0) had been specified or defaulted,
instead of RLS(*ALL), then if the installed LIC release is V5R4M5, then
all of the 5722999 PTFs would have been excluded.

Wondering if application of a CUME at some point was relevant.
Former SA was just not "into" PTFs.

I am unsure how to interpret the former comment, but with regard to
the latter, the following emoticon expresses my reaction: :-(

3) For product 5722999 there are four PTFs listed (MH01007,
MH01004, MH01001, and MH00997) with status "Permanently
applied - IPL". All appear to have been applied 1/09/11.
Multiple IPLs have been performed since then.

Are those listed in the Output File, and if so, do they incorrectly
show the "Product ID" as 5722SS1 as alluded in the text of the first
question?

I know only real issue is permanently applying temporarily applied
PTFs before upgrade to clean out old save files.

That action to effect cleanliness is preferable, but not absolutely
necessary. And I am sure there are other _possible issues_ to be
concerned with, beyond just the cleanliness :-)

But, questions 2 and 3 just seem odd.

The more I think on the noted inconsistency in the output of the
displayed vs outfile, I wonder if maybe the effects have an origin from
a common error with improper restore activity against the QUSRSYS library.

If there is any TEXT() for any file or member in any of the following
requests, then there may be an error with the PTF database that needs to
be resolved due to a past usage issue that effectively /corrupted/ the
PTF database:

wrkf qusrsys/qapz*
dspfd qusrsys/qapz* *mbrlist (*) fileatr(*pf)

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.