IBM Mainframe Forum

Hi All,

I am trying to understand a new Installation where I come through the below JCL of pointing a alias to a NONVSAM dataset.



from the above step 1 I understand that we delete alias entry SYS1.xxx.LINKLIB from ICF.LTS.USERCAT and in the next step 2 : We define alias SYS1.xxx.LINKLIB relating to 'SYS1.xxx.xxxc.BZI0LOAD'.

But When i do a Listcat against the alias "SYS1.xxx.LINKLIB" I get the below Result :



Now My question is when we have deleted the alias SYS1.xxx.LINKLIB from ICF.LTS.USERCAT then why does it shows again on the LISTCAT output ? Does it mean that the CAT keyword is taken as default in the step 2 ? Could someone please enlighten the technical reason of defining a ALIAS to a NON VSAM dataset in the installation ?

Jaggz

From the AMS for Catalogs manual in the DFSMS bookshelf, chapter 12 on DEFINE ALIAS:

The DEFINE ALIAS command defines an alternate name for a non-VSAM data set or a user catalog.

You do not indicate when the LISTCAT is being done, and the implication (not explicitly stated) is that xxx is DB14 in your post. If so, then one step deletes the alias and the next step defines the same alias -- so LISTCAT would continue to show the ALIAS unless you did the LISTCAT between step 1 and step 2 of the job. If xxx is not DB14, then you would have to explain when you are doing the LISTCAT, and why you are including a DEFINE ALIAS for a completely irrelevant data set in your post.

it' s just a way to enforce a naming standard for flexibility

for example ( not judging if it is good or bad )
if some installation had the standard of using an explicit steplib instead of relying on the LINKLIST

all the procedures invoking DB2 would have in the steplib concatenation
something like


the standard DB2 naming is something like DSN810. , DSN910. , DSNxxx

when migrating to a different db2 version all the user procedures would have to be changed

using the alias approach
defining an ALIAS <someprefix>.SDSNLOAD pointing to the DSNxxx.SDSNLOAD



would make the migration from DSN810 to DSN910 pretty painless
just an alias redefinition with no change to the procedures

Enrico ,

Thanks for your Input and I understand this is going to reduce the pain of changing loadlib each and every time time during migration, Upgrade or any Change.

Robert,

Apology for confusion.. Yes I mean DB14 as XXX so both are same. I did LISTCAT after Step1 and Step2. So my curiosity is how does the Usercatalog Information gets reflected when we do a Liscat Against the ALIAS when we have already deleted the ALIAS entry from ICF.LTS.USERCAT ?

STEP1 deletes the alias.
STEP2 defines the alias in the default catalog -- which apparently is ICF.LTS.USERCAT.

A LISTCAT will not show the alias deleted unless you execute it between STEP1 and STEP2. Does STEP1 give a zero return code? Usually data sets named <something>.LINKLIB are in the LINKLIST and cannot be deleted until removed from the LINKLIST.

Hi Robert,

"A LISTCAT will not show the alias deleted unless you execute it between STEP1 and STEP2"

issued LISTCAT after Step 2.

So you got normal and expected results -- STEP1 deletd the alias, then STEP2 defined the alias so your LISTCAT showed the alias still there.