I don't quite understand You:
====== Paul Gilmartin ====== wrote 2005-10-22 17:28:
In a recent note, Edward E. Jaffe said:
Date: Fri, 21 Oct 2005 09:56:06 -0700
Sounds like I'm in the minority here, but I like the approach of using
EDIT for basic editing in the environment you've described. EDIT is
simple, doesn't require a slew of pre-allocated data sets [whose names
will vary from site to site], and is guaranteed available.
A few months ago, there was a thread (I think in MVS-OE, but perhaps
here) about whether software products should be installed in data
sets named according to the ISV's conventions, or according to the
customers' conventions. The majority view seemed to favor the
customers' conventions, with the rationale, "Well, each shop must
enforce its own [idiosyncratic] standards, else its users would never
be able to find any ISV products." I took the minority view, for
which you have hinted at a strong argument: portability of JCL and
programmer skills.
And by that you mean.... ?
I also argued that if a site installs according to local naming
conventions, data set names in documentation will consequently
be wrong. The rebuttal was, "Documentation is [almost] all
electronic nowadays; it's easy enough to run a filter (which the
vendor supplies?) to modify data set names in the documentation
to match the site's conventions." This seems nonsensical to me.
What, then of supplementary documentation online, via the vendor's
web site? A CGI script to filter that on the fly, with the site's
prefixing conventions stored in the users' cookie jars? KISS?
Of course, the vendor should support installation with alternate
data set names for beta releases, PTF test platforms, etc.
And when they do not have that prepared ?
But
the customer is still well advised to install production versions
according to the vendor's convention.
Consider the extreme: the customer should be allowed to use a
locally chosen HLQ, if he chooses, instead of SYS1, and a JCL
INCLUDE member:
// SET IBMHLQ='SYS1' * Season to taste
...
//SYSLIB DD DISP=SHR,DSN=&IBMHLQ..MACLIB
... Again, nonsense. (Or has this already been done, for beta
testing support?)
And how do You solve the situation when the vendor have their own macros they want to have in maclib (and doesn't supply their own lib) that overwrites previously existing macors (if we would choose
to install as instrucyed) ?
Or when you have several different version that You had to use/have installed
in parallel ?
BTW, are you aware that sometimes vendors have install JCL that uses their own invented HLQ, say
like "SILLY.MACLIB" or "OUR.OWN.LINKLIB" etc.
-- gil
AFAICS, with the principle I think You propagate above and as the only common
name standard in Z/OS shops is the SYS1/SYS2-convention plus IBM's all product
HLQ's,
this will led to a situation where all ISV's would overlay each others (and our own) components in the SYSx-libs plus a myriad of ISV-HLQs. The latter will be an administrative nightmare when you had
to operate and integrate these in the production.
--
--------------------------
Mundus Vult Decipi
--------------------------
They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety.
- Benjamin Franklin
----------------------------------------------------------------------
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
