I do not understand what, precisely, is meant by the following:
| It seem the first time the DBC starts and the $490TRIG is run
A DBC address space is an MVS Started Task.
$490TRIG (as far as I know) is a batch JOB.
"Allocate" is an overloaded term. To some it means "define, allocate SPACE for, and create, and usually catalog" a data set. While that process is a typical (and usually non-confusing connotation), it is not technically correct. "Allocate" (per se) is what happens when a DD statement (or the equivalent SVC 99 Dynamic Allocation) is processed and an entry is made into the TIOT of some address space. Technically, "allocate" does not (or should not) imply "creation" or (since we are talking about a VSAM LINEAR Data Set) "definition" (i.e., IDCAMS DEFINE). Now it is possible to both DEFINE and ALLOCATE a VSAM data set in a DD statement [with DISP=(NEW,CATLG)], but as far as I am aware the DBC Started Task (STC) does not "DEFINE" its Registry repository Backing VLDS -- it merely dynamically allocates it [meaning that DYNALLOC / SVC 99 looks the base CLUSTER name up in the catalog to discover on which VOLumes it is cataloged, and then creates a TIOT entry for that data set, which DBC can then use as the Backing VLDS for its product Registry repository]. The DEFINE (creation and cataloging) of this Backing VLDS was done much earlier, perhaps even long ago [as far as I know], by the batch JOB that gets customized as JOB and member name $490TRIG.
The bottom line is that I assume that $490TRIG is run once, and once only, to DEFINE the Backing VLDS for the NGL Registry.
| I wonder why it can allocate the registry in teh first place
| and why it doesn't alloc it dynamically the second time.
It does attempt to dynamically allocate the Backing VLDS CLUSTER given its DSNAME [in NLGPIID?]. But the DBC STC does not DEFINE (create and catalog) the NGL Registry's Backing VLDS (the VSAM LINEAR CLUSTER). It _only_ ALLOCATES it (in the strict, technical sense of MVS allocation).
If you want to change the DSNAME of the Backing VLDS used for an NGL Registry, you can do so, but you will need to DEFINE it (using a JCL DD statement, or IDCAMS DEFINE). You will probably want to copy the contents of the OLD or former Backing VLDS into the new one (so you don't lose anything). The best way to do that is using the OSZRGTBR utility of RTCS, but it you do not need to enlarge the SPACE defined for the Backing VLDS, you could also simply use IDCAMS REPRO.
The NGL registry is defined automatically as well as dynamically allocated by DBC.
But this of course works only the first time, when DBC comes up.
There is no DD statement anymore in DBC.
When changing the name of the NGL registry in order to be compliant with local nam
ing standards,one has to run a job.
I wanted to shre the job which needs to be run with the community:
BMC recommends using the RD data set name that the installation creates for you.
If you change the data set name for the RD keyword in the NGLpiid member, you must ensure that the data set name is unique and allocate the data set using the SAMP member NGLREGDF. No current registry data will be migrated.