CA Jclchk 12.0 isn't able by default to expand a GDG relative dsname level to the corresponding GDG absolute name.
For example, if in a jcl there is a // DD referencing a GDG level as DSN=CNTR.EOBJ.FOBJECTI(0), the !JCK command on this jcl is not able to expand this dsname as something looking like CNTR.EOBJ.FOBJECTI.GxxxxV00 (the same happens also in a batch scan of the jcl).
One of our customers submitted an idea asking for CA JCLCheck being able to expand the GDG relative dsname levels when !JCK is executed and to detail this in a new message evidencing the GDG absolute dsname level.
Z/OS - JCLCheck 12.0
The idea has been accepted and Test APAR ST03870 has been developed and tested successfully by the customer.
With this apar applied a new message, CAY6572I, is being added to display the resolved G????V00 name for GDG datasets.
The 572 message can be suppressed unwanted using MCO or the other message control methods.
Sample of the new message:
CAY6572I GDG Resolved Name: 'GDG.DSN.NAME.G????V00'
Here a sample output from !JCK command with the Test APAR applied:
.AAABE //DDE DD DISP=SHR,DSN=EHMLG.AAFIA.AAFICOUR(0)
==MSG> //DDE DD DISP=SHR,DSN=EHMLG.AAFIA.AAFICOUR(0)
==MSG> CAY6572I GDG RESOLVED NAME: "EHMLG.AAFIA.AAFICOUR.G0003V00"
The correction is still in Test as ST03870, so it is not available in SupportOnline for download and it should be requested to CA Support opening a Case, but it has been confirmed by the customer so it will be published as GA in next weeks and the name will be SO03870, according to our naming conventions.