Re: Consistent Data Set Names (Was: Workable Debuggers ...)
Edward Jaffe wrote:
snip
However, when I experimented with this a while back, I found that it
worked as expected only when the HLQs of the base name and alias were
the same -- or more precisely -- expected to be in the same catalog.
I believe both the alias entry and the related object must be in the
same catalog for data set aliasing to work.
I created a file called 'MYUID.BASE' and used SYMBOLICRELATE to create
'SYS1.ALIAS.OF.BASE'. In my environment, data sets starting with MYUID
are cataloged in a user catalog. Data sets starting with SYS1 are
cataloged in the master catalog. Try as I might, I could not figure out
how to get the system to see 'SYS1.ALIAS.OF.BASE' as an alias of
'MYUID.BASE'. (Perhaps I overlooked something.)
I think this is because you did not place the entry for
SYS1.ALIAS.OF.BASE in the usercat, but I don't have a system to test
that assumption on these days. You might try:
DEFINE -
NONVSAM( -
NAME('MYUID.BASE') -
VOLUMES(volser) -
UNIT(3390)) -
CATALOG('usercat.with.myuid.in.it')
DEFINE -
ALIAS( -
NAME(SYS1.ALIAS.OF.BASE) -
RELATE(MYUID.BASE)) -
CATALOG('usercat.with.myuid.in.it').
Omitting the CATALOG keyword will try to place the alias entry in the
master catalog, and I think you'll see a message that says INVALID
RELATED OBJECT.
Or...is this exactly what you tried, only to find that it didn't work?
The above restriction should not be important in most if not all system
data set cases. Indeed, the example of SYS1.SBLSxxx vs
SYS1.IPCS.SBLS is a classic example of where extended aliases would
be applicable. Seems like ServerPac could distribute a procedure/program
to create/issue the appropriate DEFINE ALIAS statements for any data
sets whose HLQs were changed from the delivered defaults.
Extended aliases (those defined with SYMBOLICRELATE) don't work well
(i.e., at all!) for entries in the master catalog. Did you mean data
set aliases?
I think you might recall the early days of the ADCD systems, for which I
made all the data sets start with SYS1 for simplicity's sake*. People
complained because the data set names didn't match the books (a fair
point!). In the next iteration I used data set aliass. Then, people
complained because they thought the solution complex and because the
allocated data set names didn't match those specified in JCL on on an
ISPF panel (also fair, but the alternatives seemed worse).
(*This all happened before we put a stop to release-related qualifiers
for z/OS data sets. People stopped complaining when they found that
migrations were dead easy from a catalog standpoint because the data set
names didn't change.)
In other words, it certainly *sounds* like an attractive solution, but
experience has shown me otherwise, and these days I aim for KISS-like
solutions.
I highly recommend the use of static data set names from a catalog
standpoint because it simplifies migration and removes opportunities for
error. Using the names we ship simplifies things more because one need
not edit the PROCs, etc., we ship that name the data sets. Of course,
if you've been using different names for a Long Time, there can be
significant migration effort needed to get there. Nonetheless, it will
probably pay you back...eventually.
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[EMAIL PROTECTED]
--
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
Re: Consistent Data Set Names (Was: Workable Debuggers ...)
On Wed, 16 Apr 2008 09:28:25 -0400, John Eells wrote: Extended aliases (those defined with SYMBOLICRELATE) don't work well (i.e., at all!) for entries in the master catalog. Did you mean data set aliases? Really? In what way do you mean? I used them for an ISV product a few years ago and they seemed to work quite nicely. -- Tom Marchant -- 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
Re: Consistent Data Set Names (Was: Workable Debuggers ...)
Tom Marchant wrote: On Wed, 16 Apr 2008 09:28:25 -0400, John Eells wrote: Extended aliases (those defined with SYMBOLICRELATE) don't work well (i.e., at all!) for entries in the master catalog. Did you mean data set aliases? Really? In what way do you mean? I used them for an ISV product a few years ago and they seemed to work quite nicely. I wasn't clear. I mean that if the *entry describing the data set* is in the master catalog, SYMBOLICRELATE is probably not the tool you want to use. ;-) It's fine, of course, to have an *alias* defined with SYMBOLICRELATE in the master catalog, pointing (once the symbol has been resolved) to a user catalog where the *data set entry* lives. This works well, particularly for product set catalogs that are used for subsystems or other products that aren't in the z/OS product set. -- John Eells z/OS Technical Marketing IBM Poughkeepsie [EMAIL PROTECTED] -- 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
Re: Consistent Data Set Names (Was: Workable Debuggers ...)
On Wed, 16 Apr 2008 10:06:04 -0400, John Eells wrote:
Tom Marchant wrote:
On Wed, 16 Apr 2008 09:28:25 -0400, John Eells wrote:
Extended aliases (those defined with SYMBOLICRELATE) don't work well
(i.e., at all!) for entries in the master catalog. Did you mean data
set aliases?
Really? In what way do you mean? I used them for an ISV product a few
years ago and they seemed to work quite nicely.
I wasn't clear. I mean that if the *entry describing the data set* is
in the master catalog, SYMBOLICRELATE is probably not the tool you want
to use. ;-)
Depends on what you want to do, I suppose. The example in DFSMS:
Managing Catalogs is
DEFINE ALIAS (NAME(SYS1.PRODUCT) -
SYMBOLICRELATE('SYS1.PRODVR..PRODUCT'))
It's fine, of course, to have an *alias* defined with SYMBOLICRELATE in
the master catalog, pointing (once the symbol has been resolved) to a
user catalog where the *data set entry* lives. This works well,
particularly for product set catalogs that are used for subsystems or
other products that aren't in the z/OS product set.
Now I'm really confused. AFAIK, a data set alias for a non-VSAM data set,
with or without SYMBOLICRELATE, does not point to a catalog.
--
Tom Marchant
--
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
Re: Consistent Data Set Names (Was: Workable Debuggers ...)
Tom Marchant wrote:
On Wed, 16 Apr 2008 10:06:04 -0400, John Eells wrote:
Tom Marchant wrote:
On Wed, 16 Apr 2008 09:28:25 -0400, John Eells wrote:
Extended aliases (those defined with SYMBOLICRELATE) don't work well
(i.e., at all!) for entries in the master catalog. Did you mean data
set aliases?
Really? In what way do you mean? I used them for an ISV product a few
years ago and they seemed to work quite nicely.
I wasn't clear. I mean that if the *entry describing the data set* is
in the master catalog, SYMBOLICRELATE is probably not the tool you want
to use. ;-)
Depends on what you want to do, I suppose. The example in DFSMS:
Managing Catalogs is
DEFINE ALIAS (NAME(SYS1.PRODUCT) -
SYMBOLICRELATE('SYS1.PRODVR..PRODUCT'))
It's fine, of course, to have an *alias* defined with SYMBOLICRELATE in
the master catalog, pointing (once the symbol has been resolved) to a
user catalog where the *data set entry* lives. This works well,
particularly for product set catalogs that are used for subsystems or
other products that aren't in the z/OS product set.
Now I'm really confused. AFAIK, a data set alias for a non-VSAM data set,
with or without SYMBOLICRELATE, does not point to a catalog.
Son of a gun. You learn something new every day. I hadn't realized
there was support for other than catalog-related aliases to use
SYMBOLICRELATE, though it makes perfect sense that it's there. (And I'm
really surprised that it's the example used in the book, because...well,
never mind.)
I apologize for the misinformation.
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[EMAIL PROTECTED]
--
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
Re: Consistent Data Set Names (Was: Workable Debuggers ...)
On Wed, 16 Apr 2008 09:28:25 -0400, John Eells wrote:
Edward Jaffe wrote:
I created a file called 'MYUID.BASE' and used SYMBOLICRELATE to create
'SYS1.ALIAS.OF.BASE'. In my environment, data sets starting with MYUID
I have experienced that to fail (to my dismay) because there's
no symbol in the symbolic alias.
are cataloged in a user catalog. Data sets starting with SYS1 are
cataloged in the master catalog. Try as I might, I could not figure out
how to get the system to see 'SYS1.ALIAS.OF.BASE' as an alias of
'MYUID.BASE'. (Perhaps I overlooked something.)
I think this is because you did not place the entry for
SYS1.ALIAS.OF.BASE in the usercat, but I don't have a system to test
that assumption on these days. You might try:
DEFINE -
ALIAS( -
NAME(SYS1.ALIAS.OF.BASE) -
RELATE(MYUID.BASE)) -
CATALOG('usercat.with.myuid.in.it').
Which is pretty useless because reference to SYS1.ALIAS.OF.BASE
in a DD statement or ALLOCATE will search the master catalog
and not find the alias.
An additional problem with aliases of any sort is that jobs
referencing data sets by aliases and encountering ENQ conflicts
on the RELATED name will fail with JCL errors rather than
waiting for the conflict to be resolved.
-- 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
Re: Consistent Data Set Names (Was: Workable Debuggers ...)
In [EMAIL PROTECTED], on 04/14/2008 at 08:08 AM, Edward Jaffe [EMAIL PROTECTED] said: Actually, JCLIN works no matter what the data set LLQ is. When you code JCLIN, you specify the DDDEF (or DD) names *as* LLQs. You never specify any *real* LLQs. Are you a betting man? Quite frequently the JCLIN is the same JCL as you ran in a prior job. The old stage 2 concept may be dead for the operating system, but it is alive and well for some products, e.g., IMS. However, when I experimented with this a while back, I found that it worked as expected only when the HLQs of the base name and alias were the same -- or more precisely -- expected to be in the same catalog. Would you really want two release of the same product to be cataloged in different user catalogs? Try as I might, I could not figure out how to get the system to see 'SYS1.ALIAS.OF.BASE' as an alias of 'MYUID.BASE'. (Perhaps I overlooked something.) And I can't figure out why you wanted to ;-) Shirley making SYS1.foo.llq an alias of SYS1.foo.foorelease..llq is good enough for tracking releases. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Consistent Data Set Names (Was: Workable Debuggers ...)
In [EMAIL PROTECTED], on 04/14/2008 at 08:49 AM, Mark Zelden [EMAIL PROTECTED] said: JCLIN LLQ must equal the DDDEF name. There is no requirement that a DDDEF of LINKLIB point to hlq.LINKLIB. There is when the JCLIN is a job that you must run prior to doing the JCLIN. And, no, that didn't die when MVSCP came along. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Consistent Data Set Names (Was: Workable Debuggers ...)
In [EMAIL PROTECTED], on 04/13/2008 at 12:00 AM, Edward Jaffe [EMAIL PROTECTED] said: I don't see nearly as many configurations as a busy consultant like Mark, But, I have noticed with our customers that the LLQ of SMP/E-maintained, MVS classic data sets seems to always mirror the DDDEF name in target zone. Otherwise JCLIN wouldn't work. This observation led to the following idea, which I had previously advanced only to a select few through verbal conversation: Are you aware of extended indirect cataloging? If not, read up on SYMBOLICRELATE. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Consistent Data Set Names (Was: Workable Debuggers ...)
On Sun, 13 Apr 2008 20:07:41 -0300, Shmuel Metz (Seymour J.) [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], on 04/13/2008 at 12:00 AM, Edward Jaffe [EMAIL PROTECTED] said: I don't see nearly as many configurations as a busy consultant like Mark, But, I have noticed with our customers that the LLQ of SMP/E-maintained, MVS classic data sets seems to always mirror the DDDEF name in target zone. Otherwise JCLIN wouldn't work. JCLIN LLQ must equal the DDDEF name. There is no requirement that a DDDEF of LINKLIB point to hlq.LINKLIB. It can point to SCHMUEL.METZ and SMP/E will happily go on its way. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: Consistent Data Set Names (Was: Workable Debuggers ...)
Shmuel Metz (Seymour J.) wrote: In [EMAIL PROTECTED], on 04/13/2008 at 12:00 AM, Edward Jaffe [EMAIL PROTECTED] said: I don't see nearly as many configurations as a busy consultant like Mark, But, I have noticed with our customers that the LLQ of SMP/E-maintained, MVS classic data sets seems to always mirror the DDDEF name in target zone. Otherwise JCLIN wouldn't work. Actually, JCLIN works no matter what the data set LLQ is. When you code JCLIN, you specify the DDDEF (or DD) names *as* LLQs. You never specify any *real* LLQs. This observation led to the following idea, which I had previously advanced only to a select few through verbal conversation: Are you aware of extended indirect cataloging? If not, read up on SYMBOLICRELATE. I'm familiar with indirect cataloging -- substituting a system symbol for the volume name. (We recommend this as the best way to support large configurations with multiple operating systems and/or product releases.) SYMBOLICRELATE is an entirely different concept. It is called _extended alias_ support and allows you to refer to one data set using an alternate name. I agree this appears to be a good way to achieve the desired objective using existing operating system facilities. However, when I experimented with this a while back, I found that it worked as expected only when the HLQs of the base name and alias were the same -- or more precisely -- expected to be in the same catalog. I created a file called 'MYUID.BASE' and used SYMBOLICRELATE to create 'SYS1.ALIAS.OF.BASE'. In my environment, data sets starting with MYUID are cataloged in a user catalog. Data sets starting with SYS1 are cataloged in the master catalog. Try as I might, I could not figure out how to get the system to see 'SYS1.ALIAS.OF.BASE' as an alias of 'MYUID.BASE'. (Perhaps I overlooked something.) The above restriction should not be important in most if not all system data set cases. Indeed, the example of SYS1.SBLSxxx vs SYS1.IPCS.SBLS is a classic example of where extended aliases would be applicable. Seems like ServerPac could distribute a procedure/program to create/issue the appropriate DEFINE ALIAS statements for any data sets whose HLQs were changed from the delivered defaults. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Consistent Data Set Names (Was: Workable Debuggers ...)
On Mon, 14 Apr 2008 08:08:36 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: Actually, JCLIN works no matter what the data set LLQ is. When you code JCLIN, you specify the DDDEF (or DD) names *as* LLQs. You never specify any *real* LLQs. It is the LLQ that matters in JCLIN. Consider this example: ++USERMOD(ICEEXIT) REWORK(1996350). ++VER (Z038) FMID (HSM1F00) . ++JCLIN. //ASMLINK JOB (ACCT),CLASS=M //ASMEXEC PGM=ASMBLR //SYSPRINT DD SYSOUT=* //SYSLIB DD DSN=SYS1.MACLIB,DISP=SHR // DD DSN=SYS1.ICEUSER,DISP=SHR //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,1) //SYSPUNCH DD DSN=amp;PUNCH(ICEIEXIT), //SPACE=(TRK,(1,1,1),DISP=(,PASS) //SYSIN DD * ICEIEXIT CSECT END /* //* //LKED EXEC PGM=IEWL,PARM='LET,LIST,NCAL,RENT,XREF' //SYSPRINT DD SYSOUT=* //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,1) //SYSLMOD DD DSN=ANYTHING.FRED,DISP=SHR //SYSPUNCH DD *.ASM.SYSPUNCH,DISP=(OLD,DELETE) //SYSINDD * INCLUDE SYSPUNCH(ICEIEXIT) ENTRY ICEIEXIT NAME ICEIEXIT(R) /* ++SRC (ICEIEXIT) DISTLIB(AICESRCE) . ## // DD DSN=TECH.USERMODS.SOURCE(ICEIEXIT),DISP=SHR Will SMP/E try to link to the data set pointed to by a DDDEF (or DDNAME in JCL) of SYSLMOD, or the DSN pointed to by DDDEF or DDNAME of FRED? (FRED) Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: Consistent Data Set Names (Was: Workable Debuggers ...)
On Mon, 14 Apr 2008 08:08:36 -0700, Edward Jaffe wrote: Actually, JCLIN works no matter what the data set LLQ is. When you code JCLIN, you specify the DDDEF (or DD) names *as* LLQs. You never specify any *real* LLQs. That seems clearer and more logical than what I thought I understood from the SMP/E RM. We'll see who's right. SYMBOLICRELATE is an entirely different concept. It is called _extended alias_ support and allows you to refer to one data set using an alternate name. I agree this appears to be a good way to achieve the desired objective using existing operating system facilities. However, when I experimented with this a while back, I found that it worked as expected only when the HLQs of the base name and alias were the same -- or more precisely -- expected to be in the same catalog. Me, too. I created a file called 'MYUID.BASE' and used SYMBOLICRELATE to create 'SYS1.ALIAS.OF.BASE'. In my environment, data sets starting with MYUID are cataloged in a user catalog. Data sets starting with SYS1 are cataloged in the master catalog. Try as I might, I could not figure out how to get the system to see 'SYS1.ALIAS.OF.BASE' as an alias of 'MYUID.BASE'. (Perhaps I overlooked something.) WAD. I ranted about this in this list a while back. My expectations/desires matched yours, and I asked why the catalog search was not simply redriven from the beginning with the RELATED name so it would look in the directory actually containing that name. The modal reaction from the partisans was approximately I pity the fool ... If that were done, catalog search might loop, or IPL might be impossible, or it would be incompatible with existing art ... Or the universe might collapse into a black hole. I was and remain unmoved by the explanations. Loops can be terminated with counters. Reviews and audits can detect, anticipate, and avoid configuration errors that preclude IPL. Etc. -- 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
Re: Consistent Data Set Names (Was: Workable Debuggers ...)
On Mon, 14 Apr 2008 10:29:26 -0500, Mark Zelden wrote: On Mon, 14 Apr 2008 08:08:36 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: Actually, JCLIN works no matter what the data set LLQ is. When you code JCLIN, you specify the DDDEF (or DD) names *as* LLQs. You never specify any *real* LLQs. It is the LLQ that matters in JCLIN. Consider this example: ++USERMOD(ICEEXIT) REWORK(1996350). ++VER (Z038) FMID (HSM1F00) . ++JCLIN. //ASMLINK JOB (ACCT),CLASS=M //ASMEXEC PGM=ASMBLR //SYSPRINT DD SYSOUT=* //SYSLIB DD DSN=SYS1.MACLIB,DISP=SHR // DD DSN=SYS1.ICEUSER,DISP=SHR //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,1) //SYSPUNCH DD DSN=amp;amp;PUNCH(ICEIEXIT), //SPACE=(TRK,(1,1,1),DISP=(,PASS) //SYSIN DD * ICEIEXIT CSECT END /* //* //LKED EXEC PGM=IEWL,PARM='LET,LIST,NCAL,RENT,XREF' //SYSPRINT DD SYSOUT=* //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,1) //SYSLMOD DD DSN=ANYTHING.FRED,DISP=SHR //SYSPUNCH DD *.ASM.SYSPUNCH,DISP=(OLD,DELETE) //SYSINDD * INCLUDE SYSPUNCH(ICEIEXIT) ENTRY ICEIEXIT NAME ICEIEXIT(R) /* ++SRC (ICEIEXIT) DISTLIB(AICESRCE) . ## // DD DSN=TECH.USERMODS.SOURCE(ICEIEXIT),DISP=SHR Will SMP/E try to link to the data set pointed to by a DDDEF (or DDNAME in JCL) of SYSLMOD, or the DSN pointed to by DDDEF or DDNAME of FRED? (FRED) FRED. I believe you and Ed are saying the same thing; I can agree with both of you. The more interesting question concerns the ASM STEP: Will the assembler search for macros in the concatenation of data sets defined by DDDEFs MACLIB and ICEUSER, or in the concatenation defined by DDDEF SYSLIB? -- 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
Re: Consistent Data Set Names (Was: Workable Debuggers ...)
On Mon, 14 Apr 2008 10:47:20 -0500, Paul Gilmartin [EMAIL PROTECTED] wrote: The more interesting question concerns the ASM STEP: Will the assembler search for macros in the concatenation of data sets defined by DDDEFs MACLIB and ICEUSER, or in the concatenation defined by DDDEF SYSLIB? SYSLIB DDDEF. I'm sure it is clearly documented. :-) Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: Consistent Data Set Names (Was: Workable Debuggers ...)
Mark Zelden wrote: It is the LLQ that matters in JCLIN. Consider this example: I can't tell if you're correcting me or agreeing with me and providing additional illustrative examples. O:-) Just to clarify what I said/meant: The LLQ you specify in JCLIN *is* the DDDEF name ... and *not* the LLQ of the data set to which the DDDEF refers. The actual LLQ of the data set is irrelevant! -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Consistent Data Set Names (Was: Workable Debuggers ...)
Shane wrote:
Forget it Ed. All I want is for vendors to package product(s) properly -
let customers manage their own environments.
Shane. I think you missed the point of this entirely! Packaging products
properly is not the issue. The issue is how to give customers freedom
to choose data set names for system libraries while -- at the same time
-- allowing programs to find those libraries without knowing the local
data set names.
For example, SYS1.SBLSCLI0(BLSCLIBD) contains the following statements:
| ISPEXEC LIBDEF ISPMLIB DATASET ID('SYS1.SBLSMSG0') COND
| ISPEXEC LIBDEF ISPPLIB DATASET ID('SYS1.SBLSPNL0') COND
| ISPEXEC LIBDEF ISPSLIB DATASET ID('SYS1.SBLSKEL0') COND
As Mark pointed out, if an installation changes the names of the
SYS1.SBLS libraries to something else -- for example
SYS1.IPCS.SBLS -- then BLSCLIBD will no longer work. Someone at the
installation must manually change the CLIST to reflect their local data
set name choice.
My idea is to have (among others) the following system symbols defined
in IEASYMxx:
SBLSKEL0
SBLSMSG0
SBLSPNL0
Each symbol would contain the name of the corresponding local data set.
Instead of hard-wired data set names, the three LIBDEF statements in
BLSCLIBD would contain something like:
| ISPEXEC LIBDEF ISPMLIB DATASET ID('SBLSMSG0') COND
| ISPEXEC LIBDEF ISPPLIB DATASET ID('SBLSPNL0') COND
| ISPEXEC LIBDEF ISPSLIB DATASET ID('SBLSKEL0') COND
The DYNALLOC service would recognize and resolve the symbolic data set
name references via static system symbols. (See ASASYMBP in SYS1.MACLIB,)
In this way, BLSCLIBD, and all others similar programs with hard-coded
data set name references, could be made to work _as delivered_ without
requiring manual customization for local data set naming conventions.
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/
--
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
Re: Consistent Data Set Names (Was: Workable Debuggers ...)
--snip-- Agreed. Clearly, if tz/OS was being designed ab initio, a standard data set naming convention would probably be used. (Then again, in that case there might not even be data sets as we know them!) However, after so many decades, we can't expect customers to make wholesale -- and costly -- busy work changes in their production environments just to be consistent with others running z/OS (including their competitors). ---unsnip Changes by attrition might work, if you could show a tangible benefit. -snip- I don't see nearly as many configurations as a busy consultant like Mark, But, I have noticed with our customers that the LLQ of SMP/E-maintained, MVS classic data sets seems to always mirror the DDDEF name in target zone. (In fact, I have *never* seen an exception to this rule with data sets we deliver!) It's the HLQ(s) that seem to be fair game for site-specific customization. -unsnip- Guilty as charged. I did it for security adminstration reasons, mostly. And a select few used HLQ's that we already had in use for other purposes. -snip--- This observation led to the following idea, which I had previously advanced only to a select few through verbal conversation: Suppose static system symbols could be created automatically by SMP/E (or an add-on program using the SMP/E API) for each DDDEF in the target zone that references an MVS classic data set! The first 20 symbols would be defined something like this (from my system): SYMDEF(BNJPNL1='NETV.BNJPNL1') SYMDEF(BNJPNL2='NETV.BNJPNL2') SYMDEF(BNJSRC1='NETV.BNJSRC1') SYMDEF(CBRDBRM='SYS1.CBRDBRM') SYMDEF(CIPLIB='SYS1.CIPLIB') SYMDEF(CMDLIB='SYS1.CMDLIB') SYMDEF(CNMCLST='NETV.CNMCLST') SYMDEF(CNMINST='NETV.CNMINST') SYMDEF(CNMLINK='NETV.CNMLINK') SYMDEF(CNMPNL1='NETV.CNMPNL1') SYMDEF(CNMSAMP='NETV.CNMSAMP') SYMDEF(COB2LIB='CALLLIBS.DUMMY') SYMDEF(CSSLIB='SYS1.CSSLIB') SYMDEF(DBBLIB='SYS1.DBBLIB') SYMDEF(DCFASM='SCRIPT.DCFASM') SYMDEF(DCFDIST='SCRIPT.DCFDIST') SYMDEF(DCFGML='SCRIPT.DCFGML') SYMDEF(DCFIMAGE='SCRIPT.DCFIMAGE') SYMDEF(DCFLOAD='SCRIPT.DCFLOAD') SYMDEF(DCFMAC='SCRIPT.DCFMAC') SYMDEF(DCFSAMP='SCRIPT.DCFSAMP') SYMDEF(DFQLLIB='SYS1.DFQLLIB') SYMDEF(DFQMLIB='SYS1.DFQMLIB') SYMDEF(DFQPLIB='SYS1.DFQPLIB') SYMDEF(DGTCLIB='SYS1.DFQLLIB') SYMDEF(DGTLLIB='SYS1.DGTLLIB') SYMDEF(DGTMLIB='SYS1.DGTMLIB') SYMDEF(DGTPLIB='SYS1.DGTPLIB') SYMDEF(DGTSLIB=SYS1.DGTSLIB') . . (there are hundreds and hundreds more)) . The member containing these symbols could be concatenated with other, existing IEASYMxx members in parmlib. Like other static system symbols, these symbols would be created at IPL time and be available to all programs. IBM- and ISV-distributed CLISTs, JCL, and other program elements that reference these SMP/E-maintained target libraries could then refer to a data set name by its symbolic name. For example, instead of specifying: EX 'SYS1.SBLSCLI0(BLDCDDIR)' we would write something like: EX 'SBLSCLI0.(BLSCDDIR)' And, backward compatibility would be automatically maintained for existing programs that don't expect to be updated in the near-term to take advantage of this new level of indirection. Although static symbol substitution support is fairly pervasive in some obvious places within z/OS, it is still missing from some other equally-obvious places -- such as for the data set command operands in these examples. Static symbol substitution for data set names would need a thorough implementation for this scheme to work reliably. (Perhaps the call to the substitution service should be made from within DYNALLOC itself to minimize interface points.) No matter the exact details of implementation, IMHO it would be time well spent... unsnip Ed, I agree with the concept. But the implementation will be horrendously expensive. Just providing efficient access to those symbols across all the environments that would need it could be a massive undertaking. And getting all the ISV's aboard will be nigh-unto impossible unless you can show them a real benefit on the balance sheets. THEN you've got to teach the customers how to use it to their best advantage. GOOD LUCK!!! -- 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
