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.
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.
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.
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.
DSPPTFAPYI only shows the 5 PTFs I ordered plus a pre-req, SI58278.
DSPPTF? Perhaps a typo?
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.
I would have looked at the SNDPTFORD command in KnowledgeCenter, but
as usual, typing the command in the search bar yields everything except
the command [syntax] in the first 20 results :-(
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.
midrange.com
