On Sat, 3 Jul 2010 11:29:41 -0500, Chase, John wrote:
>>
>> FROMNTS( 'package-ID.gimzip' )
>> //*
>> //SMPNTS DD PATHOPTS=ORDONLY,
>> // PATH='&NTS'
>
>Thanks. Don't know why I didn't think to try specifying the package id
>(subdirectory name) without the ORDER keyword.
>
It might be useful to include a verification DD:
//VERIFY DD PATHOPTS=ORDONLY,
// PATH='&NTS/package-ID.gimzip/GIMPAF.XML'
to cause the step to fail with an allocation error before ever
initiating.
Damm! I wish we had symbol substitution in SYSIN so I could use
the same '&PKGID' in the DD statement (possible) and in the
SMPCNTL (impossible).
> ... the RECEIVE FROMNETWORK runs quite a bit faster with the package
>already downloaded, but our sandbox is severely "knee-capped" and the
>"verification" processing takes nearly an hour for the subject package.
>The previous un-zip stage ran almost 10 hours before filling up the
>single Mod-9 SMPWKDIR filesystem. We'll see how long it takes to fill
>up a two-volume (both Mod-9s) SMPWKDIR filesystem. :-|
>
Is there a ROT relating size-of-SMPWKDIR to size-of-SMPNTS? Factor
of 3, perhaps? It ought to be better than that for RELFILES, since
recent releases of SMP/E load each expanded RELFILE to SMPTLIB with
IEBCOPY and discard it before expanding the next one.
Damm! I wish IEBCOPY would accept a POSIX pipe for its unloaded
input (or output).
Current data flow:
RELFILE.pax.Z
via pax
expanded RELFILE in SMPWKDIR
via SMP/E internal filter
Classic unloaded RELFILE temp DS
via IEBCOPY
RELFILE.SMPTLIB
Where with a redesign of the GIMPAF format and enhancement to
IEBCOPY (SMOP, borderline of trivial) it could be:
RELFILE.Z
via uncompress
POSIX pipe (no DASD storage)
via IEBCOPY
RELFILE.SMPTLIB
-- 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
