On 2015-05-11 09:43, R.S. wrote:
> Regarding software products, can I live without tape? Yes, definitely. Would
> I like it? No.
>
> I use tape as an installation medium only for ServerPacs (z/OS and DB2, and
> CICS, and NCP in the past).
> Other stuff like IBM CBPDO or ISV products come to me via Internet or via DVD
> (for ISV's which do not offer Internet download).
>
> Now, why I use tapes for ServerPac.
> A couple of reasons:
> * Software download is cumbersome, especially for big downloads. I want to
> have packing list, MEMOEXT, basic documentation (Installation Directiories)
> and some "ISO data". It is much easier to get in in the box. Note, the same
> advantage exists for non-tape physical medium (DVD). Note, the bigger problem
> exists for non-z/OS code add-ons like documentation or ISO images (CD, DVD).
>
For multiple volumes, there's no solution. Except it would be
great if z/OS could employ the optical drive in the HMC, as I've
been told z/Linux and z/VM do. Or even a USB-attached drive from
Best Buy.
> * SMP/E and "pre-SMP/E" procedures for software installation. You have to
> upload (or download directly) the package to the host - that mean huge HFS
> container. Then you have to unpack it (can be combined with next step),
> RECEIVE it, then start SMP/E installation. A lot of DASD space is consumed.
>
(See wild ideas below.)
> Compare it to ServerPac procedure: two jobs. ALLOCDS creates empty datasets,
> next job reads the tape(s) and copies fills the libraries. No DASD needed for
> "tape content".
>
How many job steps? I suppose ALLOCDS could be a single IDCAMS step, and the
next job a single GIMSMP step that has a lot of UCLIN for DDDEFS, UTILITYs,
etc. Would customers prefer to separate these operations and review return
codes before proceeding? Well, not if it's guaranteed to work the first time.
> * Procedures. Both CBPDO and ServerPac assume tape as medium.
>
This may be even worse from the ISV's perspective. Does the Packaging
manual describe the conventions for Optical Disk and Internet Delivery?
It used to describe only tape. Where is the Packaging manual on Knowledge
Center?
> * Lack of scripts. When I get DVD or Internet-downloaded files I have to
> upload it to the host manually. It would be nice to insert first DVD into the
> drive run some application - some ftp frontend, choose some simple options
> like HFS directory, IP (kept for next uses) and start copying+restoring.
>
In times of eld, we delivered a CD burned from a .iso image that contained
both a .pax image of a SMPNTS and the same, unpaxed (small product; ample
space on CD). I could mount that CD on either a Solaris or an OS X system
and do RECEIVE FROMNETWORK. Or transfer the .pax; extract it; and do
RECEIVE FROMNTS. After two corporate acquisitions, Company Policy dictates
that every Internet deliverable be a .zip file, and every optical medium
contain that .zip file. We suffer no constraints concerning the payload;
it's still the .pax image of the SMPNTS. And I can expand it with one[1]
command[2]:
unzip -p $PROD.zip $PROD.pax |
ssh -X $MVS_USER@$MVS_HOST "set -x
cd /tmp/\$LOGNAME &&
mkdir -p SMPNTS &&
cd SMPNTS &&
iconv -f IBM-1047 -t ISO8859-1 | # I hate EBCDIC!
pax -vr &&
ls -al"
Would any user find value in having the un-paxed SMPNTS in the .zip
in order to do RECEIVE FROMNETWORK? None of our testers chose to do
it that way.
Long ago, a contributor to this forum suggested a paradigm of "The
great SMPNTS in the [Cloud]". No RECEIVE would be needed; the customer
could proceed directly to APPLY which would treat the Cloud as an
extension of GLOBAL. And storage requirements would greatly reduced.
John should suggest this to Kurt. They could have a good laugh over
it (but I won't buy the needed beer).
Further, IEBCOPY should be enhanced to support either z/FS file or
Internet stream as PDSU, further reducing temporary storage need.
(All with robust recovery/restart facility, of course.)
[1] FSVO "one".
[2] Presuming the installer has Info-Zip. But that's "The Third Most
Portable Program in the World!"
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
