JCL 'SYMBOLS=' vs. IDCAMS SYMBOLICRELATE

[Steve Horein]

I am in the process of building JCL to distribute resources across several
images. I've been leveraging 'SYMBOLS=' in JCL to assist in that capacity.
I've now come to a point where some conditional processing takes place, and
I am using IDCAMS IF-THEN logic to determine whether to ALTER - NEWNAME and
ALIAS - RELATE data set names to relieve GRS contention in certain
situations. The NEWNAME contains a system symbolic, which sparked the
memory of previously using SYMBOLICRELATE when it came to strategically
relating ALIAS entries.

Which lead me to wonder - will SYMBOLICRELATE functionality eventually go
away due to redundancy with the more flexible IAZSYMBL JES symbol service
being available?

Have folks switched their methods/practices?

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

[John Eells]

Post by Steve Horein
I am in the process of building JCL to distribute resources across several
images. I've been leveraging 'SYMBOLS=' in JCL to assist in that capacity.
I've now come to a point where some conditional processing takes place, and
I am using IDCAMS IF-THEN logic to determine whether to ALTER - NEWNAME and
ALIAS - RELATE data set names to relieve GRS contention in certain
situations. The NEWNAME contains a system symbolic, which sparked the
memory of previously using SYMBOLICRELATE when it came to strategically
relating ALIAS entries.
Which lead me to wonder - will SYMBOLICRELATE functionality eventually go
away due to redundancy with the more flexible IAZSYMBL JES symbol service
being available?

<snip>

As the person who got the Catalog/VSAM team to create SYMBOLICRELATE
some time ago, *I* certainly do not want it to go away, and I doubt very
much that it will go away.

The reason we created it was to make volumes containing things like
subsystem data sets portable to help with software migration. Put a
usercat on the volume, named using the volume serial, use SYMBOLICRELATE
for the alias, IMPORT CONNECT the catalog, and create or update a system
symbol with the volume label. In addition, this can make volumes with,
for example, VSAM data sets portable. If you use a rotating set of
volume labels, it doesn't take much work to make the right levels of
like-named data sets available when you replace one of these volumes.

That people found other uses for this function is a serendipitous byproduct.

[Tom Marchant]

This post might be inappropriate. Click to display it.

[Steve Horein]

On Thu, Oct 5, 2017 at 6:54 AM, Tom Marchant <

Post by Tom Marchant
SYMBOLICRELATE is very different from using symbolic substitution in
IDCAMS control statements. The former is done dynamically every time
the alias is referenced. The latter at the time the alias or data set name
is defined. When you define an alias with SYMBOLICRELATE, you can
change the value assigned to the symbol and every reference to that
alias will then pick up the new name.
Furthermore, with SYMBOLICRELATE, you can have an alias in a catalog
that is shared across a sysplex and different MVS images in the sysplex
can use that alias to refer to different data sets simply by having a
different value assigned to the symbol. You can't do that with symbolic
substitution in the IDCAMS control statements.
In addition, a normal alias must be defined in the same catalog that holds
the related data set name. With SYMBOLICRELATE, that is not a requirement.
--
Tom Marchant

Ah yes!
I forgot about the dynamic nature of SYMBOLICRELATE. I guess with
leveraging symbolic substitution lately to retool distribution of resources
across several sysplexes and many systems, symbolic substitution appeared a
tad more shiny. The final resting places for the data sets don't require
periodic changes, but if they did, having both tools in the toolbox (and
knowing when to use the right one!) can certainly come in handy.

Thanks Mr. Marchant!

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

[Paul Gilmartin]

Post by John Eells
As the person who got the Catalog/VSAM team to create SYMBOLICRELATE
some time ago, *I* certainly do not want it to go away, and I doubt very
much that it will go away.
...
That people found other uses for this function is a serendipitous byproduct.

At some point I opened an SR on an unexpected error when I used SYMBOLICRELATE.
Support replied that the problem was that I had no symbols in my alias. But
though z/OS 2.1, the IDCAMS Ref. says:
SYMBOLICRELATE(entryname)
Allows the specification of the base data set name using system symbols. ...
"Allows" is permissive, not restrictive. I insisted that there was a bug needing
repair.

Alas, in z/OS 2.3 IDCAMS Ref. I see:
SYMBOLICRELATE(entryname)
Requires the specification of the base data set name using system symbols.

"Allows" became "Requires". All too characteristic of IBM to document a deficiency
rather than repairing it.

Sigh,
gil

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

[John Eells]

Post by Paul Gilmartin

Post by John Eells
As the person who got the Catalog/VSAM team to create SYMBOLICRELATE
some time ago, *I* certainly do not want it to go away, and I doubt very
much that it will go away.
...
That people found other uses for this function is a serendipitous byproduct.

At some point I opened an SR on an unexpected error when I used SYMBOLICRELATE.
Support replied that the problem was that I had no symbols in my alias. But
SYMBOLICRELATE(entryname)
Allows the specification of the base data set name using system symbols. ...
"Allows" is permissive, not restrictive. I insisted that there was a bug needing
repair.
SYMBOLICRELATE(entryname)
Requires the specification of the base data set name using system symbols.
"Allows" became "Requires". All too characteristic of IBM to document a deficiency
rather than repairing it.

As the author of the original requirement, and an approver of the
original design, I can assure you that the deficiency you identified was
in the documentation and not in the code. You can blame me, if you
wish, for crafting a requirement that led to behavior you found
astonishing and failing to identify the miswording during review; but,
as far as I am concerned, the Level 2 and ID teams acted appropriately.
The code was and is working as designed, and it meets the requirement
it was written to satisfy.

That someone might want to use it differently than we intended did not
cross our minds at the time, but sometimes our crystal ball is cloudy.

There is, as others have said here, nonzero cost (and risk) to extending
functions on a whim, and it's hard to see how this extension would
survive prioritization. Nonetheless, you are always welcome to open an
RFE and ask.

[Tom Marchant]

Post by Paul Gilmartin
I opened an SR on an unexpected error when I used SYMBOLICRELATE.
Support replied that the problem was that I had no symbols in my alias. But
SYMBOLICRELATE(entryname)
Allows the specification of the base data set name using system symbols. ...
"Allows" is permissive, not restrictive. I insisted that there was a bug needing
repair.
SYMBOLICRELATE(entryname)
Requires the specification of the base data set name using system symbols.
"Allows" became "Requires". All too characteristic of IBM to document a deficiency
rather than repairing it.

If the intent when designing SYMBOLICRELATE was that symbols could be used but were not required, then it was a bug. If the intent was that SYMBOLICRELATE requires at least one symbol, then it is the doc that was in error.

[Jesse 1 Robinson]

Ask and ye shall receive. Just not necessarily what you were hoping for.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Thursday, October 05, 2017 9:20 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: JCL 'SYMBOLS=' vs. IDCAMS SYMBOLICRELATE

Post by John Eells
As the person who got the Catalog/VSAM team to create SYMBOLICRELATE
some time ago, *I* certainly do not want it to go away, and I doubt
very much that it will go away.
...
That people found other uses for this function is a serendipitous byproduct.

At some point I opened an SR on an unexpected error when I used SYMBOLICRELATE.
Support replied that the problem was that I had no symbols in my alias. But though z/OS 2.1, the IDCAMS Ref. says:
SYMBOLICRELATE(entryname)
Allows the specification of the base data set name using system symbols. ...
"Allows" is permissive, not restrictive. I insisted that there was a bug needing repair.

Alas, in z/OS 2.3 IDCAMS Ref. I see:
SYMBOLICRELATE(entryname)
Requires the specification of the base data set name using system symbols.

"Allows" became "Requires". All too characteristic of IBM to document a deficiency rather than repairing it.

Sigh,
gil


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