GAH! I was thinking "Standalone DFSMSdss" any my fingers typed "ICKDSF"
instead.
Depending on when you get the COD, you will IPL one or both from DVD
based on the instructions. But only DSS is necessary now.
John McKown wrote:
On Tue, Oct 4, 2016 at 7:45 AM, R.S. <[email protected]> wrote:
W dniu 2016-10-04 o 14:35, John Eells pisze:
R.S. wrote:
<snip>
The notable exception is z/OS COD - Customized Offering Driver. While it
can be IPL-ed from both DVD and ftp, the next activity is to restore DVD
content to CKD disk and the source has to be DVD.
Actually, you can *install* the COD from DVD, but z/OS itself is IPLed
from CKD disk. Only the copy of Standalone ICKDSF that comes with the COD
is IPLed from the DVD. Also, we do not support Internet delivery for the
COD today.
Yes, IPL from DVD is not COD itself, but ICKDSF.
However I mentioned it just to point it cannot be processed from ftp
directory.
There are at least two reasons why z/OS does not get IPLed from DVD. One
is that even the COD's z/OS subset is too large to fit on a DVD. A full
copy of z/OS, of course, is even larger. The second is that we'd need
significant changes to IPL from the DVD- or another HMC file system-based
IPL process. It might be feasible, but I have not looked at that and
currently do not plan to look at it. It's far below other things on my
personal list of things to make easier.
That's another story. In fact I don't feel the need to IPL z/OS from DVD
or ftp directory (which is solution for DVD space constraint).
If we talking about dreams, I would rather want *some process* which is
DVD/ftp IPL-able and it can restore full z/OS image from the directory. In
other words I don't want to have z/OS IPL-ed from DVD/directory, I want
Installator.
I agree. I can, sort of, envision a process where you could IPL a stand
alone version of ADRDSSUR via the HMC. Then enhance ADRDSSUR so that it
could restore a full disk dump via ftp. I have been known to use ADRDSSUR
to dump a disk to tape, then ftp that tape to a Linux/Intel system using
"stru r" (structure record). I could then ftp that Linux/Intel file back to
z/OS onto another tape (again using STRU R) which would then be readable by
ADRDSSUR to restore the disk image. I have no doubt that it would be at
least _theoretically_ possible to have ADRDSSUR use the FTP API in
Communications Server to do something like this and directly process the
returned records. That is, I'm sure the programmers are smart enough to do
it. But I'm not sure that it would be "cost effective" to IBM.
Which leads to another weird idea. A z/OS subsystem which can use the FTP
API to log on to an FTP server, retrieve a file and present the individual
records to the program as if they had been read from a standard sequential
data set. But I'm going off thread. E.g. something like: //SYSIN DD
SUBSYS=(FTP,"user:password@server","/directory/to/file.txt") would log on
to "server" using the "user" with a "password", then do the equivalent of
"get /directory/to/file.txt". It would return each record to the
application when it read from the file. The main problem that I can think
of is if the application does not read very quickly, which could cause a
"time out" on the server side.
Regards
--
Radoslaw Skorupka
Lodz, Poland
to [email protected] with the message: INFO IBM-MAIN
--
John Eells
IBM Poughkeepsie
[email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
