Operating System - OpenVMS

ADU BUILD issue integrity

Go to solution
sathya prabu

ADU BUILD issue integrity

Hi All,

i have few cdo records in a logical path(process) and few CDOs in logical path(system). the Task Group file has to use CDOs from both locations. Both the locations have the same logical name except that for each process and system level point to different physical paths.
When i do a adu build for the GDF file, the CDOs must be found by the ADU utility from the both the paths and the TDB should be built properly. this is not happening. always the other system path CDOs directory is not being identified. I tried using a process level logcal for both the physical paths together and also with the job level logical also. i also verified the logical order, for which is searched first.
Please help me how to make the ADU identify the CDOs in the path that is in the system logical.

the error message is something like "not able to find the object or dictionary..." type CDD$RECORD..
Hein van den Heuvel
Honored Contributor

Re: ADU BUILD issue integrity

Hold on... that's all mumbo jumbo to most readers.
The missing key word being ACMS.

- Did it used to work? What changed?
- Versions / Platforms ?
- 'something like' doesn't cut it when trying to resolve what is likely to be a subtle problem.

There is only one default root in effect. It follows the 'first' logical name, typically being a process one. If the application needs something from a different root, then it will have to be explicit about that.

If this used to work and stopped then my WAG is the a middle fragment in in a dictionary path suddenly became eligible for a logical name translation, due to adding a new logical.
Best I recall the CDD+ will translate each component, which can come as a surprise.

My crude tools of choice if I had to figure this out without knowing enough to reason my way out from the top?
Start at the bottom: $ SET WATCH FILE/CLA=MAJOR + ANAL/SYSTEM... LNM TRACE ... /ID=pid-for-adu
See where it is actually going and compare with where you though it should be.

Hope this helps a little,

sathya prabu

Re: ADU BUILD issue integrity

Hi Hein,

That definitely helped me figure out what exactly is going on. but i am still not able to get the ADU build the task group DB.

Sorry for 'something like', please find the actual error below when built in IA64,
PO>adu build group tg.01/userlib=xyzlib
%ADU-E-ERRFNDNOD, error finding object 'XYZ_ABC_WKSP.XYZ_WKSP', type 'CDD$RECORD'
-CDD-E-NODNOTFND, directory or object not found

where XYZ_ABC_WKSP is the logical for the CDO workspace path and the XYZ_WKSP is the actual workspace.

i have defined(process) XYZ_ABC_WKSP to two paths,
1-> to the local CDO dictionary i have created and few workspaces i defined.
2-> the original system level defined path i just copied and used.
sathya prabu

Re: ADU BUILD issue integrity


Just one more query.
Can the records from two different CDO repositories can be used in the same path?

vivek choudhary
New Member

Re: ADU BUILD issue integrity


The ADU default is always the same as that of the CDO. It is always good practice to define all the tasks and records in one directory and make that as default directory. As far as using of two different paths is concerned we can use logical cdd$default to make available our choice of record to ADU. ADU at a time can only have one path and hence the records defined in different paths need to be made available to ADU and this can be done by changing the defaults of cdd by using logical cdd$default. AS per the query yes, the records from different cdo repositories can be used but for that we need to adjust our cdd$default logical again and again.

sathya prabu

Re: ADU BUILD issue integrity

Thank you vivek,

That helped me to get the job done.

sathya prabu

Re: ADU BUILD issue integrity