Re: Deleting Alias
Hello, Below is the result of LISTCAT against the NONVSAM which I was trying to relate and I find there are two Alias being associated. 1IDCAMS SYSTEM SERVICES TIME: 0NONVSAM --- ZOS.SAMPLJCL HISTORY DATASET-OWNER-(NULL) CREATION2009.043 RELEASE2 EXPIRATION--.000 ACCOUNT-INFO---(NULL) DSNTYPE--LIBRARY SMSDATA STORAGECLASS XXX MANAGEMENTCLASS--XXX DATACLASS ---DEFAULT LBACKUP ---.000. VOLUMES VOLSERXX DEVTYPE--X'3010200F' FSEQN- ASSOCIATIONS ALIASZOS.LUT.SAMPJCL ALIASZOS.MUT.SAMPJCL ATTRIBUTES IN-CAT --- ICF.RND.CATX ZOS.LUT.SAMPJCL - Is the One which does not appear in ISPF 3.4 search ZOS.MUT.SAMPLJCL - Via ISPF does not looks to be a alias but a PDS dataset. On Thu, Aug 22, 2013 at 11:24 AM, Gerhard Postpischil gerh...@valley.netwrote: On 8/21/2013 10:21 PM, John Gilmore wrote: In one shop, call it S to protect the guilty, the applications programmers were very reluctant, perhaps for sentimental reasons, to give up using it long after any rationale for doing so had disappeared. Making IEWL440 an alias for a more storage-intensive and much more efficient version of the linkage editor resolved this problem without discommoding the these sentimental S applications programmers. That brings back memories; we used a program named ZLKD from SHARE, credited to Alan Fulford of ALLIED BREWERIES, BURTON, 25/7/73 . While the original was written for MFT, picking up the partition size, it was easily converted to MVT. It checked the available storage, built a modified PARM with the appropriate SIZE parameter, and invoked the largest Linkage Editor that would fit. Our unprivileged users never had a chance to mess up g Gerhard Postpischil Bradford, Vermont --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Another thing to add : The normal Alias deletion with : DEL ZOS.LUT.SAMPJCL ALIAS does not deletes the alias but a CATALOG parameter with CAT(ICF.RND.CATX) deletes the alias. Not sure why it is not picking up the usercatalog automatically during deletion. On Thu, Aug 22, 2013 at 4:19 PM, mf db dbajava...@gmail.com wrote: Hello, Below is the result of LISTCAT against the NONVSAM which I was trying to relate and I find there are two Alias being associated. 1IDCAMS SYSTEM SERVICES TIME: 0NONVSAM --- ZOS.SAMPLJCL HISTORY DATASET-OWNER-(NULL) CREATION2009.043 RELEASE2 EXPIRATION--.000 ACCOUNT-INFO---(NULL) DSNTYPE--LIBRARY SMSDATA STORAGECLASS XXX MANAGEMENTCLASS--XXX DATACLASS ---DEFAULT LBACKUP ---.000. VOLUMES VOLSERXX DEVTYPE--X'3010200F' FSEQN- ASSOCIATIONS ALIASZOS.LUT.SAMPJCL ALIASZOS.MUT.SAMPJCL ATTRIBUTES IN-CAT --- ICF.RND.CATX ZOS.LUT.SAMPJCL - Is the One which does not appear in ISPF 3.4 search ZOS.MUT.SAMPLJCL - Via ISPF does not looks to be a alias but a PDS dataset. On Thu, Aug 22, 2013 at 11:24 AM, Gerhard Postpischil gerh...@valley.netwrote: On 8/21/2013 10:21 PM, John Gilmore wrote: In one shop, call it S to protect the guilty, the applications programmers were very reluctant, perhaps for sentimental reasons, to give up using it long after any rationale for doing so had disappeared. Making IEWL440 an alias for a more storage-intensive and much more efficient version of the linkage editor resolved this problem without discommoding the these sentimental S applications programmers. That brings back memories; we used a program named ZLKD from SHARE, credited to Alan Fulford of ALLIED BREWERIES, BURTON, 25/7/73 . While the original was written for MFT, picking up the partition size, it was easily converted to MVT. It checked the available storage, built a modified PARM with the appropriate SIZE parameter, and invoked the largest Linkage Editor that would fit. Our unprivileged users never had a chance to mess up g Gerhard Postpischil Bradford, Vermont --**--** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
In cae1xxdhzntyss_1w68jktuwrcqzy8uvvdaqeymfa6wzojpz...@mail.gmail.com, on 08/21/2013 at 10:21 PM, John Gilmore jwgli...@gmail.com said: In one shop, call it S to protect the guilty, the applications programmers were very reluctant, perhaps for sentimental reasons, to give up using it long after any rationale for doing so had disappeared. Making IEWL440 an alias for a more storage-intensive and much more efficient version of the linkage editor resolved this problem without discommoding the these sentimental S applications programmers. This is a wholly appropriate use of catalog aliases. No, it has nothing to do with catalog alias entries. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
I was able to do the following 1. Def a new PDS 2. Def alias. Def alias (name(mytsoid.cattest.cntl) relate(tsoid.test cat.cntl) This was successful 3. Def another alias with my altid. Also successful Going to ispf 3.4. I bring up my dataset group I then enter on an alias Del alias / This was successful. List no longer showed that alias. However the nonvsam file and the remaining alias are still there. So this works for me Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
On 3.4, remove the / from __ Prefix Dsname Level
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of mf db
Sent: Wednesday, August 21, 2013 6:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Deleting Alias
Hello,
I was able to delete a alias from a usercatalog with a below parms :
DEL ENTRYNAME ALIAS CAT(USERCAT)
Defining alias to a Non Vsam :
DEF ALIAS (NAME(XX..)-
RELATE('X..ZZZ.'))
But when I tried checking the alias with ISPF 3.4 option I couldn't see the
entry being visible.
When I do listcat against the dataset ..ZZZ. but I could see the
alias relation for XXX... Not sure why the alias entry is not visible.
I tried even deleting and defining back but no luck. I do get a message as
duplicate dataset name when I try defining it again.
IDC3013I DUPLICATE DATA SET NAME
Z/OS : 1.13
Could some please shed some light on the above.
/Peter
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Its already removed...
On Wed, Aug 21, 2013 at 4:34 PM, Richards, Robert B.
robert.richa...@opm.gov wrote:
On 3.4, remove the / from __ Prefix Dsname Level
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of mf db
Sent: Wednesday, August 21, 2013 6:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Deleting Alias
Hello,
I was able to delete a alias from a usercatalog with a below parms :
DEL ENTRYNAME ALIAS CAT(USERCAT)
Defining alias to a Non Vsam :
DEF ALIAS (NAME(XX..)-
RELATE('X..ZZZ.'))
But when I tried checking the alias with ISPF 3.4 option I couldn't see
the entry being visible.
When I do listcat against the dataset ..ZZZ. but I could see
the alias relation for XXX... Not sure why the alias entry is not
visible.
I tried even deleting and defining back but no luck. I do get a message as
duplicate dataset name when I try defining it again.
IDC3013I DUPLICATE DATA SET NAME
Z/OS : 1.13
Could some please shed some light on the above.
/Peter
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
On Wed, 21 Aug 2013 11:25:36 +, Tidy, David (D) wrote: The alias will be created in the same catalog as the related object Are you sure? The AMS manual doesn't say that, as far as I can see. In any case, unless both the alias and the data set name resolve to the same user catalog, the alias is worthless. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
On Wed, 21 Aug 2013 09:07:51 -0500, Tom Marchant wrote: In any case, unless both the alias and the data set name resolve to the same user catalog, the alias is worthless. That is one of the dumber design decisions I have ever encountered. Simply, alias resolution should search for the RELATED DSN in the catalog corresponding to its HLQ where it is, not that of the alias. Multi-level aliasing would be nice, too. And why is an alias of a VSAM DSN called something else (PATH, IIRC) rather than simply ALIAS? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Lizette,
The LISTCAT shows that both the values are pointing to the same usercatalog.
On Wed, Aug 21, 2013 at 7:47 PM, Lizette Koehler stars...@mindspring.comwrote:
Note in the definition of the DEF ALIAS RELATE() it states: The
resolved value for entryname must be a catalog entry that is located in the
same catalog that contains the value for aliasname.
So you need to ensure the RELATE entryname is in the same catalog as the
main entry name.
So if your entryname is BOB.MY.FILE that is in ucat MYUCAT1 then when you
do the
DEF TED.MY.FILE ALIAS RELATE(BOB.MY.FILE) then both BOB hlq and TED hlq
must be in MYUCAT1
I may have that backwards, but it is close. Bottom line, the example IBM
has in the book for doing this is very bad. I will be opening a request for
updating that to a more reasonable example. Second, from the document it
appears that the HLQs should be in the same UCAT. At least that is my
understanding from reading the IBM doc (which is very nebulous at best).
And I do not believe that you are required to use the CAT parameter in the
DEF ... ALIAS RELATE() function
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of mf db
Sent: Wednesday, August 21, 2013 3:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Deleting Alias
Hello,
I was able to delete a alias from a usercatalog with a below parms :
DEL ENTRYNAME ALIAS CAT(USERCAT)
Defining alias to a Non Vsam :
DEF ALIAS (NAME(XX..)-
RELATE('X..ZZZ.'))
But when I tried checking the alias with ISPF 3.4 option I couldn't see the
entry being visible.
When I do listcat against the dataset ..ZZZ. but I could see
the
alias relation for XXX... Not sure why the alias entry is not
visible.
I tried even deleting and defining back but no luck. I do get a message as
duplicate dataset name when I try defining it again.
IDC3013I DUPLICATE DATA SET NAME
Z/OS : 1.13
Could some please shed some light on the above.
/Peter
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
mf db wrote:
n ISPF 3.4, put in the '/' on the line for include additional qualifiers
It is there...
Then you have messy problems. What is your TSO PREFIX setting?
I was able to delete a alias from a usercatalog with a below parms :
DEL ENTRYNAME ALIAS CAT(USERCAT)
Did you do a LISTC before deletion?
Defining alias to a Non Vsam :
DEF ALIAS (NAME(XX..)-
RELATE('X..ZZZ.'))
Then, did you do a LISTC on that? The catalog itself, the entry itself and the
related catalog.
But when I tried checking the alias with ISPF 3.4 option I couldn't see the
entry being visible.
You have a problem with your catalog search order. Check from Master Catalog
all the way down to that user catalog for pointers. You can try =3.4 using XX,
then XX., and so on. if you can see something, press PF10-PF11 until you
see the catalog.
I think you have duplicate entries or your master catalog is not pointing to
the right user catalog.
I tried even deleting and defining back but no luck. I do get a message as
duplicate dataset name when I try defining it again.
If it is a duplicate, then use ISMF and using the name and the catalog names to
search where is that entry is actually.
Or it is somewhere on a volume. If it is in a SMS volser, but not cataloged,
then you need other remedies for that.
I think you should post the results of your searches so the right approach can
be recommended to fix it. Of course, make a backup of your catalogs first.
Groete / Greetings
Elardus Engelbrecht
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
I am sure in that we had exactly this issue recently when someone tried to alias non-vsam dataset across catalogs. I thought I found something somewhere that logically (but not necessarily explicitly) supported this statement, but it might take me some time to find back again. Best regards, David Tidy Tel:(31)115-67-1745 IS Technical Management/SAP-Mf Dow Benelux B.V. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: 21 August 2013 16:08 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Deleting Alias On Wed, 21 Aug 2013 11:25:36 +, Tidy, David (D) wrote: The alias will be created in the same catalog as the related object Are you sure? The AMS manual doesn't say that, as far as I can see. In any case, unless both the alias and the data set name resolve to the same user catalog, the alias is worthless. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Do you have multilevel alias implemented in your environment?
If so, you may have TED and BOB in one catalog but perhaps TED.MY and BOB.MY
are in different catalogs???
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of mf db
Sent: Wednesday, August 21, 2013 7:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Deleting Alias
Lizette,
The LISTCAT shows that both the values are pointing to the same usercatalog.
On Wed, Aug 21, 2013 at 7:47 PM, Lizette Koehler
stars...@mindspring.comwrote:
Note in the definition of the DEF ALIAS RELATE() it states:
The resolved value for entryname must be a catalog entry that is
located in the same catalog that contains the value for aliasname.
So you need to ensure the RELATE entryname is in the same catalog as
the main entry name.
So if your entryname is BOB.MY.FILE that is in ucat MYUCAT1 then when
you do the
DEF TED.MY.FILE ALIAS RELATE(BOB.MY.FILE) then both BOB hlq and TED
hlq must be in MYUCAT1
I may have that backwards, but it is close. Bottom line, the example
IBM has in the book for doing this is very bad. I will be opening a
request for updating that to a more reasonable example. Second, from
the document it appears that the HLQs should be in the same UCAT. At
least that is my understanding from reading the IBM doc (which is very
nebulous at best).
And I do not believe that you are required to use the CAT parameter in
the DEF ... ALIAS RELATE() function
Lizette
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of mf db
Sent: Wednesday, August 21, 2013 3:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Deleting Alias
Hello,
I was able to delete a alias from a usercatalog with a below parms :
DEL ENTRYNAME ALIAS CAT(USERCAT)
Defining alias to a Non Vsam :
DEF ALIAS (NAME(XX..)-
RELATE('X..ZZZ.'))
But when I tried checking the alias with ISPF 3.4 option I couldn't
see the entry being visible.
When I do listcat against the dataset ..ZZZ. but I could
see the alias relation for XXX... Not sure why the alias entry
is not visible.
I tried even deleting and defining back but no luck. I do get a
message as duplicate dataset name when I try defining it again.
IDC3013I DUPLICATE DATA SET NAME
Z/OS : 1.13
Could some please shed some light on the above.
/Peter
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
On Wed, 21 Aug 2013 07:17:27 -0700, Lizette Koehler wrote: DEF TED.MY.FILE ALIAS RELATE(BOB.MY.FILE) then both BOB hlq and TED hlq must be in MYUCAT1 You can control which catalog the TED alias is created in, but if the catalogs are different you lose either way. If you create TED in BOB's catalog, catalog search fails to find TED; if you create TED in its proper catalog, catalog search fails to find BOB. I may have that backwards, but it is close. Bottom line, the example IBM has in the book for doing this is very bad. I will be opening a request for updating that to a more reasonable example.... Rather, that should be a Requirement that it be done right, not a RCF for documentation that it is done wrong. ... Second, from the document it appears that the HLQs should be in the same UCAT. At least that is my understanding from reading the IBM doc (which is very nebulous at best). And I do not believe that you are required to use the CAT parameter in the DEF ... ALIAS RELATE() function -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Aliases are most useful for PDS and PDSE members, and they are handled very differently in the two. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Elardus, I tried viewing via ISMF and I could see the alias entry pointing the same usercatalog, but when I type Browse agains the alias I get a message as Dataset not catalogued On Wed, Aug 21, 2013 at 8:01 PM, Paul Gilmartin paulgboul...@aim.comwrote: On Wed, 21 Aug 2013 07:17:27 -0700, Lizette Koehler wrote: DEF TED.MY.FILE ALIAS RELATE(BOB.MY.FILE) then both BOB hlq and TED hlq must be in MYUCAT1 You can control which catalog the TED alias is created in, but if the catalogs are different you lose either way. If you create TED in BOB's catalog, catalog search fails to find TED; if you create TED in its proper catalog, catalog search fails to find BOB. I may have that backwards, but it is close. Bottom line, the example IBM has in the book for doing this is very bad. I will be opening a request for updating that to a more reasonable example.... Rather, that should be a Requirement that it be done right, not a RCF for documentation that it is done wrong. ... Second, from the document it appears that the HLQs should be in the same UCAT. At least that is my understanding from reading the IBM doc (which is very nebulous at best). And I do not believe that you are required to use the CAT parameter in the DEF ... ALIAS RELATE() function -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
In 3.4 if you display the dataset and then PF11 - see if there are dataset attributes. If there is no space, no lrecl, no blksize, and so forth, then all you have is a catalog entry and that is it. You can create as many catalog entries as you like that do not have REAL datasets underneath them. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of mf db Sent: Wednesday, August 21, 2013 7:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Deleting Alias Elardus, I tried viewing via ISMF and I could see the alias entry pointing the same usercatalog, but when I type Browse agains the alias I get a message as Dataset not catalogued On Wed, Aug 21, 2013 at 8:01 PM, Paul Gilmartin paulgboul...@aim.comwrote: On Wed, 21 Aug 2013 07:17:27 -0700, Lizette Koehler wrote: DEF TED.MY.FILE ALIAS RELATE(BOB.MY.FILE) then both BOB hlq and TED hlq must be in MYUCAT1 You can control which catalog the TED alias is created in, but if the catalogs are different you lose either way. If you create TED in BOB's catalog, catalog search fails to find TED; if you create TED in its proper catalog, catalog search fails to find BOB. I may have that backwards, but it is close. Bottom line, the example IBM has in the book for doing this is very bad. I will be opening a request for updating that to a more reasonable example.... Rather, that should be a Requirement that it be done right, not a RCF for documentation that it is done wrong. ... Second, from the document it appears that the HLQs should be in the same UCAT. At least that is my understanding from reading the IBM doc (which is very nebulous at best). And I do not believe that you are required to use the CAT parameter in the DEF ... ALIAS RELATE() function -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Lizette, But I am not able to create and relate with same alias and I get a duplicate dataset entry. Here the background is that I am trying to use this alias in one of our proclibs. On Wed, Aug 21, 2013 at 8:12 PM, Lizette Koehler stars...@mindspring.comwrote: In 3.4 if you display the dataset and then PF11 - see if there are dataset attributes. If there is no space, no lrecl, no blksize, and so forth, then all you have is a catalog entry and that is it. You can create as many catalog entries as you like that do not have REAL datasets underneath them. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of mf db Sent: Wednesday, August 21, 2013 7:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Deleting Alias Elardus, I tried viewing via ISMF and I could see the alias entry pointing the same usercatalog, but when I type Browse agains the alias I get a message as Dataset not catalogued On Wed, Aug 21, 2013 at 8:01 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Wed, 21 Aug 2013 07:17:27 -0700, Lizette Koehler wrote: DEF TED.MY.FILE ALIAS RELATE(BOB.MY.FILE) then both BOB hlq and TED hlq must be in MYUCAT1 You can control which catalog the TED alias is created in, but if the catalogs are different you lose either way. If you create TED in BOB's catalog, catalog search fails to find TED; if you create TED in its proper catalog, catalog search fails to find BOB. I may have that backwards, but it is close. Bottom line, the example IBM has in the book for doing this is very bad. I will be opening a request for updating that to a more reasonable example.... Rather, that should be a Requirement that it be done right, not a RCF for documentation that it is done wrong. ... Second, from the document it appears that the HLQs should be in the same UCAT. At least that is my understanding from reading the IBM doc (which is very nebulous at best). And I do not believe that you are required to use the CAT parameter in the DEF ... ALIAS RELATE() function -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
This problem seems unclear because of the two catalog ALIAS uses. One for the
HLQ that probably points to a user catlg and another for the DSN alias pointing
to a user catlg. Ensure that both are pointing to the same catalog. Is there
an ALIAS entry for the HLQ?
Cliff McNeill
I was able to delete a alias from a usercatalog with a below parms :
DEL ENTRYNAME ALIAS CAT(USERCAT)
Defining alias to a Non Vsam :
DEF ALIAS (NAME(XX..)-
RELATE('X..ZZZ.'))
But when I tried checking the alias with ISPF 3.4 option I couldn't see the
entry being visible.
When I do listcat against the dataset ..ZZZ. but I could see
the alias relation for XXX... Not sure why the alias entry is not
visible.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Catalog aliases (as opposed to PDS member aliases) have two different
uses.
1. By far the most common is high-level-qualifier such as TSO userid. In
this case, the alias itself lives in the master catalog and
points--RELATEs--to a user catalog that contains one or more actual DSNs
that all begin with the HLQ. To delete such an alias, you *must not* name
the user catalog in the command because user cat name is just part of the
entry you are deleting. You are deleting the alias (implicitly) from the
master catalog.
DEL 'hlq' ALIAS
2. A less common usage but one we deploy to manage ServerPac data sets
relates a fully qualified DSN in a user catalog to a different name. For
example:
'OSR13.SYS1.LINKILIB' is defined in 'MVSR13.ICF.MASTER' as
pointing--RELATing--to 'SYS1.LINKLIB' on the SMPE target volume. In order
for this to work, there must still be an HLQ alias 'OSR13'
pointing--RELATing--to the user catalog as in (1). To delete the fully
qualified alias data set name from the user catalog, you must name the
user catalog because that's where the alias entry actually lives.
DEL 'fully-qualified-name' ALIAS CAT('usercat-name') NOSCRATCH
I threw in NOSCRATCH because otherwise your actual data set will
disappear. Unless that's what you want.
3. If you are getting 'duplicate name' when you try to redefine the alias,
then you did not actually delete the alias in the first place. That would
be the result of including user cat name in the command in (1) above. The
command would fail, and the alias would remain in the master catalog.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: mf db dbajava...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 08/21/2013 07:40 AM
Subject:Re: Deleting Alias
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Elardus,
I tried viewing via ISMF and I could see the alias entry pointing the same
usercatalog, but when I type Browse agains the alias I get a message as
Dataset not catalogued
On Wed, Aug 21, 2013 at 8:01 PM, Paul Gilmartin
paulgboul...@aim.comwrote:
On Wed, 21 Aug 2013 07:17:27 -0700, Lizette Koehler wrote:
DEF TED.MY.FILE ALIAS RELATE(BOB.MY.FILE) then both BOB hlq and TED
hlq
must be in MYUCAT1
You can control which catalog the TED alias is created in, but if the
catalogs are different you lose either way. If you create TED in
BOB's catalog, catalog search fails to find TED; if you create TED
in its proper catalog, catalog search fails to find BOB.
I may have that backwards, but it is close. Bottom line, the example
IBM
has in the book for doing this is very bad. I will be opening a request
for
updating that to a more reasonable example....
Rather, that should be a Requirement that it be done right, not
a RCF for documentation that it is done wrong.
... Second, from the document it
appears that the HLQs should be in the same UCAT. At least that is my
understanding from reading the IBM doc (which is very nebulous at
best).
And I do not believe that you are required to use the CAT parameter in
the
DEF ... ALIAS RELATE() function
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
On Wed, 21 Aug 2013 20:25:48 +0530, mf db wrote: But I am not able to create and relate with same alias and I get a duplicate dataset entry. Here the background is that I am trying to use this alias in one of our proclibs. If the alias has the same name as the related data set, it would seem that the alias is unnecessary. On Wed, Aug 21, 2013 at 8:12 PM, Lizette Koehler wrote: In 3.4 if you display the dataset and then PF11 - see if there are dataset attributes. If there is no space, no lrecl, no blksize, and so forth, then all you have is a catalog entry and that is it. You can create as many catalog entries as you like that do not have REAL datasets underneath them. But you can't create an alias unless the RELATEd DSN is catalogued. Unless you call it a SYMBOLIC alias, and you can't create a SYMBOLIC alias unless its name contains one or more actual symbols. Silly rule. On Wed, 21 Aug 2013 10:39:41 -0400, John Gilmore wrote: Aliases are most useful for PDS and PDSE members, and they are handled very differently in the two. And both are even more radically different from catalogued aliases of data set names. Hmmm... If a directory alias exists for a PDS (or PDSE) member, and I EDIT and SAVE that member, what's the subsequent condition of the alias? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
The NOSCRATCH does not takes up :
DEL .linklib ALIAS CATALOG(ICF.UCAT.CAT2) NOSCRATCH
IDC3226I INCONSISTENT PARAMETERS INVOLVING 'NOSCRATCH'
On Wed, Aug 21, 2013 at 8:41 PM, Skip Robinson jo.skip.robin...@sce.comwrote:
Catalog aliases (as opposed to PDS member aliases) have two different
uses.
1. By far the most common is high-level-qualifier such as TSO userid. In
this case, the alias itself lives in the master catalog and
points--RELATEs--to a user catalog that contains one or more actual DSNs
that all begin with the HLQ. To delete such an alias, you *must not* name
the user catalog in the command because user cat name is just part of the
entry you are deleting. You are deleting the alias (implicitly) from the
master catalog.
DEL 'hlq' ALIAS
2. A less common usage but one we deploy to manage ServerPac data sets
relates a fully qualified DSN in a user catalog to a different name. For
example:
'OSR13.SYS1.LINKILIB' is defined in 'MVSR13.ICF.MASTER' as
pointing--RELATing--to 'SYS1.LINKLIB' on the SMPE target volume. In order
for this to work, there must still be an HLQ alias 'OSR13'
pointing--RELATing--to the user catalog as in (1). To delete the fully
qualified alias data set name from the user catalog, you must name the
user catalog because that's where the alias entry actually lives.
DEL 'fully-qualified-name' ALIAS CAT('usercat-name') NOSCRATCH
I threw in NOSCRATCH because otherwise your actual data set will
disappear. Unless that's what you want.
3. If you are getting 'duplicate name' when you try to redefine the alias,
then you did not actually delete the alias in the first place. That would
be the result of including user cat name in the command in (1) above. The
command would fail, and the alias would remain in the master catalog.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: mf db dbajava...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 08/21/2013 07:40 AM
Subject:Re: Deleting Alias
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Elardus,
I tried viewing via ISMF and I could see the alias entry pointing the same
usercatalog, but when I type Browse agains the alias I get a message as
Dataset not catalogued
On Wed, Aug 21, 2013 at 8:01 PM, Paul Gilmartin
paulgboul...@aim.comwrote:
On Wed, 21 Aug 2013 07:17:27 -0700, Lizette Koehler wrote:
DEF TED.MY.FILE ALIAS RELATE(BOB.MY.FILE) then both BOB hlq and TED
hlq
must be in MYUCAT1
You can control which catalog the TED alias is created in, but if the
catalogs are different you lose either way. If you create TED in
BOB's catalog, catalog search fails to find TED; if you create TED
in its proper catalog, catalog search fails to find BOB.
I may have that backwards, but it is close. Bottom line, the example
IBM
has in the book for doing this is very bad. I will be opening a request
for
updating that to a more reasonable example....
Rather, that should be a Requirement that it be done right, not
a RCF for documentation that it is done wrong.
... Second, from the document it
appears that the HLQs should be in the same UCAT. At least that is my
understanding from reading the IBM doc (which is very nebulous at
best).
And I do not believe that you are required to use the CAT parameter in
the
DEF ... ALIAS RELATE() function
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Sorry about that. NSCR is valid only for DEL NONVSAM. Not for alias. Leave
out that operand. No ill consequences.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: mf db dbajava...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 08/21/2013 08:26 AM
Subject:Re: Deleting Alias
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
The NOSCRATCH does not takes up :
DEL .linklib ALIAS CATALOG(ICF.UCAT.CAT2) NOSCRATCH
IDC3226I INCONSISTENT PARAMETERS INVOLVING 'NOSCRATCH'
On Wed, Aug 21, 2013 at 8:41 PM, Skip Robinson
jo.skip.robin...@sce.comwrote:
Catalog aliases (as opposed to PDS member aliases) have two different
uses.
1. By far the most common is high-level-qualifier such as TSO userid. In
this case, the alias itself lives in the master catalog and
points--RELATEs--to a user catalog that contains one or more actual DSNs
that all begin with the HLQ. To delete such an alias, you *must not*
name
the user catalog in the command because user cat name is just part of
the
entry you are deleting. You are deleting the alias (implicitly) from the
master catalog.
DEL 'hlq' ALIAS
2. A less common usage but one we deploy to manage ServerPac data sets
relates a fully qualified DSN in a user catalog to a different name. For
example:
'OSR13.SYS1.LINKILIB' is defined in 'MVSR13.ICF.MASTER' as
pointing--RELATing--to 'SYS1.LINKLIB' on the SMPE target volume. In
order
for this to work, there must still be an HLQ alias 'OSR13'
pointing--RELATing--to the user catalog as in (1). To delete the fully
qualified alias data set name from the user catalog, you must name the
user catalog because that's where the alias entry actually lives.
DEL 'fully-qualified-name' ALIAS CAT('usercat-name') NOSCRATCH
I threw in NOSCRATCH because otherwise your actual data set will
disappear. Unless that's what you want.
3. If you are getting 'duplicate name' when you try to redefine the
alias,
then you did not actually delete the alias in the first place. That
would
be the result of including user cat name in the command in (1) above.
The
command would fail, and the alias would remain in the master catalog.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: mf db dbajava...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 08/21/2013 07:40 AM
Subject:Re: Deleting Alias
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Elardus,
I tried viewing via ISMF and I could see the alias entry pointing the
same
usercatalog, but when I type Browse agains the alias I get a message as
Dataset not catalogued
On Wed, Aug 21, 2013 at 8:01 PM, Paul Gilmartin
paulgboul...@aim.comwrote:
On Wed, 21 Aug 2013 07:17:27 -0700, Lizette Koehler wrote:
DEF TED.MY.FILE ALIAS RELATE(BOB.MY.FILE) then both BOB hlq and TED
hlq
must be in MYUCAT1
You can control which catalog the TED alias is created in, but if the
catalogs are different you lose either way. If you create TED in
BOB's catalog, catalog search fails to find TED; if you create TED
in its proper catalog, catalog search fails to find BOB.
I may have that backwards, but it is close. Bottom line, the example
IBM
has in the book for doing this is very bad. I will be opening a
request
for
updating that to a more reasonable example....
Rather, that should be a Requirement that it be done right, not
a RCF for documentation that it is done wrong.
... Second, from the document it
appears that the HLQs should be in the same UCAT. At least that is
my
understanding from reading the IBM doc (which is very nebulous at
best).
And I do not believe that you are required to use the CAT parameter
in
the
DEF ... ALIAS RELATE() function
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Then you may have a aparable condition. I would open a case (SR) with IBM and see if they have any open APARs on this condition Personally I go to ISPF 3.4 and bring up the file name I want to delete Then issue Del / alias And hit enter Or Del / alias noscratch Note I do not use the catalog parameter. Catalog should know where to go. If you are working in a production environment. Be very careful you do not create a recovery situation for yourself. I always do this on my sandbox until I am sure of the command sequences. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of mf db Sent: Wednesday, August 21, 2013 8:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Deleting Alias The NOSCRATCH does not takes up : DEL .linklib ALIAS CATALOG(ICF.UCAT.CAT2) NOSCRATCH IDC3226I INCONSISTENT PARAMETERS INVOLVING 'NOSCRATCH' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
I note the presence of quotes in the RELATE but not the NAME. If not a
byproduct of excessive munging, this could be a part of the difficulty.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of mf db
Sent: Wednesday, August 21, 2013 3:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Deleting Alias
Hello,
I was able to delete a alias from a usercatalog with a below parms :
DEL ENTRYNAME ALIAS CAT(USERCAT)
Defining alias to a Non Vsam :
DEF ALIAS (NAME(XX..)-
RELATE('X..ZZZ.'))
But when I tried checking the alias with ISPF 3.4 option I couldn't see the
entry being visible.
When I do listcat against the dataset ..ZZZ. but I could see the
alias relation for XXX... Not sure why the alias entry is not visible.
I tried even deleting and defining back but no luck. I do get a message as
duplicate dataset name when I try defining it again.
IDC3013I DUPLICATE DATA SET NAME
Z/OS : 1.13
Could some please shed some light on the above.
/Peter
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Ok,
1 ) I did deleted the alias pointing to the usercatalog.- RC-0 and Alias
did not appear in listcat against the NON-VSAM dataset.
2 ) Again I defined with same name relating to the Non Vsam Dataset - RC-0
3 ) Listcat against the NON-VSAM dataset shows me the Alias which I defined
in previous step.
4 ) Here Alias and NON-vsam are pointing towards the same Usercatalog.
5 ) All the required options are enabled under ISPF 3.4 browse option.
6 ) The usercatalog is very much connected to the correct master catalog.
7 ) Usercatalog is sitting on the SMS managed volume.
But not sure why the system isn't recognizing the alias which was defined.
On Wed, Aug 21, 2013 at 9:05 PM, Skip Robinson jo.skip.robin...@sce.comwrote:
Sorry about that. NSCR is valid only for DEL NONVSAM. Not for alias. Leave
out that operand. No ill consequences.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: mf db dbajava...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 08/21/2013 08:26 AM
Subject:Re: Deleting Alias
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
The NOSCRATCH does not takes up :
DEL .linklib ALIAS CATALOG(ICF.UCAT.CAT2) NOSCRATCH
IDC3226I INCONSISTENT PARAMETERS INVOLVING 'NOSCRATCH'
On Wed, Aug 21, 2013 at 8:41 PM, Skip Robinson
jo.skip.robin...@sce.comwrote:
Catalog aliases (as opposed to PDS member aliases) have two different
uses.
1. By far the most common is high-level-qualifier such as TSO userid. In
this case, the alias itself lives in the master catalog and
points--RELATEs--to a user catalog that contains one or more actual DSNs
that all begin with the HLQ. To delete such an alias, you *must not*
name
the user catalog in the command because user cat name is just part of
the
entry you are deleting. You are deleting the alias (implicitly) from the
master catalog.
DEL 'hlq' ALIAS
2. A less common usage but one we deploy to manage ServerPac data sets
relates a fully qualified DSN in a user catalog to a different name. For
example:
'OSR13.SYS1.LINKILIB' is defined in 'MVSR13.ICF.MASTER' as
pointing--RELATing--to 'SYS1.LINKLIB' on the SMPE target volume. In
order
for this to work, there must still be an HLQ alias 'OSR13'
pointing--RELATing--to the user catalog as in (1). To delete the fully
qualified alias data set name from the user catalog, you must name the
user catalog because that's where the alias entry actually lives.
DEL 'fully-qualified-name' ALIAS CAT('usercat-name') NOSCRATCH
I threw in NOSCRATCH because otherwise your actual data set will
disappear. Unless that's what you want.
3. If you are getting 'duplicate name' when you try to redefine the
alias,
then you did not actually delete the alias in the first place. That
would
be the result of including user cat name in the command in (1) above.
The
command would fail, and the alias would remain in the master catalog.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: mf db dbajava...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 08/21/2013 07:40 AM
Subject:Re: Deleting Alias
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Elardus,
I tried viewing via ISMF and I could see the alias entry pointing the
same
usercatalog, but when I type Browse agains the alias I get a message as
Dataset not catalogued
On Wed, Aug 21, 2013 at 8:01 PM, Paul Gilmartin
paulgboul...@aim.comwrote:
On Wed, 21 Aug 2013 07:17:27 -0700, Lizette Koehler wrote:
DEF TED.MY.FILE ALIAS RELATE(BOB.MY.FILE) then both BOB hlq and TED
hlq
must be in MYUCAT1
You can control which catalog the TED alias is created in, but if the
catalogs are different you lose either way. If you create TED in
BOB's catalog, catalog search fails to find TED; if you create TED
in its proper catalog, catalog search fails to find BOB.
I may have that backwards, but it is close. Bottom line, the example
IBM
has in the book for doing this is very bad. I will be opening a
request
for
updating that to a more reasonable example....
Rather, that should be a Requirement that it be done right, not
a RCF for documentation that it is done wrong.
... Second, from the document it
appears that the HLQs should be in the same UCAT. At least that is
my
understanding from reading the IBM doc (which is very nebulous at
best).
And I do not believe that you are required to use the CAT parameter
in
the
DEF ... ALIAS RELATE() function
-- gil
Re: Deleting Alias
On 8/21/2013 10:39 AM, John Gilmore wrote: Aliases are most useful for PDS and PDSE members, and they are handled very differently in the two. Beauty is in the eye of the beholder. As useful as member aliases are, I find data set aliases more useful. For example, our third party products were usually referred to as product.library or SYS1.product.library, but those were alias entries for product.VnnRnnMnn.library or the SYS1. equivalent. This allows product support without a constant replacement of procedures, and allows fallback simply by recataloging the alias. Also the procedures had a parameter to allow inserting the version level, allowing us to keep service bureau customers with special requirements happy. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
Data-set aliases are certainly useful for keeping such names as ASSEMBLE or BIND unchanged when new versions are brought into use. They permit an installation to control which version default-taking users will invoke. I made my comment because it seemed to me that things were being done or, better, attempted with data-set aliases that are better done with member-name ones. I still think this. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
In of3e905769.0a5fdaa3-on88257bce.0050dfe9-88257bce.00537...@sce.com, on 08/21/2013 at 08:11 AM, Skip Robinson jo.skip.robin...@sce.com said: Catalog aliases (as opposed to PDS member aliases) have two different uses. 3. MLA -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
At this point it looks like you need to cut and paste the complete output from the job so we have a chance to determine what is really happening. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of mf db :: Sent: Wednesday, August 21, 2013 10:26 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: Deleting Alias :: :: Ok, :: :: 1 ) I did deleted the alias pointing to the usercatalog.- RC-0 and Alias :: did not appear in listcat against the NON-VSAM dataset. :: 2 ) Again I defined with same name relating to the Non Vsam Dataset - :: RC-0 :: 3 ) Listcat against the NON-VSAM dataset shows me the Alias which I :: defined :: in previous step. :: 4 ) Here Alias and NON-vsam are pointing towards the same Usercatalog. :: 5 ) All the required options are enabled under ISPF 3.4 browse option. :: 6 ) The usercatalog is very much connected to the correct master catalog. :: 7 ) Usercatalog is sitting on the SMS managed volume. :: :: But not sure why the system isn't recognizing the alias which was :: defined. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
I did not wish to deprecate the [appropriate] use of catalog aliases. Once, long ago, there was a configuration of the linkage editor called IEWL440 that operated very sedately but used little [then real], storage to do its job. In one shop, call it S to protect the guilty, the applications programmers were very reluctant, perhaps for sentimental reasons, to give up using it long after any rationale for doing so had disappeared. Making IEWL440 an alias for a more storage-intensive and much more efficient version of the linkage editor resolved this problem without discommoding the these sentimental S applications programmers. This is a wholly appropriate use of catalog aliases. These uses are few but not for that reason unimportant. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting Alias
On 8/21/2013 10:21 PM, John Gilmore wrote: In one shop, call it S to protect the guilty, the applications programmers were very reluctant, perhaps for sentimental reasons, to give up using it long after any rationale for doing so had disappeared. Making IEWL440 an alias for a more storage-intensive and much more efficient version of the linkage editor resolved this problem without discommoding the these sentimental S applications programmers. That brings back memories; we used a program named ZLKD from SHARE, credited to Alan Fulford of ALLIED BREWERIES, BURTON, 25/7/73 . While the original was written for MFT, picking up the partition size, it was easily converted to MVT. It checked the available storage, built a modified PARM with the appropriate SIZE parameter, and invoked the largest Linkage Editor that would fit. Our unprivileged users never had a chance to mess up g Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
