Discussion:
IEFA107I when pointing to dataset alias
(too old to reply)
Sankaranarayanan, Vignesh
2018-04-30 16:33:25 UTC
Permalink
Hello All,

Let's say I have A.DATA.SET in APF and LNK.
I then create B.DATA.SET as an alias to A.DATA.SET

NONVSAM ------- A.DATA.SET
IN-CAT --- CATALOG.MASTER.CAT
HISTORY
DATASET-OWNER-----(NULL) CREATION--------2018.120
RELEASE----------------2 EXPIRATION------0000.000
VOLUMES
VOLSER------------VOL001 DEVTYPE------X'3010200F' FSEQN------------------0
ASSOCIATIONS
ALIAS----B.DATA.SET
ATTRIBUTES

ALIAS --------- B.DATA.SET
IN-CAT --- CATALOG.MASTER.CAT
HISTORY
RELEASE----------------2 CREATION--------2018.120
ASSOCIATIONS
NONVSAM-A.DATA.SET


But when I refer to B.DATA.SET in //SYSLIB in an assemble job, I get --> IEFA107I JOBNAME STEPNAME SYSLIB - DATA SET B.DATA.SET NOT FOUND

What gives.. ?

- Vignesh
Mainframe Infrastructure


MARKSANDSPENCER.COM
________________________________
Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Michael Babcock
2018-04-30 16:48:12 UTC
Permalink
If the job is running in a plex, make sure the job gets run on the system
where the alias is defined.

On Mon, Apr 30, 2018 at 11:35 AM Sankaranarayanan, Vignesh <
Post by Sankaranarayanan, Vignesh
Hello All,
Let's say I have A.DATA.SET in APF and LNK.
I then create B.DATA.SET as an alias to A.DATA.SET
NONVSAM ------- A.DATA.SET
IN-CAT --- CATALOG.MASTER.CAT
HISTORY
DATASET-OWNER-----(NULL) CREATION--------2018.120
RELEASE----------------2 EXPIRATION------0000.000
VOLUMES
VOLSER------------VOL001 DEVTYPE------X'3010200F'
FSEQN------------------0
ASSOCIATIONS
ALIAS----B.DATA.SET
ATTRIBUTES
ALIAS --------- B.DATA.SET
IN-CAT --- CATALOG.MASTER.CAT
HISTORY
RELEASE----------------2 CREATION--------2018.120
ASSOCIATIONS
NONVSAM-A.DATA.SET
But when I refer to B.DATA.SET in //SYSLIB in an assemble job, I get -->
IEFA107I JOBNAME STEPNAME SYSLIB - DATA SET B.DATA.SET NOT FOUND
What gives.. ?
- Vignesh
Mainframe Infrastructure
MARKSANDSPENCER.COM
________________________________
Marks and Spencer plc
Waterside House
35 North Wharf Road
London
W2 1NW
Registered No. 214436 in England and Wales.
Telephone (020) 7935 4422
Facsimile (020) 7487 2670
www.marksandspencer.com
Please note that electronic mail may be monitored.
This e-mail is confidential. If you received it by mistake, please let us
know and then delete it from your system; you should not copy, disclose, or
distribute its contents to anyone nor act in reliance on this e-mail, as
this is prohibited and may be unlawful.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
David W Noon
2018-04-30 16:51:26 UTC
Permalink
On Mon, 30 Apr 2018 16:34:43 +0000, Sankaranarayanan, Vignesh
(***@MARKS-AND-SPENCER.COM) wrote about "IEFA107I
when pointing to dataset alias" (in
Post by Sankaranarayanan, Vignesh
Let's say I have A.DATA.SET in APF and LNK.
I then create B.DATA.SET as an alias to A.DATA.SET
Are the A and B HLQs aliased to the same catalogue?

The alias will be in the catalogue for A, and if DSN lookups for B.*
don't go to the same catalogue then the lookup for your alias will not
be found.
--
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
***@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Sankaranarayanan, Vignesh
2018-04-30 16:54:57 UTC
Permalink
Usually, A goes to the mastercat, B goes to a usercat.
But when I define B.DATA.SET as an alias to A.DATA.SET when specifying RELATE(B's UCAT), it doesn't work.

– Vignesh
Mainframe Infrastructure

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of David W Noon
Sent: Monday 30-Apr-2018 22:23
To: IBM-***@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IEFA107I when pointing to dataset alias

On Mon, 30 Apr 2018 16:34:43 +0000, Sankaranarayanan, Vignesh
Post by Sankaranarayanan, Vignesh
Let's say I have A.DATA.SET in APF and LNK.
I then create B.DATA.SET as an alias to A.DATA.SET
Are the A and B HLQs aliased to the same catalogue?

The alias will be in the catalogue for A, and if DSN lookups for B.* don't go to the same catalogue then the lookup for your alias will not be found.
--
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
***@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

MARKSANDSPENCER.COM
________________________________
Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-04-30 16:58:16 UTC
Permalink
On Mon, Apr 30, 2018 at 11:52 AM, David W Noon <
Post by David W Noon
On Mon, 30 Apr 2018 16:34:43 +0000, Sankaranarayanan, Vignesh
when pointing to dataset alias" (in
Post by Sankaranarayanan, Vignesh
Let's say I have A.DATA.SET in APF and LNK.
I then create B.DATA.SET as an alias to A.DATA.SET
Are the A and B HLQs aliased to the same catalogue?
The alias will be in the catalogue for A, and if DSN lookups for B.*
don't go to the same catalogue then the lookup for your alias will not
be found.
--
Regards,
​RCF time, I guess. I tested and you are correct (of course). But the
manual does not say anything about the ALIAS name being required to be in
the same catalog as the base name.​
--
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Sankaranarayanan, Vignesh
2018-04-30 17:01:50 UTC
Permalink
RCF time?

– Vignesh
Mainframe Infrastructure

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of John McKown
Sent: Monday 30-Apr-2018 22:29
To: IBM-***@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IEFA107I when pointing to dataset alias
Post by David W Noon
On Mon, 30 Apr 2018 16:34:43 +0000, Sankaranarayanan, Vignesh
"IEFA107I when pointing to dataset alias" (in
Post by Sankaranarayanan, Vignesh
Let's say I have A.DATA.SET in APF and LNK.
I then create B.DATA.SET as an alias to A.DATA.SET
Are the A and B HLQs aliased to the same catalogue?
The alias will be in the catalogue for A, and if DSN lookups for B.*
don't go to the same catalogue then the lookup for your alias will not
be found.
--
Regards,
​RCF time, I guess. I tested and you are correct (of course). But the manual does not say anything about the ALIAS name being required to be in the same catalog as the base name.​

--
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

MARKSANDSPENCER.COM
________________________________
Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-04-30 17:05:15 UTC
Permalink
On Mon, Apr 30, 2018 at 12:02 PM, Sankaranarayanan, Vignesh <
Post by Sankaranarayanan, Vignesh
RCF time?
– Vignesh
Mainframe Infrastructure
​Reader Comment Form -- how to report a perceived error in an IBM manual.​
And I gotta watch out because RCF != RFC. RFC is "Request For Comment";
which is the way that IEEE documents internet protocols and other
documentation.
--
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Horein
2018-04-30 17:14:05 UTC
Permalink
In the DEFINE ALIAS doc here (for reference):
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.idai200/da6i2100.htm
and here (for detail):
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.idai200/da6i2102.htm
:

"If the entryname in the RELATE parameter is non-VSAM, choose an aliasname in
the NAME parameter. This is done to ensure the multilevel alias facility
selects the catalog that has the entryname."

To me, that last sentence indicates the aliasname is required to be in the
same catalog as the entry name.
I had to read it a couple of times to get the gist of it.
Post by John McKown
On Mon, Apr 30, 2018 at 11:52 AM, David W Noon <
Post by David W Noon
On Mon, 30 Apr 2018 16:34:43 +0000, Sankaranarayanan, Vignesh
when pointing to dataset alias" (in
Post by Sankaranarayanan, Vignesh
Let's say I have A.DATA.SET in APF and LNK.
I then create B.DATA.SET as an alias to A.DATA.SET
Are the A and B HLQs aliased to the same catalogue?
The alias will be in the catalogue for A, and if DSN lookups for B.*
don't go to the same catalogue then the lookup for your alias will not
be found.
--
Regards,
​RCF time, I guess. I tested and you are correct (of course). But the
manual does not say anything about the ALIAS name being required to be in
the same catalog as the base name.​
--
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-04-30 17:21:35 UTC
Permalink
Post by Steve Horein
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/
com.ibm.zos.v2r2.idai200/da6i2100.htm
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/
com.ibm.zos.v2r2.idai200/da6i2102.htm
​​
"If the entryname in the RELATE parameter is non-VSAM, choose an aliasname in
the NAME parameter. This is done to ensure the multilevel alias facility
selects the catalog that has the entryname."
​OK, I see it now. I think it could be a bit clearer as below:



"If the entryname in the RELATE parameter is non-VSAM, choose an aliasname
in
the NAME parameter *which resolves to the same catalog as the one in RELATE*.
This is done to ensure the multilevel alias facility
selects the catalog that has the entryname."
Post by Steve Horein
To me, that last sentence indicates the aliasname is required to be in the
same catalog as the entry name.
I had to read it a couple of times to get the gist of it.
--
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-04-30 17:31:03 UTC
Permalink
Post by John McKown
Post by David W Noon
Are the A and B HLQs aliased to the same catalogue?
The alias will be in the catalogue for A, and if DSN lookups for B.*
don't go to the same catalogue then the lookup for your alias will not
be found.
​RCF time, I guess. I tested and you are correct (of course). But the
manual does not say anything about the ALIAS name being required to be in
the same catalog as the base name.​
This has been discussed here so often that even I know it. So I'm astonished
that it's not documented.

But which manual should describe it? It should have cross-references from all
relavant others.

There ought to be an RFE tnat when the lookup fails in B's catalog the search should
be re-driven from A's catalog.

And the rule for SYMOLIC aliases is different.

The behavior of SYMBOLIC aliases is so usefully different that there ought to be an
RFE that a SYMBOLIC alias could be defined that doesn't contain an actual
substitutable symbol.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-04-30 17:40:20 UTC
Permalink
Post by Steve Horein
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.idai200/da6i2100.htm
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.idai200/da6i2102.htm
"If the entryname in the RELATE parameter is non-VSAM, choose an aliasname in
the NAME parameter. This is done to ensure the multilevel alias facility
selects the catalog that has the entryname."
"multilevel alias"? Does this mean I should be able to define an alias of an alias?
I thought I had tried that and, alas, it failed.
Post by Steve Horein
To me, that last sentence indicates the aliasname is required to be in the
same catalog as the entry name.
I had to read it a couple of times to get the gist of it.
This is so obscure a pitfall that IDCAMS ought to issue a message when the
guideline is violated.

And the suggestion is useless. Forcing B's alias into A's catalog simply causes
JCL //NAME DD DSN=B.WHAT.EVER to fail sooner.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-04-30 18:09:48 UTC
Permalink
This post might be inappropriate. Click to display it.
Lizette Koehler
2018-04-30 17:55:57 UTC
Permalink
It is best to keep everything in the same UCAT. Makes for a happy system

Could you explain what you are trying to do?

I have used SYMBLICREALTES and SYSTEM SYMBOLS to add things like release levels
in datasets, without the user having to change the JCL

For example. A.R111.B.C would be related to A.B.C which the end user always
uses and the R111 could be a system symbol that could be dynamically changed as
need.


Lizette
Post by Sankaranarayanan, Vignesh
-----Original Message-----
Sankaranarayanan, Vignesh
Sent: Monday, April 30, 2018 9:35 AM
Subject: IEFA107I when pointing to dataset alias
Hello All,
Let's say I have A.DATA.SET in APF and LNK.
I then create B.DATA.SET as an alias to A.DATA.SET
NONVSAM ------- A.DATA.SET
IN-CAT --- CATALOG.MASTER.CAT
HISTORY
DATASET-OWNER-----(NULL) CREATION--------2018.120
RELEASE----------------2 EXPIRATION------0000.000
VOLUMES
VOLSER------------VOL001 DEVTYPE------X'3010200F' FSEQN-------
-----------0
ASSOCIATIONS
ALIAS----B.DATA.SET
ATTRIBUTES
ALIAS --------- B.DATA.SET
IN-CAT --- CATALOG.MASTER.CAT
HISTORY
RELEASE----------------2 CREATION--------2018.120
ASSOCIATIONS
NONVSAM-A.DATA.SET
But when I refer to B.DATA.SET in //SYSLIB in an assemble job, I get -->
IEFA107I JOBNAME STEPNAME SYSLIB - DATA SET B.DATA.SET NOT FOUND
What gives.. ?
- Vignesh
Mainframe Infrastructure
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2018-04-30 18:10:34 UTC
Permalink
You are entangling non-VSAM aliases and Usercat aliases.

Non-VSAM aliases are always created in the same catalog as the related
name. However, catalog look-up will use relevant catalog aliases to
determine where the name is cataloged.

Probably, you need to specify the proper catalog (i.e. the one that would
be used to resolve it) on the DEFINE ALIAS.

btw, it's not valid to put a macro library in the APF or linklist. Nor to
try to use a load library as a macro library.
Post by Lizette Koehler
It is best to keep everything in the same UCAT. Makes for a happy system
Could you explain what you are trying to do?
​yeah... hypothetical issues aren't normally worth the time and energy.

sas​

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-04-30 18:27:39 UTC
Permalink
Post by Steve Smith
You are entangling non-VSAM aliases and Usercat aliases.
Non-VSAM aliases are always created in the same catalog as the related
name. However, catalog look-up will use relevant catalog aliases to
determine where the name is cataloged.
Probably, you need to specify the proper catalog (i.e. the one that would
be used to resolve it) on the DEFINE ALIAS.
btw, it's not valid to put a macro library in the APF or linklist. Nor to
try to use a load library as a macro library.
​Hum, now wouldn't it be "interesting" if you could use a load library as a
macro library. You ask "What would it do?". Well, instead of inserting the
card images from the member, it would _run_ the member referenced (LINK)
and that program would dynamically create and "insert" the card images via
some API. In the case of a COPY, the program would be passed a parm list
which would be like that passed by the initiator with PARM='' (or no PARM).
I.e. GPR1 upon entry points to a fullword with the high order bit "on"
which points to another fullword of binary 0s. In the case of a macro
invocation, each "parameter" on the macro would be passed as separate
"string" where each "string" in the the normal PARM format (halfword
length, then characters). This would be using the standard CALL format.
GPR1 pointing to an array of pointers to "strings" with the last pointer
address having bit 0 "on".​

Example:

BINMACRO PARM1,PARM2B,,PARM4=SOMETHING

GPR1->A(?)->H'5',CL5'PARM1'
A(?)->H'6',CL6'PARM2B'
A(?)->H'0'
A(X'80000000'+?)->H'15',CL15'PARM4=SOMETHING'
--
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Sankaranarayanan, Vignesh
2018-05-01 01:54:02 UTC
Permalink
What am I trying to do?
Let's say a product installation/customisation allows only for 1 HLQ, so I choose B for it because
A.** is used to host datasets that need to be LNK/LPAd.
B.** is used to host datasets that need to be APFd or nothing at all (just run-time).

A.** goes direct to the MCAT and B.** goes to a CATALOG.B.UCAT

Because I mentioned the 1 HLQ in product customisation, I need to make sure that if the files are looked for in B.**, the A.** files need to be reachable via their alises in B.**.

Makes sense?

- Vignesh
Mainframe Infrastructure

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Monday 30-Apr-2018 23:27
To: IBM-***@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IEFA107I when pointing to dataset alias

It is best to keep everything in the same UCAT. Makes for a happy system

Could you explain what you are trying to do?

I have used SYMBLICREALTES and SYSTEM SYMBOLS to add things like release levels in datasets, without the user having to change the JCL

For example. A.R111.B.C would be related to A.B.C which the end user always uses and the R111 could be a system symbol that could be dynamically changed as need.


Lizette
Post by Sankaranarayanan, Vignesh
-----Original Message-----
Behalf Of Sankaranarayanan, Vignesh
Sent: Monday, April 30, 2018 9:35 AM
Subject: IEFA107I when pointing to dataset alias
Hello All,
Let's say I have A.DATA.SET in APF and LNK.
I then create B.DATA.SET as an alias to A.DATA.SET
NONVSAM ------- A.DATA.SET
IN-CAT --- CATALOG.MASTER.CAT
HISTORY
DATASET-OWNER-----(NULL) CREATION--------2018.120
RELEASE----------------2 EXPIRATION------0000.000
VOLUMES
VOLSER------------VOL001 DEVTYPE------X'3010200F' FSEQN-------
-----------0
ASSOCIATIONS
ALIAS----B.DATA.SET
ATTRIBUTES
ALIAS --------- B.DATA.SET
IN-CAT --- CATALOG.MASTER.CAT
HISTORY
RELEASE----------------2 CREATION--------2018.120
ASSOCIATIONS
NONVSAM-A.DATA.SET
But when I refer to B.DATA.SET in //SYSLIB in an assemble job, I get
--> IEFA107I JOBNAME STEPNAME SYSLIB - DATA SET B.DATA.SET NOT FOUND
What gives.. ?
- Vignesh
Mainframe Infrastructure
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

MARKSANDSPENCER.COM
________________________________
Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Feller, Paul
2018-05-01 02:23:51 UTC
Permalink
"A.**" and "B.**" can be in the same catalog. The datasets that are in the linklst or lpalist do not have to be in the master catalog. You can use VOLSER to point to the datasets.

LPALIST could look like this.
A.B.C.SOFTWARE(VOLSR1)
A.B.D.SOFTWARE(VOLSR2)

LINKLST could look like this.
LNKLST ADD NAME(PROGPL) DSN(A.C.D.SOFTWARE)
VOLUME(VOLSR3)
LNKLST ADD NAME(PROGPL) DSN(A.C.E.SOFTWARE)
VOLUME(VOLSR4)


Thanks..

Paul Feller
AGT Mainframe Technical Support
***@transamerica.com
Work: (319)-355-7824
Cell: (319)-573-4821

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Sankaranarayanan, Vignesh
Sent: Monday, April 30, 2018 20:55
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IEFA107I when pointing to dataset alias

What am I trying to do?
Let's say a product installation/customisation allows only for 1 HLQ, so I choose B for it because
A.** is used to host datasets that need to be LNK/LPAd.
B.** is used to host datasets that need to be APFd or nothing at all (just run-time).

A.** goes direct to the MCAT and B.** goes to a CATALOG.B.UCAT

Because I mentioned the 1 HLQ in product customisation, I need to make sure that if the files are looked for in B.**, the A.** files need to be reachable via their alises in B.**.

Makes sense?

- Vignesh
Mainframe Infrastructure

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Monday 30-Apr-2018 23:27
To: IBM-***@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IEFA107I when pointing to dataset alias

It is best to keep everything in the same UCAT. Makes for a happy system

Could you explain what you are trying to do?

I have used SYMBLICREALTES and SYSTEM SYMBOLS to add things like release levels in datasets, without the user having to change the JCL

For example. A.R111.B.C would be related to A.B.C which the end user always uses and the R111 could be a system symbol that could be dynamically changed as need.


Lizette
Post by Sankaranarayanan, Vignesh
-----Original Message-----
Behalf Of Sankaranarayanan, Vignesh
Sent: Monday, April 30, 2018 9:35 AM
Subject: IEFA107I when pointing to dataset alias
Hello All,
Let's say I have A.DATA.SET in APF and LNK.
I then create B.DATA.SET as an alias to A.DATA.SET
NONVSAM ------- A.DATA.SET
IN-CAT --- CATALOG.MASTER.CAT
HISTORY
DATASET-OWNER-----(NULL) CREATION--------2018.120
RELEASE----------------2 EXPIRATION------0000.000
VOLUMES
VOLSER------------VOL001 DEVTYPE------X'3010200F' FSEQN-------
-----------0
ASSOCIATIONS
ALIAS----B.DATA.SET
ATTRIBUTES
ALIAS --------- B.DATA.SET
IN-CAT --- CATALOG.MASTER.CAT
HISTORY
RELEASE----------------2 CREATION--------2018.120
ASSOCIATIONS
NONVSAM-A.DATA.SET
But when I refer to B.DATA.SET in //SYSLIB in an assemble job, I get
--> IEFA107I JOBNAME STEPNAME SYSLIB - DATA SET B.DATA.SET NOT FOUND
What gives.. ?
- Vignesh
Mainframe Infrastructure
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

MARKSANDSPENCER.COM
________________________________
Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Sankaranarayanan, Vignesh
2018-05-01 03:21:02 UTC
Permalink
Hi Paul,

I know, it's just a site practice I guess.

- Vignesh
Mainframe Infrastructure

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Feller, Paul
Sent: Tuesday 01-May-2018 07:55
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IEFA107I when pointing to dataset alias

"A.**" and "B.**" can be in the same catalog. The datasets that are in the linklst or lpalist do not have to be in the master catalog. You can use VOLSER to point to the datasets.

LPALIST could look like this.
A.B.C.SOFTWARE(VOLSR1)
A.B.D.SOFTWARE(VOLSR2)

LINKLST could look like this.
LNKLST ADD NAME(PROGPL) DSN(A.C.D.SOFTWARE)
VOLUME(VOLSR3)
LNKLST ADD NAME(PROGPL) DSN(A.C.E.SOFTWARE)
VOLUME(VOLSR4)


Thanks..

Paul Feller
AGT Mainframe Technical Support
***@transamerica.com
Work: (319)-355-7824
Cell: (319)-573-4821

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Sankaranarayanan, Vignesh
Sent: Monday, April 30, 2018 20:55
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IEFA107I when pointing to dataset alias

What am I trying to do?
Let's say a product installation/customisation allows only for 1 HLQ, so I choose B for it because
A.** is used to host datasets that need to be LNK/LPAd.
B.** is used to host datasets that need to be APFd or nothing at all (just run-time).

A.** goes direct to the MCAT and B.** goes to a CATALOG.B.UCAT

Because I mentioned the 1 HLQ in product customisation, I need to make sure that if the files are looked for in B.**, the A.** files need to be reachable via their alises in B.**.

Makes sense?

- Vignesh
Mainframe Infrastructure

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Monday 30-Apr-2018 23:27
To: IBM-***@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IEFA107I when pointing to dataset alias

It is best to keep everything in the same UCAT. Makes for a happy system

Could you explain what you are trying to do?

I have used SYMBLICREALTES and SYSTEM SYMBOLS to add things like release levels in datasets, without the user having to change the JCL

For example. A.R111.B.C would be related to A.B.C which the end user always uses and the R111 could be a system symbol that could be dynamically changed as need.


Lizette
Post by Sankaranarayanan, Vignesh
-----Original Message-----
Behalf Of Sankaranarayanan, Vignesh
Sent: Monday, April 30, 2018 9:35 AM
Subject: IEFA107I when pointing to dataset alias
Hello All,
Let's say I have A.DATA.SET in APF and LNK.
I then create B.DATA.SET as an alias to A.DATA.SET
NONVSAM ------- A.DATA.SET
IN-CAT --- CATALOG.MASTER.CAT
HISTORY
DATASET-OWNER-----(NULL) CREATION--------2018.120
RELEASE----------------2 EXPIRATION------0000.000
VOLUMES
VOLSER------------VOL001 DEVTYPE------X'3010200F' FSEQN-------
-----------0
ASSOCIATIONS
ALIAS----B.DATA.SET
ATTRIBUTES
ALIAS --------- B.DATA.SET
IN-CAT --- CATALOG.MASTER.CAT
HISTORY
RELEASE----------------2 CREATION--------2018.120
ASSOCIATIONS
NONVSAM-A.DATA.SET
But when I refer to B.DATA.SET in //SYSLIB in an assemble job, I get
--> IEFA107I JOBNAME STEPNAME SYSLIB - DATA SET B.DATA.SET NOT FOUND
What gives.. ?
- Vignesh
Mainframe Infrastructure
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

MARKSANDSPENCER.COM
________________________________
Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
van der Grijn, Bart , B
2018-05-01 02:35:15 UTC
Permalink
If you can, I would recommend putting everything under B (put it in a ucat), limit your install libraries to your &SYSR1 or similar volumes and use system symbols for you PROGxx entries.
Except for SYS1 all our load libraries are in ucats. All LNK or LPA libraries are on &SYSR1 and every single entry in PROGxx has VOLUME(&SYSR1) coded (and every entry ins LPALSTxx has &SYSR1 coded as the volser)

Bart

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Sankaranarayanan, Vignesh
Sent: Monday, April 30, 2018 9:55 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IEFA107I when pointing to dataset alias

This email originated from outside of the organization.


What am I trying to do?
Let's say a product installation/customisation allows only for 1 HLQ, so I choose B for it because
A.** is used to host datasets that need to be LNK/LPAd.
B.** is used to host datasets that need to be APFd or nothing at all (just run-time).

A.** goes direct to the MCAT and B.** goes to a CATALOG.B.UCAT

Because I mentioned the 1 HLQ in product customisation, I need to make sure that if the files are looked for in B.**, the A.** files need to be reachable via their alises in B.**.

Makes sense?

- Vignesh
Mainframe Infrastructure

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Monday 30-Apr-2018 23:27
To: IBM-***@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IEFA107I when pointing to dataset alias

It is best to keep everything in the same UCAT. Makes for a happy system

Could you explain what you are trying to do?

I have used SYMBLICREALTES and SYSTEM SYMBOLS to add things like release levels in datasets, without the user having to change the JCL

For example. A.R111.B.C would be related to A.B.C which the end user always uses and the R111 could be a system symbol that could be dynamically changed as need.


Lizette
Post by Sankaranarayanan, Vignesh
-----Original Message-----
Behalf Of Sankaranarayanan, Vignesh
Sent: Monday, April 30, 2018 9:35 AM
Subject: IEFA107I when pointing to dataset alias
Hello All,
Let's say I have A.DATA.SET in APF and LNK.
I then create B.DATA.SET as an alias to A.DATA.SET
NONVSAM ------- A.DATA.SET
IN-CAT --- CATALOG.MASTER.CAT
HISTORY
DATASET-OWNER-----(NULL) CREATION--------2018.120
RELEASE----------------2 EXPIRATION------0000.000
VOLUMES
VOLSER------------VOL001 DEVTYPE------X'3010200F' FSEQN-------
-----------0
ASSOCIATIONS
ALIAS----B.DATA.SET
ATTRIBUTES
ALIAS --------- B.DATA.SET
IN-CAT --- CATALOG.MASTER.CAT
HISTORY
RELEASE----------------2 CREATION--------2018.120
ASSOCIATIONS
NONVSAM-A.DATA.SET
But when I refer to B.DATA.SET in //SYSLIB in an assemble job, I get
--> IEFA107I JOBNAME STEPNAME SYSLIB - DATA SET B.DATA.SET NOT FOUND
What gives.. ?
- Vignesh
Mainframe Infrastructure
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-04-30 18:44:56 UTC
Permalink
Post by Lizette Koehler
It is best to keep everything in the same UCAT. Makes for a happy system
IBM should emphasize happy customers above happy systems.

If the OP had created B.DATA.SET, listed it and noted the catalog then
deleted it and created the alias in that catalog, RELATEd to A.DATA.SET,
would it have worked cleanly?
Post by Lizette Koehler
Post by Sankaranarayanan, Vignesh
-----Original Message-----
From: IBM Mainframe Discussion List Sankaranarayanan, Vignesh
Sent: Monday, April 30, 2018 9:35 AM
NONVSAM ------- A.DATA.SET
IN-CAT --- CATALOG.MASTER.CAT
HISTORY
DATASET-OWNER-----(NULL) CREATION--------2018.120
RELEASE----------------2 EXPIRATION------0000.000
VOLUMES
VOLSER------------VOL001 DEVTYPE------X'3010200F' FSEQN-------
-----------0
ASSOCIATIONS
ALIAS----B.DATA.SET
ATTRIBUTES
ALIAS --------- B.DATA.SET
IN-CAT --- CATALOG.MASTER.CAT
HISTORY
RELEASE----------------2 CREATION--------2018.120
ASSOCIATIONS
NONVSAM-A.DATA.SET
But when I refer to B.DATA.SET in //SYSLIB in an assemble job, I get -->
IEFA107I JOBNAME STEPNAME SYSLIB - DATA SET B.DATA.SET NOT FOUND
-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Sankaranarayanan, Vignesh
2018-05-01 01:57:09 UTC
Permalink
I already tried this.

Say B.** goes to CATALOG.B.UCAT, I already tried DEFINE ALIAS B.DATA.SET RELATE(A.DATA.SET) CATALOG(CATALOG.B.UCAT), I got an error.
This was weeks ago, so I just used the DEFALIAS without the CATALOG keyword.

– Vignesh
Mainframe Infrastructure

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Tuesday 01-May-2018 00:16
To: IBM-***@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IEFA107I when pointing to dataset alias
Post by Lizette Koehler
It is best to keep everything in the same UCAT. Makes for a happy system
IBM should emphasize happy customers above happy systems.

If the OP had created B.DATA.SET, listed it and noted the catalog then deleted it and created the alias in that catalog, RELATEd to A.DATA.SET, would it have worked cleanly?
Post by Lizette Koehler
Post by Sankaranarayanan, Vignesh
-----Original Message-----
From: IBM Mainframe Discussion List Sankaranarayanan, Vignesh
Sent: Monday, April 30, 2018 9:35 AM
NONVSAM ------- A.DATA.SET
IN-CAT --- CATALOG.MASTER.CAT
HISTORY
DATASET-OWNER-----(NULL) CREATION--------2018.120
RELEASE----------------2 EXPIRATION------0000.000
VOLUMES
VOLSER------------VOL001 DEVTYPE------X'3010200F' FSEQN-------
-----------0
ASSOCIATIONS
ALIAS----B.DATA.SET
ATTRIBUTES
ALIAS --------- B.DATA.SET
IN-CAT --- CATALOG.MASTER.CAT
HISTORY
RELEASE----------------2 CREATION--------2018.120
ASSOCIATIONS
NONVSAM-A.DATA.SET
But when I refer to B.DATA.SET in //SYSLIB in an assemble job, I get
--> IEFA107I JOBNAME STEPNAME SYSLIB - DATA SET B.DATA.SET NOT FOUND
-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

MARKSANDSPENCER.COM
________________________________
Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-04-30 19:02:55 UTC
Permalink
Post by John McKown
Post by Steve Smith
btw, it's not valid to put a macro library in the APF or linklist. Nor to
try to use a load library as a macro library.
​Hum, now wouldn't it be "interesting" if you could use a load library as a
macro library. You ask "What would it do?". Well, instead of inserting the
card images from the member, it would _run_ the member referenced (LINK)
and that program would dynamically create and "insert" the card images via
some API. ...​
Or a Rexx EXEC which would insert card images via ADDRESS ASSEMBLE.
I did this once on CMS for a cross-assembler for a proprietary microprocessor.
We controlled the cross-assembler; we could provide the API. The ISV
language's debugger allowed Rexx to access assembler symbols.

We didn't use CMS Pipelines, but I could imagine a Pipeline connector as
another such API.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2018-05-01 00:57:40 UTC
Permalink
Post by Paul Gilmartin
There ought to be an RFE tnat when the lookup fails in B's catalog the search should
be re-driven from A's catalog.
How could that possibly work?

I reference B.DATA.SET and so the system goes to the catalog that B directs it to. In that catalog, it finds no record for B.DATA.SET (because the ALIAS record is in the catalog for A).

Having found no record for B.DATA.SET, the system has no idea that it's an alias, nor any clue which other catalog it ought to look in.

The only way it could work would be to change the base functionality so the ALIAS record could go in B's catalog, and I doubt that would happen at this late date.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-05-01 02:49:05 UTC
Permalink
Post by Feller, Paul
"A.**" and "B.**" can be in the same catalog. The datasets that are in the linklst or lpalist do not have to be in the master catalog. You can use VOLSER to point to the datasets.
One purpose of a catalog is to avoid the need to specify VOLSERs.
The design fails that purpose.

One purpose of aliases is to be able to use arbitrary alternate names
for data sets. The design fails that purpose.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-05-01 15:12:23 UTC
Permalink
Of course, you can use static system symbols in the volume serial numbers.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Paul Gilmartin <0000000433f07816-dmarc-***@listserv.ua.edu>
Sent: Monday, April 30, 2018 10:50 PM
To: IBM-***@listserv.ua.edu
Subject: Re: [EXTERNAL] Re: IEFA107I when pointing to dataset alias
Post by Feller, Paul
"A.**" and "B.**" can be in the same catalog. The datasets that are in the linklst or lpalist do not have to be in the master catalog. You can use VOLSER to point to the datasets.
One purpose of a catalog is to avoid the need to specify VOLSERs.
The design fails that purpose.

One purpose of aliases is to be able to use arbitrary alternate names
for data sets. The design fails that purpose.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
AlanWatthey , GMAIL
2018-05-01 05:20:48 UTC
Permalink
Walt,

You are correct for the RELATE type alias. The one that is linked directly to the dataset (ie. The alias gets deleted when the dataset gets deleted).

However, with a bit of extra work you can use SYMBOLICRELATE type alias instead and that is allowed to go in a different catalog (see OA52218). However, I ran into a problem whereby if you want to delete the alias again you need ALTER access to the catalog. I PMRed it and IBM have recently closed APAR OA54588 to fix it.


Regards,
Alan Watthey

-----Original Message-----
From: Walt Farrell [mailto:***@GMAIL.COM]
Sent: 01 May 2018 3:59 am
Subject: Re: IEFA107I when pointing to dataset alias
Post by Paul Gilmartin
There ought to be an RFE tnat when the lookup fails in B's catalog the search should
be re-driven from A's catalog.
How could that possibly work?

I reference B.DATA.SET and so the system goes to the catalog that B directs it to. In that catalog, it finds no record for B.DATA.SET (because the ALIAS record is in the catalog for A).

Having found no record for B.DATA.SET, the system has no idea that it's an alias, nor any clue which other catalog it ought to look in.

The only way it could work would be to change the base functionality so the ALIAS record could go in B's catalog, and I doubt that would happen at this late date.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-01 11:36:23 UTC
Permalink
Post by Sankaranarayanan, Vignesh
What am I trying to do?
Let's say a product installation/customisation allows only for 1 HLQ, so I choose B for it because
A.** is used to host datasets that need to be LNK/LPAd.
B.** is used to host datasets that need to be APFd or nothing at all (just run-time).
A.** goes direct to the MCAT and B.** goes to a CATALOG.B.UCAT
Contact the vendor and submit a requirement.
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Sankaranarayanan, Vignesh
2018-05-01 12:18:52 UTC
Permalink
.. and just stop doing everything until they deliver?

– Vignesh
Mainframe Infrastructure

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Tom Marchant
Sent: 01 May 2018 12:38
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IEFA107I when pointing to dataset alias
Post by Sankaranarayanan, Vignesh
What am I trying to do?
Let's say a product installation/customisation allows only for 1 HLQ,
so I choose B for it because
A.** is used to host datasets that need to be LNK/LPAd.
B.** is used to host datasets that need to be APFd or nothing at all (just run-time).
A.** goes direct to the MCAT and B.** goes to a CATALOG.B.UCAT
Contact the vendor and submit a requirement.

--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

MARKSANDSPENCER.COM
________________________________
Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-01 12:43:12 UTC
Permalink
Post by Sankaranarayanan, Vignesh
.. and just stop doing everything until they deliver?
Of course not. You have to do what you have to do. But you cannot do what
you want to do. Some choices are:

Give the vendor "B" for the HLQ and edit the JCL that they create, or rename
the data set later. DDDEFs will need to be changed if it is maintained by SMP/E.

Specify the VOLSER for LNKLST. That wouldn't be my first choice.
--
Tom Marchant
Post by Sankaranarayanan, Vignesh
-----Original Message-----
Contact the vendor and submit a requirement.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-05-01 15:36:17 UTC
Permalink
Post by Sankaranarayanan, Vignesh
.. and just stop doing everything until they deliver?
Better late than never. Or think of it as your gift to future generations of systems programmers.
But Walt's remarks were discouraging.
Post by Sankaranarayanan, Vignesh
However, with a bit of extra work you can use SYMBOLICRELATE type alias instead and that is allowed to go in a different catalog (see OA52218). ...
And to this end catalog should support specifying SYMBOLICRELATE with no
need to have an actual substitutable symbol in the alias name. That would
eliminate the need for (some of) the extra work.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John Eells
2018-05-01 18:00:02 UTC
Permalink
Data set aliases have confused people for a long time.

There are two basic kinds of aliases, user catalog connector aliases and
data set aliases.

Let's start with user catalog connector aliases. These are the ones
where what is specified on RELATE is a user catalog. User catalog
connector aliases in the master catalog are used to establish "catalog
orientation." That's a fancy way of saying, "Which catalog will be
searched for this data set?"

It's important to understand that z/OS has a 2-level catalog structure
at most. Thus, only those user catalog connector aliases that are in
the system's current *master* catalog will be used. You can have all
the user catalog connector aliases you want in user catalogs; the system
will cheerfully ignore them all.

Back to orientation. Suppose I have alias ABC and I point it to
MY.USER.CATALOG by running this IDCAMS command: DEFINE ALIAS(NAME(ABC)
RELATE(MY.USER.CATALOG)) to define it in my master catalog. Now, any
search for ABC."anything" will be directed to MY.USER.CATALOG; if the
data set entry cannot be resolved within the entries found in that same
catalog, the attempt to locate the data set will fail.*

OK so far? Now, let's suppose I want to find ABC.SOME.THING by the name
DEF.SOME.THING via the catalog structure. I can define a data set alias
named DEF.SOME.THING and related it to ABC.SOME.THING. However, since
the data set entry for ABC.SOME.THING is in MY.USER.CATALOG, the data
set alias entry has to be there as well for me to find it--because once
Catalog gets to MY.USER.CATALOG, it won't search in other places. So, I
will need to issue: DEFINE ALIAS(NAME(DEF.SOME.THING)
RELATE(ABC.SOME.THING) CATALOG(MY.USER.CATALOG))

I will also need MY.USER.CATALOG to be searched for names starting with
DEF to set the scope of the search (the "orientation") so that the
ABC.SOME.THING entry can eventually be found. So, I will *also* need to
issue: DEFINE ALIAS(NAME(DEF) RELATE(MY.USER.CATALOG))

So now, when I look for DEF.SOME.THING, Catalog finds the alias named
DEF, and uses it to orient the search to MY.USER.CATALOG. Catalog finds
DEF.SOME.THING and sees that it's an alias. Because the search *remains
oriented to* MY.USER.CATALOG, it looks for (and finds) the related-to
entry for ABC.SOME.THING and all is well.

(* Let's leave SYMBOLICRELATE out of it for now, until we all understand
the basics. Likewise, we can work our way up to what happens before
Catalog processes aliases and PATHENTRY entries for VSAM data seats, if
necessary.)

I hope this helps, a bit.
--
John Eells
IBM Poughkeepsie
***@us.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John Eells
2018-05-02 12:38:51 UTC
Permalink
Post by John Eells
(* Let's leave SYMBOLICRELATE out of it for now, until we all understand
the basics. Likewise, we can work our way up to what happens before
Catalog processes aliases and PATHENTRY entries for VSAM data seats, if
necessary.)
So now, let's look at what happens before Catalog is completely
initialized. During Catalog address space (aka "CAS") initialization,
the alias table (called the MLA table) is built. Before it's built, all
searches are oriented to the master catalog. After it's built, they are
oriented depending on whether there is an alias entry for the HLQ or
HLQs represented in each MLA table entry. (This is a logical view, not
necessarily how the code works in detail.)

The implication of this is that you can have *both*:

- One or more data set entries in the master catalog with a particular HLQ.

- An ALIAS entry for that same HLQ. (If you are using MLA, of course,
this can be more than one qualifier.)

Then, before the MLA table is built, the data set entries will be used
to find the data sets, but after it's built, the alias entry will be
used to reorient the search to the user cataog, and the data set entries
in the master catalog will be ignored.

While I am sure this can be construed to be "handy" to some, it is
pretty much guaranteed to confuse those who follow later, so I can't
really recommend that anyone actually do this. So I'll leave the order
in which such entries must be defined as an "Exercise to the Astute Reader."

(Still up...if I get to it...SYMBOLICRELATE and catalog orientation.)
--
John Eells
IBM Poughkeepsie
***@us.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-01 19:45:49 UTC
Permalink
Post by Sankaranarayanan, Vignesh
Post by AlanWatthey , GMAIL
However, with a bit of extra work you can use SYMBOLICRELATE type alias
instead and that is allowed to go in a different catalog (see OA52218). ...
And to this end catalog should support specifying SYMBOLICRELATE with no
need to have an actual substitutable symbol in the alias name. That would
eliminate the need for (some of) the extra work.
Not for the OP's problem. He wants to define most of his data sets in a Usercat,
but those that are in LNKLST, he wants to define in the Master Catalog. He
could create an alias in the master using SYMBOLICRELATE, but he cannot
include that alias in the LNKLST.
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-05-01 19:50:43 UTC
Permalink
On Tue, May 1, 2018 at 2:47 PM, Tom Marchant <
Post by Tom Marchant
Post by AlanWatthey , GMAIL
Post by AlanWatthey , GMAIL
However, with a bit of extra work you can use SYMBOLICRELATE type alias
instead and that is allowed to go in a different catalog (see OA52218).
...
Post by AlanWatthey , GMAIL
And to this end catalog should support specifying SYMBOLICRELATE with no
need to have an actual substitutable symbol in the alias name. That would
eliminate the need for (some of) the extra work.
Not for the OP's problem. He wants to define most of his data sets in a Usercat,
but those that are in LNKLST, he wants to define in the Master Catalog. He
could create an alias in the master using SYMBOLICRELATE, but he cannot
include that alias in the LNKLST.
​Hum, now you _can_ do that -- have a DSN on the LNKLST in a UCAT without
specifying the VOLSER in the PROGnn member. But __ONLY IF__ you do a
SETPROG after IPL which creates a new LNKLST to be used by address spaces
which start _after_ the SETPROG is done. This does not help with LPA
modules or with modules which need to be available (perhaps via IEFSSN)
earlier in the IPL.​
Post by Tom Marchant
--
Tom Marchant
--
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Gibney, Dave
2018-05-01 21:28:17 UTC
Permalink
I hate to add to the complexity. I don't like the OP's naming plans/conventions at all.

But, he can have what he wants. It is the IPL time linklst that isn't going to have such fancy thigs and access to usercats available. He can IPL with a minimal, perhaps even IBM only LPA/LINKLST/APF and then, once the system is far enough up that that full catalog services are available, use SETPROG to "enhance" these resources.

I am not saying this is a good idea, although I have considered using this idea in a more limited manner for a couple ISV's
Post by Sankaranarayanan, Vignesh
-----Original Message-----
On Behalf Of Tom Marchant
Sent: Tuesday, May 01, 2018 12:47 PM
Subject: Re: [EXTERNAL] Re: IEFA107I when pointing to dataset alias
On Tue, 1 May 2018 10:37:37 -0500, Paul Gilmartin
Post by Sankaranarayanan, Vignesh
Post by AlanWatthey , GMAIL
However, with a bit of extra work you can use SYMBOLICRELATE type alias
instead and that is allowed to go in a different catalog (see OA52218). ...
And to this end catalog should support specifying SYMBOLICRELATE with
no need to have an actual substitutable symbol in the alias name. That
would eliminate the need for (some of) the extra work.
Not for the OP's problem. He wants to define most of his data sets in a
Usercat, but those that are in LNKLST, he wants to define in the Master
Catalog. He could create an alias in the master using SYMBOLICRELATE, but he
cannot include that alias in the LNKLST.
--
Tom Marchant
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Sankaranarayanan, Vignesh
2018-05-02 03:10:49 UTC
Permalink
Hi Dave,

I wouldn’t dare change the structuring at this point without fully understanding why it is the way it is; which may very well be because of something that happened twenty years ago.

– Vignesh
Mainframe Infrastructure

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave
Sent: Wednesday 02-May-2018 03:00
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IEFA107I when pointing to dataset alias

I hate to add to the complexity. I don't like the OP's naming plans/conventions at all.

But, he can have what he wants. It is the IPL time linklst that isn't going to have such fancy thigs and access to usercats available. He can IPL with a minimal, perhaps even IBM only LPA/LINKLST/APF and then, once the system is far enough up that that full catalog services are available, use SETPROG to "enhance" these resources.

I am not saying this is a good idea, although I have considered using this idea in a more limited manner for a couple ISV's
Post by Sankaranarayanan, Vignesh
-----Original Message-----
On Behalf Of Tom Marchant
Sent: Tuesday, May 01, 2018 12:47 PM
Subject: Re: [EXTERNAL] Re: IEFA107I when pointing to dataset alias
On Tue, 1 May 2018 10:37:37 -0500, Paul Gilmartin
Post by Sankaranarayanan, Vignesh
Post by AlanWatthey , GMAIL
However, with a bit of extra work you can use SYMBOLICRELATE type alias
instead and that is allowed to go in a different catalog (see OA52218). ...
And to this end catalog should support specifying SYMBOLICRELATE with
no need to have an actual substitutable symbol in the alias name.
That would eliminate the need for (some of) the extra work.
Not for the OP's problem. He wants to define most of his data sets in
a Usercat, but those that are in LNKLST, he wants to define in the
Master Catalog. He could create an alias in the master using
SYMBOLICRELATE, but he cannot include that alias in the LNKLST.
--
Tom Marchant
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

MARKSANDSPENCER.COM
________________________________
Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Gibney, Dave
2018-05-02 08:13:25 UTC
Permalink
Well, you can't (to the best of my knowledge) use things depending on user catalogs at the time that the IPL LPA or Linklst are built. And the name in the APF list has to be the real name on the volume.

I don't know the effect of STEPLIBing a job or STC via an non-VSAM alias to a dataset that is correctly APF authorized by it's real name. I think that should actually work.

Playing post IPL games with SETPROG might get you what you want, but will be need additional attention maintaining the Commands and likely be more prone to error.
Post by Sankaranarayanan, Vignesh
-----Original Message-----
Behalf Of Sankaranarayanan, Vignesh
Sent: Tuesday, May 01, 2018 8:12 PM
Subject: Re: [EXTERNAL] Re: IEFA107I when pointing to dataset alias
Hi Dave,
I wouldn’t dare change the structuring at this point without fully
understanding why it is the way it is; which may very well be because of
something that happened twenty years ago.
– Vignesh
Mainframe Infrastructure
-----Original Message-----
On Behalf Of Gibney, Dave
Sent: Wednesday 02-May-2018 03:00
Subject: Re: [EXTERNAL] Re: IEFA107I when pointing to dataset alias
I hate to add to the complexity. I don't like the OP's naming
plans/conventions at all.
But, he can have what he wants. It is the IPL time linklst that isn't going to
have such fancy thigs and access to usercats available. He can IPL with a
minimal, perhaps even IBM only LPA/LINKLST/APF and then, once the
system is far enough up that that full catalog services are available, use
SETPROG to "enhance" these resources.
I am not saying this is a good idea, although I have considered using this idea
in a more limited manner for a couple ISV's
Post by Sankaranarayanan, Vignesh
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-
On Behalf Of Tom Marchant
Sent: Tuesday, May 01, 2018 12:47 PM
Subject: Re: [EXTERNAL] Re: IEFA107I when pointing to dataset alias
On Tue, 1 May 2018 10:37:37 -0500, Paul Gilmartin
Post by Sankaranarayanan, Vignesh
Post by AlanWatthey , GMAIL
However, with a bit of extra work you can use SYMBOLICRELATE type alias
instead and that is allowed to go in a different catalog (see OA52218). ...
And to this end catalog should support specifying SYMBOLICRELATE with
no need to have an actual substitutable symbol in the alias name.
That would eliminate the need for (some of) the extra work.
Not for the OP's problem. He wants to define most of his data sets in
a Usercat, but those that are in LNKLST, he wants to define in the
Master Catalog. He could create an alias in the master using
SYMBOLICRELATE, but he cannot include that alias in the LNKLST.
--
Tom Marchant
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
MARKSANDSPENCER.COM
________________________________
Marks and Spencer plc
Waterside House
35 North Wharf Road
London
W2 1NW
Registered No. 214436 in England and Wales.
Telephone (020) 7935 4422
Facsimile (020) 7487 2670
www.marksandspencer.com
Please note that electronic mail may be monitored.
This e-mail is confidential. If you received it by mistake, please let us know
and then delete it from your system; you should not copy, disclose, or
distribute its contents to anyone nor act in reliance on this e-mail, as this is
prohibited and may be unlawful.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John Eells
2018-05-02 12:43:40 UTC
Permalink
Post by Sankaranarayanan, Vignesh
Hi Dave,
I wouldn’t dare change the structuring at this point without fully understanding why it is the way it is; which may very well be because of something that happened twenty years ago.
For testing stuff like this, ZONECOPY can be your friend. Make a copy
of the zone. Play with things like UCLIN, ZONEEDIT, etc. to your
heart's content and see what happens. But don't use the copy to
actually install anything (that is, no APPLY or ACCEPT), since the
intent is "play with it now, delete it afterward." Right after the
ZONECOPY, a ZONEEDIT to point the DDDEFs in to Outer Space before
playing with things further is not a terrible idea, in fact.
--
John Eells
IBM Poughkeepsie
***@us.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Bruce Hewson
2018-05-02 05:02:12 UTC
Permalink
This post might be inappropriate. Click to display it.
Tom Marchant
2018-05-02 13:41:09 UTC
Permalink
Post by Gibney, Dave
Well, you can't (to the best of my knowledge) use things depending on
user catalogs at the time that the IPL LPA or Linklst are built. And the
name in the APF list has to be the real name on the volume.
True, but the APF list entries include the volume serial on which the data
set resides, or they specify "SMS". In either case, the catalog entries are
not needed at IPL time, so APF listed data sets can be cataloged in a
user catalog.
Post by Gibney, Dave
I don't know the effect of STEPLIBing a job or STC via an non-VSAM
alias to a dataset that is correctly APF authorized by it's real name.
I think that should actually work.
It does.
Post by Gibney, Dave
Playing post IPL games with SETPROG might get you what you want,
but will be need additional attention maintaining the Commands and
likely be more prone to error.
I wouldn't call it "games". I have created a new LNKLST set after IPL
and it works quite well. There is no reason the OP couldn't create a
PROGxx member that contains, for example,

LNKLST DEFINE NAME(ADD.USERCAT.DS) COPYFROM(CURRENT)
LNKLST ADD NAME(ADD.USERCAT.DS) DSNAME(B.LOAD)
LNKLST ACTIVATE NAME(ADD.USERCAT.DS)

and issue SET PROG=xx. From then on, any new address space
uses the new LNKLST set, and have the added library available.

I would expect that the system is up far enough for this to work
correctly at the time COMMNDxx members are processed, so
that the SET PROG=xx command can be in COMMNDxx. I don't
know if my expectation would be correct.

Note that as coded above, the ADD puts the data set at the
bottom of the LNKLST. You can put it somewhere else.
--
Tom Marchant
Post by Gibney, Dave
Post by Sankaranarayanan, Vignesh
-----Original Message-----
Behalf Of Sankaranarayanan, Vignesh
Sent: Tuesday, May 01, 2018 8:12 PM
Subject: Re: [EXTERNAL] Re: IEFA107I when pointing to dataset alias
Hi Dave,
I wouldn’t dare change the structuring at this point without fully
understanding why it is the way it is; which may very well be because of
something that happened twenty years ago.
– Vignesh
Mainframe Infrastructure
-----Original Message-----
On Behalf Of Gibney, Dave
Sent: Wednesday 02-May-2018 03:00
Subject: Re: [EXTERNAL] Re: IEFA107I when pointing to dataset alias
I hate to add to the complexity. I don't like the OP's naming
plans/conventions at all.
But, he can have what he wants. It is the IPL time linklst that isn't going to
have such fancy thigs and access to usercats available. He can IPL with a
minimal, perhaps even IBM only LPA/LINKLST/APF and then, once the
system is far enough up that that full catalog services are available, use
SETPROG to "enhance" these resources.
I am not saying this is a good idea, although I have considered using this idea
in a more limited manner for a couple ISV's
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-05-02 16:13:24 UTC
Permalink
Post by Tom Marchant
True, but the APF list entries include the volume serial on which the data
set resides, or they specify "SMS". In either case, the catalog entries are
not needed at IPL time, so APF listed data sets can be cataloged in a
user catalog.
How do you build the DEB for the link list when LNKAUTH=APFTAB is specified if the volume serial is not specified and the data set is cataloged in a user catalog?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Tom Marchant <0000000a2a8c2020-dmarc-***@listserv.ua.edu>
Sent: Wednesday, May 2, 2018 9:42 AM
To: IBM-***@listserv.ua.edu
Subject: Re: [EXTERNAL] Re: IEFA107I when pointing to dataset alias
Post by Tom Marchant
Well, you can't (to the best of my knowledge) use things depending on
user catalogs at the time that the IPL LPA or Linklst are built. And the
name in the APF list has to be the real name on the volume.
True, but the APF list entries include the volume serial on which the data
set resides, or they specify "SMS". In either case, the catalog entries are
not needed at IPL time, so APF listed data sets can be cataloged in a
user catalog.
Post by Tom Marchant
I don't know the effect of STEPLIBing a job or STC via an non-VSAM
alias to a dataset that is correctly APF authorized by it's real name.
I think that should actually work.
It does.
Post by Tom Marchant
Playing post IPL games with SETPROG might get you what you want,
but will be need additional attention maintaining the Commands and
likely be more prone to error.
I wouldn't call it "games". I have created a new LNKLST set after IPL
and it works quite well. There is no reason the OP couldn't create a
PROGxx member that contains, for example,

LNKLST DEFINE NAME(ADD.USERCAT.DS) COPYFROM(CURRENT)
LNKLST ADD NAME(ADD.USERCAT.DS) DSNAME(B.LOAD)
LNKLST ACTIVATE NAME(ADD.USERCAT.DS)

and issue SET PROG=xx. From then on, any new address space
uses the new LNKLST set, and have the added library available.

I would expect that the system is up far enough for this to work
correctly at the time COMMNDxx members are processed, so
that the SET PROG=xx command can be in COMMNDxx. I don't
know if my expectation would be correct.

Note that as coded above, the ADD puts the data set at the
bottom of the LNKLST. You can put it somewhere else.

--
Tom Marchant
Post by Tom Marchant
Post by Sankaranarayanan, Vignesh
-----Original Message-----
Behalf Of Sankaranarayanan, Vignesh
Sent: Tuesday, May 01, 2018 8:12 PM
Subject: Re: [EXTERNAL] Re: IEFA107I when pointing to dataset alias
Hi Dave,
I wouldn’t dare change the structuring at this point without fully
understanding why it is the way it is; which may very well be because of
something that happened twenty years ago.
– Vignesh
Mainframe Infrastructure
-----Original Message-----
On Behalf Of Gibney, Dave
Sent: Wednesday 02-May-2018 03:00
Subject: Re: [EXTERNAL] Re: IEFA107I when pointing to dataset alias
I hate to add to the complexity. I don't like the OP's naming
plans/conventions at all.
But, he can have what he wants. It is the IPL time linklst that isn't going to
have such fancy thigs and access to usercats available. He can IPL with a
minimal, perhaps even IBM only LPA/LINKLST/APF and then, once the
system is far enough up that that full catalog services are available, use
SETPROG to "enhance" these resources.
I am not saying this is a good idea, although I have considered using this idea
in a more limited manner for a couple ISV's
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-05-03 12:33:25 UTC
Permalink
Post by Seymour J Metz
Post by Tom Marchant
True, but the APF list entries include the volume serial on which the data
set resides, or they specify "SMS". In either case, the catalog entries are
not needed at IPL time, so APF listed data sets can be cataloged in a
user catalog.
How do you build the DEB for the link list when LNKAUTH=APFTAB is specified if
the volume serial is not specified and the data set is cataloged in a user catalog?
If you have a link list containing data sets cataloged in a user catalog, and the
volume serial is not specified in the link list specification, that link list must have
been created after IPL when user catalogs are available.
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-05-03 15:21:11 UTC
Permalink
That was my point; if you need it at IPL time and it's cataloged in a user catalog, you need an explicit volume serial.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Tom Marchant <0000000a2a8c2020-dmarc-***@listserv.ua.edu>
Sent: Thursday, May 3, 2018 8:34 AM
To: IBM-***@listserv.ua.edu
Subject: Re: [EXTERNAL] Re: IEFA107I when pointing to dataset alias
Post by Seymour J Metz
Post by Tom Marchant
True, but the APF list entries include the volume serial on which the data
set resides, or they specify "SMS". In either case, the catalog entries are
not needed at IPL time, so APF listed data sets can be cataloged in a
user catalog.
How do you build the DEB for the link list when LNKAUTH=APFTAB is specified if
the volume serial is not specified and the data set is cataloged in a user catalog?
If you have a link list containing data sets cataloged in a user catalog, and the
volume serial is not specified in the link list specification, that link list must have
been created after IPL when user catalogs are available.

--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-05-03 18:04:38 UTC
Permalink
Post by Seymour J Metz
That was my point; if you need it at IPL time and it's cataloged in a user catalog, you need an explicit volume serial.
I'm (slowly) coming to grasp that. At IPL time, the CAS is not initialized and
user catalogs can not be searched. So data sets needed during IPL must either
be catalogued in the master cat or accessed by explicit volume serial.

But in the case that impacted me many years ago, I wanted both the alias and
the related DSN in different user cats. I didn't need either during IPL (not my
job) and in user cats they couldn't be accessed during IPL. It still disconcerts me
that after CAS initialization a user cat can't be searched for the alias and the HLQ
of that alias could not identify a possibly different user cat to search for the
related DSN.

(Ih another case I would have found it useful to have an alias of an alias. That,
also, should be supported.)

--gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-05-03 18:14:39 UTC
Permalink
On Thu, May 3, 2018 at 1:06 PM, Paul Gilmartin <
Post by Seymour J Metz
Post by Seymour J Metz
That was my point; if you need it at IPL time and it's cataloged in a
user catalog, you need an explicit volume serial.
I'm (slowly) coming to grasp that. At IPL time, the CAS is not initialized and
user catalogs can not be searched. So data sets needed during IPL must either
be catalogued in the master cat or accessed by explicit volume serial.
But in the case that impacted me many years ago, I wanted both the alias and
the related DSN in different user cats. I didn't need either during IPL (not my
job) and in user cats they couldn't be accessed during IPL. It still disconcerts me
that after CAS initialization a user cat can't be searched for the alias and the HLQ
of that alias could not identify a possibly different user cat to search for the
related DSN.
(Ih another case I would have found it useful to have an alias of an alias. That,
also, should be supported.)
--gil
​This is disconcerting to me too. But I can envision what might be
happening. The logic to me would be something like:

1) Find catalog in which A.B.C exists according to the standard search order
2) Read entry for A.B.C in that catalog​.
3) If alias, find the base related-to entry in the catalog.

This reminds me a bit of BPAM. Suppose you have member A, but not B, in
PDS1. Now suppose you have B in PDS2 as an alias to A (in PDS2). If you ask
for member B then you get A in PDS2, not the PDS1 version. Granted, I don't
think that BPAM actually uses the A entry in PDS2 for anything when you
reference B, but I can easily be wrong. I'm speaking conceptually. The way
you & I want it to work is like a UNIX symlink (which can traverse to
another filesystem), but it is working more like a hard link (which cannot
span filesystems).
--
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-05-04 15:36:10 UTC
Permalink
An alias entry in a PDS directory doesn't point to the base name, it points to the actual member. And, yes, I know about load modules, but what the link editor/binder puts in the user halfwords doesn't count.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of John McKown <***@GMAIL.COM>
Sent: Thursday, May 3, 2018 2:16 PM
To: IBM-***@listserv.ua.edu
Subject: Re: [EXTERNAL] Re: IEFA107I when pointing to dataset alias

On Thu, May 3, 2018 at 1:06 PM, Paul Gilmartin <
Post by Seymour J Metz
Post by Seymour J Metz
That was my point; if you need it at IPL time and it's cataloged in a
user catalog, you need an explicit volume serial.
I'm (slowly) coming to grasp that. At IPL time, the CAS is not
initialized and
user catalogs can not be searched. So data sets needed during IPL must
either
be catalogued in the master cat or accessed by explicit volume serial.
But in the case that impacted me many years ago, I wanted both the alias
and
the related DSN in different user cats. I didn't need either during IPL
(not my
job) and in user cats they couldn't be accessed during IPL. It still
disconcerts me
that after CAS initialization a user cat can't be searched for the alias
and the HLQ
of that alias could not identify a possibly different user cat to search
for the
related DSN.
(Ih another case I would have found it useful to have an alias of an
alias. That,
also, should be supported.)
--gil
​This is disconcerting to me too. But I can envision what might be
happening. The logic to me would be something like:

1) Find catalog in which A.B.C exists according to the standard search order
2) Read entry for A.B.C in that catalog​.
3) If alias, find the base related-to entry in the catalog.

This reminds me a bit of BPAM. Suppose you have member A, but not B, in
PDS1. Now suppose you have B in PDS2 as an alias to A (in PDS2). If you ask
for member B then you get A in PDS2, not the PDS1 version. Granted, I don't
think that BPAM actually uses the A entry in PDS2 for anything when you
reference B, but I can easily be wrong. I'm speaking conceptually. The way
you & I want it to work is like a UNIX symlink (which can traverse to
another filesystem), but it is working more like a hard link (which cannot
span filesystems).


--
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Dan D
2018-05-05 14:59:59 UTC
Permalink
A very long time ago (over 30 years ago) I worked for a service bureau.\
They had specific naming standards for their libraries when products were installed (ie. SYSx.product.V01R03.LOADLIB).

We couldn't have our customers continually changing JCL unless they wanted a different version than what was installed so we created a system tool called "Virtual Dataset Names".

This worked very similar to how ALIAS names works although there was no "must be in the same catalog" restriction.

When the system was IPL'd (or later via a special operator command) a table was loaded into CSA that contained the REAL dataset name, the VIRTUAL name and the various versions that were available. One of the versions was marked as the default.
We used the IGG026DU catalog front-end exit (which I believe is now used by DFSMSHSM) to intercept catalog lookups and replace the REAL name that is being located with the VIRTUAL name. It would scan SWA and check if an ACCT= was specified on the EXEC statement. If so, the 1st operand was used to overriding VERION for all datasets within that step.
Example:
//step50 exec pgm=iefbr15,ACCT=V5R3
//DD1 dd dsn=sys1.sortlib,disp=shr
If SYS1.SORTLIB is in the table and it's virtual name is PROD.?.SORTLIB and it had a list of versions, V1R0 being the alias, DD1 would be translated to PROD.V5R3.SORTLIB as ACCT=V5R3 was specified. If it wasn't DD1 would be PROD.V1R0.SORTLIB.

Our customers loved this as they could test NEW versions of products before they became the default.

If someone has the time, maybe they could take on this project and re-write this cool tool ;-)

Dan

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mike Schwab
2018-05-05 18:44:23 UTC
Permalink
IBM did a one test library addition for PDSE for COBOL 5
Post by Dan D
A very long time ago (over 30 years ago) I worked for a service bureau.\
They had specific naming standards for their libraries when products were installed (ie. SYSx.product.V01R03.LOADLIB).
We couldn't have our customers continually changing JCL unless they wanted a different version than what was installed so we created a system tool called "Virtual Dataset Names".
This worked very similar to how ALIAS names works although there was no "must be in the same catalog" restriction.
When the system was IPL'd (or later via a special operator command) a table was loaded into CSA that contained the REAL dataset name, the VIRTUAL name and the various versions that were available. One of the versions was marked as the default.
We used the IGG026DU catalog front-end exit (which I believe is now used by DFSMSHSM) to intercept catalog lookups and replace the REAL name that is being located with the VIRTUAL name. It would scan SWA and check if an ACCT= was specified on the EXEC statement. If so, the 1st operand was used to overriding VERION for all datasets within that step.
//step50 exec pgm=iefbr15,ACCT=V5R3
//DD1 dd dsn=sys1.sortlib,disp=shr
If SYS1.SORTLIB is in the table and it's virtual name is PROD.?.SORTLIB and it had a list of versions, V1R0 being the alias, DD1 would be translated to PROD.V5R3.SORTLIB as ACCT=V5R3 was specified. If it wasn't DD1 would be PROD.V1R0.SORTLIB.
Our customers loved this as they could test NEW versions of products before they became the default.
If someone has the time, maybe they could take on this project and re-write this cool tool ;-)
Dan
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Sankaranarayanan, Vignesh
2018-05-06 04:17:40 UTC
Permalink
That. Is. Excellent!

– Vignesh
Mainframe Infrastructure

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Dan D
Sent: Saturday 05-May-2018 20:31
To: IBM-***@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IEFA107I when pointing to dataset alias

A very long time ago (over 30 years ago) I worked for a service bureau.\ They had specific naming standards for their libraries when products were installed (ie. SYSx.product.V01R03.LOADLIB).

We couldn't have our customers continually changing JCL unless they wanted a different version than what was installed so we created a system tool called "Virtual Dataset Names".

This worked very similar to how ALIAS names works although there was no "must be in the same catalog" restriction.

When the system was IPL'd (or later via a special operator command) a table was loaded into CSA that contained the REAL dataset name, the VIRTUAL name and the various versions that were available. One of the versions was marked as the default.
We used the IGG026DU catalog front-end exit (which I believe is now used by DFSMSHSM) to intercept catalog lookups and replace the REAL name that is being located with the VIRTUAL name. It would scan SWA and check if an ACCT= was specified on the EXEC statement. If so, the 1st operand was used to overriding VERION for all datasets within that step.
Example:
//step50 exec pgm=iefbr15,ACCT=V5R3
//DD1 dd dsn=sys1.sortlib,disp=shr
If SYS1.SORTLIB is in the table and it's virtual name is PROD.?.SORTLIB and it had a list of versions, V1R0 being the alias, DD1 would be translated to PROD.V5R3.SORTLIB as ACCT=V5R3 was specified. If it wasn't DD1 would be PROD.V1R0.SORTLIB.

Our customers loved this as they could test NEW versions of products before they became the default.

If someone has the time, maybe they could take on this project and re-write this cool tool ;-)

Dan

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

MARKSANDSPENCER.COM
________________________________
Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-05-06 19:34:35 UTC
Permalink
That may have been cool long ago in a galaxy far away, but after the advent of static system symbols it became unnecessary complexity. Not worth getting rid of if you're already doing it, but it's not the way to go for a new data center.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Dan D <***@GMAIL.COM>
Sent: Saturday, May 5, 2018 11:01 AM
To: IBM-***@listserv.ua.edu
Subject: Re: IEFA107I when pointing to dataset alias

A very long time ago (over 30 years ago) I worked for a service bureau.\
They had specific naming standards for their libraries when products were installed (ie. SYSx.product.V01R03.LOADLIB).

We couldn't have our customers continually changing JCL unless they wanted a different version than what was installed so we created a system tool called "Virtual Dataset Names".

This worked very similar to how ALIAS names works although there was no "must be in the same catalog" restriction.

When the system was IPL'd (or later via a special operator command) a table was loaded into CSA that contained the REAL dataset name, the VIRTUAL name and the various versions that were available. One of the versions was marked as the default.
We used the IGG026DU catalog front-end exit (which I believe is now used by DFSMSHSM) to intercept catalog lookups and replace the REAL name that is being located with the VIRTUAL name. It would scan SWA and check if an ACCT= was specified on the EXEC statement. If so, the 1st operand was used to overriding VERION for all datasets within that step.
Example:
//step50 exec pgm=iefbr15,ACCT=V5R3
//DD1 dd dsn=sys1.sortlib,disp=shr
If SYS1.SORTLIB is in the table and it's virtual name is PROD.?.SORTLIB and it had a list of versions, V1R0 being the alias, DD1 would be translated to PROD.V5R3.SORTLIB as ACCT=V5R3 was specified. If it wasn't DD1 would be PROD.V1R0.SORTLIB.

Our customers loved this as they could test NEW versions of products before they became the default.

If someone has the time, maybe they could take on this project and re-write this cool tool ;-)

Dan

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-05-05 18:10:45 UTC
Permalink
Post by Dan D
A very long time ago (over 30 years ago) I worked for a service bureau.\
They had specific naming standards for their libraries when products were installed (ie. SYSx.product.V01R03.LOADLIB).
We couldn't have our customers continually changing JCL unless they wanted a different version than what was installed so we created a system tool called "Virtual Dataset Names".
This worked very similar to how ALIAS names works although there was no "must be in the same catalog" restriction.
...
Our customers loved this as they could test NEW versions of products before they became the default.
If someone has the time, maybe they could take on this project and re-write this cool tool ;-)
Damn! That "must be in the same catalog" restriction creates a lot of otherwise needless
work. It should be relaxed.

(How much does JCLLIB help nowadays?)

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-05-05 22:28:26 UTC
Permalink
Post by Mike Schwab
IBM did a one test library addition for PDSE for COBOL 5
Details (or citation)? Is this a facility peculiar to COBOL? PDSE only, or old-fashioned PDS?
Post by Mike Schwab
Post by Dan D
A very long time ago (over 30 years ago) I worked for a service bureau.\
They had specific naming standards for their libraries when products were installed (ie. SYSx.product.V01R03.LOADLIB).
We couldn't have our customers continually changing JCL unless they wanted a different version than what was installed so we created a system tool called "Virtual Dataset Names".
This worked very similar to how ALIAS names works although there was no "must be in the same catalog" restriction.
When the system was IPL'd (or later via a special operator command) a table was loaded into CSA that contained the REAL dataset name, the VIRTUAL name and the various versions that were available. One of the versions was marked as the default.
We used the IGG026DU catalog front-end exit (which I believe is now used by DFSMSHSM) to intercept catalog lookups and replace the REAL name that is being located with the VIRTUAL name. It would scan SWA and check if an ACCT= was specified on the EXEC statement. If so, the 1st operand was used to overriding VERION for all datasets within that step.
//step50 exec pgm=iefbr15,ACCT=V5R3
//DD1 dd dsn=sys1.sortlib,disp=shr
If SYS1.SORTLIB is in the table and it's virtual name is PROD.?.SORTLIB and it had a list of versions, V1R0 being the alias, DD1 would be translated to PROD.V5R3.SORTLIB as ACCT=V5R3 was specified. If it wasn't DD1 would be PROD.V1R0.SORTLIB.
Our customers loved this as they could test NEW versions of products before they became the default.
If someone has the time, maybe they could take on this project and re-write this cool tool ;-)
-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...