Re: 7.2 Python PTFs FYI

On 1/11/2016 3:53 PM, CRPence wrote:

On 11-Jan-2016 12:48 -0700, Buck Calabro wrote:

The developerWorks wiki for Python has a new page for Python PTFs:
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/IBM%20i%20Technology%20Updates/page/Python%20PTFs

I see that there are some new ones, SI58191 - SI58195. So I ordered
them:
SNDPTFORD PTFID((SI58191) (SI58192) (SI58193) (SI58194) (SI58195))

I was a bit surprised when I saw what looked like hundreds of PTFs
for V7R1M0 to be pulled down. When the SNDPTFORD had completed, I
counted the *SAVF objects which have V7R1M0 in the description and
there are more than 600 of them!

The options defaulted for the Send PTF Order (SNDPTFORD) request
included /requisite processing/. Two of the PTF Identifiers specified
have /distribution requisites/ (DIST-REQ) included as requisites, for
which /ordering/ [with requisites included] will _deliver_ those
other\additional PTFs.

They sure did.

The /distribution requisite/ is a designation that allows for
requested orders to deliver additional PTFs for whatever reason:
• in the worst case they could denote requisites that were accidentally
omitted from original requisites for which the PTF would have to be
repackaged or [marked defective and] superseded to correct the
condition; otherwise more likely one of the others:
• to denote effective pre-requisite or co-requisite across features for
which there is no ability to enforce that requisite processing
• to denote PTFs that are perceptibly related, but for which no actual
PTF changes are required to effect the specific fix for the ordered PTF
being ordered is corrected; yet without the additional fixes, the
_related_ functions might not seem to work, or at least as best they
should.

Thank you for explaining that; this makes perfect sense.

In the specific scenario described in the OP, the PTF SI58191 has the
two IBM i 7.1 OS DIST-REQ PTFs SI57014 and SI57015 that deliver some
Database support and the PTF SI58194 has the one IBM i 7.1 OS DIST-REQ
PTFs SI56645 that delivers some SSL support. Likely there is something
about what was provided with the [specific or superseded] PYTHON support
that sufficiently ties-in with that Database and SSL support, such that
the development teams decided all those fixes being delivered together
would provide the best chance of everything necessary to perform
everything available from that fix-level of the PYTHON; i.e. perhaps
some Database [e.g. DB2 SQL /services/] feature and\or SSL support at
the lower fix-levels than what was delivered with the DIST-REQ PTFs
might be perceived as a defect by the user when missing or might instead
result in /not supported/ messaging due to that missing support.

Yes, that is easy to understand. And of course, once those 7.1 PTFs get
added in to the order, all of /their/ pre-requisites need to be added
and so on. Ending up with many hundreds of useless 7.1 PTFs on a 7.2 system

The issue for the R110 5733OPS appears to compound the above, per
being supported on both R710 and R720 of the IBM i OS; i.e. requisites
[pre and dist] must name both versions of the OS vs merely one OS to
ensure that the OPS feature is updated correctly for whichever release.

I guess I'll go update the wiki to let someone else know what they're
getting into.

DSPPTFAPYI only shows the 5 PTFs I ordered plus a pre-req, SI58278.

DSPPTF? Perhaps a typo?

On my 7.2 machine I can do this:
dspptfapyi
All selected PTFs are already applied.

Display PTF Apply Information (DSPPTFAPYI)

Type choices, press Enter.

Product . . . . . . . . . . . . LICPGM *ALL
PTF numbers to select . . . . . SELECT *NOTAPY
+ for more values
PTF group . . . . . . . . . . . PTFGRP *NONE

Release . . . . . . . . . . . . RLS *ONLY
Output . . . . . . . . . . . . . OUTPUT *

LODPTF and APYPTF seemed to go fine. So I deleted all those 7.1 save
files. There were some for 5770-999, 5770-SS1, 5770-SC1, and
5770-SC1.

The LPAR seems fine but it sure is curious that it downloaded all
that 7.1 stuff.

I seem to recall there being an option on the ordering [Service
attributes and\or Send PTF Order (SNDPTFORD) itself] to override the
requisite processing so as to ask that the order include requisites only
for products that are actually *installed* [on the ordering-from system,
for which requisite ordering-resolution is being conducted]. Specify
that option, if exists\found [as a parameter of the order command or
elsewhere]; doing that should prevent having to delete stuff
after-the-fact, because they should have have gotten ordered.

CHECK(*YES) - Thanks Paul.

CALL QP2TERM, python3 --version responds with 'Python 3.4.2', which
is exactly the same as the LPAR without those PTFs so I'm not sure I
really got anything accomplished.

I guess I would not see that as very surprising; I expect the Python
code being delivered remains the same version, but with some fixes to
make that version operate as expected on IBM i. That is, there is a
standard version of Python, and the fixes from IBM i to make that
version functional on IBM i, can be completely separate from the fixes
to the Python source that would have changed the standard version and
thus the versioning numbers.

That's what I was most afraid of.