System setup not working

[odwillia]

One of the programmers for my company contacted me with the attached issue. I'm hoping someone can help me with this. Not entirely sure if this an OS issue or not. We are using OpenVMS V7.2-2.
Thanks in advance.

[Hein van den Heuvel · Accepted solution]

This is NOT an OS issue, but striclty and only an application setup issue.

>> %DCL-W-ACTIMAGE, error activating image DBEXE:DB_BLD_AFFECTED_RPT_EXTR
>> -CLI-E-IMGNAME, image file DPA301:[PROD.DATABASE.][EXE_AXP]DB_BLD_AFFECTED_RPT_EXTR.EXE;
-RMS-E-DNF, directory not found

So the logical name DBEXE is wrongly defined, or it's target was deleted:

DBEXE appaers to be defined as:

something:[EXE_AXP]

Check with $SHOW LOG DBEXE/full

The 'something' is _likely_, but not certainly 'DB$ROOT'

It is probably in turn defined as

DPA301:[PROD.DATABASE.]

Do a $SHOW LOG for that as well.

The next commands I would issues would be:

$DIR DPA301:[PROD.DATABASE.000000]

and

$DIR DPA301:[*...]DB_BLD_AFFECTED_RPT_EXTR.*

Good luck!
Hein.

[Hoff]

As Hein writes, this is not an "OS issue".

I see Uniface and multi-version Rdb here, which means there can be a mildly involved set-up for the various applications; the environments require various set-up to get to the database. There's a second-level here, with local logical names to get to the production tools. Looks to have Alpha and probably has or had VAX systems around. And it's that set-up which is going off the rails here.

This case looks to require some DCL-level debugging. Starting with what is probably the most obvious course of investigation, I'd start the quest with what the programmer changed here, and particularly look for errors or for cases where DCL was exiting prematurely due to an error. A DIFFERENCES of the old and new DCL procedures, for instance. That'll probably narrow down the areas to investigate. A key search target would be for the DBEXE logical name; that's clearly caught in an area of the DCL environment that's not being set up correctly here.

I'd also look to set up a specific release sequence and a release command procedure, rather than editing files in what I infer to be the production DBCOM: directory. Hand-editing production files tends to lead to problems, in my experience. Regressions can become commonplace, where production and development don't match.

Finding out why a production node would have a link-related logical name (lnk$library) would be worth a look, too. In various production environments, LINK operations (which implies source code builds are aso occurring) is comparatively unusual.

Stephen Hoffman
HoffmanLabs LLC

[DECxchange]

Hello,
This does not an OS issue. It looks like you have a logical, naybe a rooted logical definition defined incorrectly. What is the logical ODIN? Why are you using the assign command for this logical but define command for all the rest (it may not matter anyway, just curious). Also, what is the command that defines DBCOM? This could be a place to look. You might also need to do some DCL command file debugging.