Re: SMP/E packaging for RECEIVE ORDER?
- From: gilmap@xxxxxxxxxxxx
- Date: 7 Mar 2007 09:03:01 -0800
Setting Reply-to: -- I'll summarize and attribute replies, if any.
In a recent note, Kurt Quackenbush said:
Date: Wed, 7 Mar 2007 11:08:03 -0500Always doing feasibility studies; how can we better serve our customers?
The format of the downloadable files is the same for RECEIVE FROMNET and
RECEIVE ORDER. That is, both expect to handle GIMZIP format packages.
However, I'm curious why you ask such a question. Do you hope to
implement your own Automated Delivery Request server which SMP/E RECEIVE
ORDER can communicate with and request your PTFs?
And I note in this list perceptible enthusiasm for ShopZ, which I think
embraces RECEIVE ORDER, but little enthusiasm for RECEIVE FROMNETWORK.
And:
Date: Wed, 7 Mar 2007 11:15:04 -0500Do customers in any substantial number download directly to z/OS? My
Subject: Download z/OS software protocols (was SMP/E packaging for RECEIVE
ORDER?)
Utilization and support of FTP are generally waning outside IBM.
Really? Why? If not FTP, then what is the desired method for
downloading products, PTFs, and HOLDDATA directly to a z/OS system from
an Internet server?
perception is they download to desktops and FTP/Samba/IND$FILE to
z/OS.
Survey question: What do you do?
1. Download directly to z/OS
a. FTP (what client?)
b. Other (specify)
2. Download to desktop, and then to z/OS:
a. FTP
b. Samba
c. IND$FILE
d. NFS
e. Other (specify)
3. RECEIVE FROMNETWORK
4. RECEIVE ORDER
5. Tape.
HTTP(S) Rules the Universe! Many sites are idling down their FTP
support while FTP flourishes. I can think of a couple reasons, good
but not overpowering:
o The specification of FTP is incomplete in that it doesn't define the
format of the replies to the LIST and NLST commands, making automated
navigation of FTP sites difficult for clients, which must implement
parsers for the reply formats of all supported servers. I suspect
many readers of this list felt frustration at FTP clients that can't
navigate z/OS sites because they expect replies in the format of the
UNIX "ls" command.
o The security features of HTTPS.
Why did IBM choose to use HTTPS for RECEIVE ORDER rather than staying with
a uniform FTP protocol?
If there were a suitable HTTP(S) client on z/OS, or if SMP/E extendedIt's admittedly a supplier-side issue. As infrastructure support for FTP
its current client (today used soley for communications with the
Automated Delivery Request server during RECEIVE ORDER processing),
would that fare better than FTP? If so, why?
servers dwindles, vendor engineering departments that would like to provide
IBM formats confront IS departments that say, "We'll only support HTTPS;
why can't you use that?"
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.
- Follow-Ups:
- Re: SMP/E packaging for RECEIVE ORDER?
- From: Kurt Quackenbush
- Re: SMP/E packaging for RECEIVE ORDER?
- From: Shane
- RE: SMP/E packaging for RECEIVE ORDER?
- From: Veilleux, Jon L
- Re: SMP/E packaging for RECEIVE ORDER?
- Prev by Date: Looking for ideas on remote system
- Next by Date: RE: Looking for ideas on remote system
- Previous by thread: RE: SMP/E packaging for RECEIVE ORDER?
- Next by thread: RE: SMP/E packaging for RECEIVE ORDER?
- Index(es):
Relevant Pages
|
