On Sat, 3 Jul 2010 22:35:23 -0500, Chase, John wrote:
>
>The package contains about 3 GiB of product and about 5.5 GiB of
>accumulated maintenance. SMP/E apparently wants to process the
>maintenance first.
>
It needs to process the SMPPTFIN first because the processing of
the RELFILEs is controlled by the SMPPTFIN. There's an ordering
constraint within SMPPTFIN in that dependent functions and maintenance
can be processed only after RECEIVEing the related FMID.
>> >It would be really nice if SMP/E would move the unzipped /SMPPTFIN files
>> >into the SMPPTS and delete them from SMPWKDIR "one at a time" instead of
>> >unzipping them all first.
>>
>> Indeed. But it would be tricky because they must be concatenated.
>> It could be done with POSIX pipes; in fact the code could be RYO,
>> outboard from SMP/E RECEIVE. But the error recovery would be
>> messy.
>
>You lost me there.... Each PTF becomes a separate member in the SMPPTS,
>so "theoretically" the maintenance could as logically be shipped as a
>bazillion files each containing a single PTF, as a single file
>containing a bazillion PTFs. The KISS principle should intersect
>economies of scale somewhere in between.
>
On thinking further, I agree. SMOP. But classic SMP/E RECEIVE
processes one SMPPTFIN, not a bazillion files, and I suspect the
design of RECEIVE FROMN{ETWORK|TS} was guided by a desire to make
the minimal change to core RECEIVE processing.
I've tried this as POC with the existing SMP/E. At a value of about
bazillion=1000, SMP/E crashes on exceeding a cantenation limit in
DYNALLOC. And the existing SMP/E RECEIVE design provides no
reduction in the SMPWKDIR storage requirement.
As I said, I could do about what you suggest using existing SMP/E
and allocating SMPPTFIN to a [named] pipe. I have no intention to
suggest making this a product. Program Managment would conclude
it would incur the same customer doubt as CA MSM, and for far less
perceived benefit to the customer, and they'd be right. And that
we haven't the resource to maintain it, and they'd be right.
>In the Shopz package it appears that each component has its own SMPPTFIN
>file(s), some of which are rather gargantuan (ca. 2 GiB).
>
That's 35% of your stated 5.5 GB, so serial processing would present
a factor of 2.75 reduction in SMPWKDIR storage requirement; not to
be dismissed lightly.
To verify my "factor of 3" guess, I tried as a statistically significant
and unbiased sample of one data point the largest PTF we have around:
$ wc PTF.pax.Z
81566 588786 14415605 PTF.pax.Z
$ zcat PTF.pax.Z | pax -v
USTAR format archive
drwxr-xr-x 0 user scm Mar 31 2009 .
-rw-r--r-- 0 user scm 1440 Mar 31 2009 ./GIMFAF.XML
-rw-r--r-- 0 user scm 33548960 Mar 31 2009 ./SMPPTFIN
$
$ awk 'BEGIN { print 33548960 / 14415605 } END'
2.32727
OK. Factor of 2.3 for compression. Compressing but not paxing the
SMPPTFIN and leaving the GIMFAF.XML file elsewhere would allow direct
piping into SMP/E RECEIVE without first extracting to a file. Is
there a way to trick pax into extracting a selected file to a pipe?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
