search path to activate a shared image?

[gaspar2013]

I buid a program and shared images linked to it in a particular directory,

say DISK$PROG3:[PGMAGJ.EDA4.DBG]

When I run the program, the shared images cannot be found by the image activator.

I know that it is looking for them in the logical SYS$SHARE which is defined in the SYSTEM_TABLE as follows:

"SYS$SHARE" = "SYS$SYSROOT:[SYSLIB]" (LNM$SYSTEM_TABLE)

So knowing that a logical can be defined as multivalued search path, I redefined SYS$SHARE in the PROCESS_TABLE by appending my directory to the old value of SYS$SHARE as follows:

DEFINE SYS$SHARE SYS$SYSROOT:[SYSLIB],DISK$PROG3:[PGMAGJ.EDA4.DBG]

show log sys$share
   "SYS$SHARE" = "SYS$SYSROOT:[SYSLIB]" (LNM$PROCESS_TABLE)
        = "DISK$PROG3:[PGMAGJ.EDA4.DBG]"
   "SYS$SHARE" = "SYS$SYSROOT:[SYSLIB]" (LNM$SYSTEM_TABLE)

Then my program can be run fine, and the image activator finds all the shared images.

My program also succeeded to programmatically activate one of my shared images calling LIB$FIND_IMAGE_SYMBOL().

QUESTION:

Is this method OK?

Can I rely on re-defining SYS$SHARE in the PROCESS_TABLE in order to tell the image activator where to find the images it needs to load?

[John Gillings]

Obviously what you're doing is working, but it's maybe a bit too much of a sledgehammer. Consider, are you going to extend the search list for every shareable image you want to use? Do you want all images in your directory to be reachable by name alone?

In general it's best not to redefine anything with a SYS$ prefix.

The usual approach for shareable images is to define a single logical name for your shareable image in the table appropriate to your expected users.

For example:

$ DEFINE YOURIMAGE DISK$PROG3:[PGMAGJ.EDA4.DBG]YOURIMAGE

My general rule with shareable images is to only ever refer to them by the name alone "YOURIMAGE" at all stages - compile, link, activate and runtime (LIB$FIND_IMAGE_SYMBOL). Rely on a logical name to add the path.

The above definition is in the process table (default for DEFINE). You could use a LOGIN or initialisation procedure to define the same logical name in the process table of each process you want to be able to activate the image, or, use a higher level table if there are many users. Perhaps the GROUP table, or even SYSTEM or CLUSTER to give your image wider visibility.

If you have many images, and want to grant access to a select set of users, not necessarily in the same UIC group, you may choose to create a shareable logical name table, populated with your shareable image logical names, and link it into the process search path for target processes (redefine LNM$FILE_DEV in LNM$PROCESS_DIRECTORY)

[H.Becker]

>In general it's best not to redefine anything with a SYS$ prefix.

Really, no more redefinition of sys$output, sys$error or even sys$input? :-)

>Is this method OK?

>Can I rely on re-defining SYS$SHARE in the PROCESS_TABLE in order to tell the image activator where to find the images it needs to load?

Yes. It is even sufficient to define this in user mode (/user) just before running the main image.  In case of a few shareable images I would rearrange the order, my directory first and then the VMS one. Whether this is approach is better or worse than defining logicals for every single image looks debatable to me. But what do I know, I even redefine sys$scratch :-)

And yes, you can't by accident overlay an important VMS shareable image that way.

[gaspar2013]

Using logicals is especially inconvenient for the following reasons:

1. I have many shared images (several hundred).

2. Any shared image, say ABC.EXE, may have been linked with another one of my shared images at build time, say XYZ.EXE.

3. In my development environment I have 2 altenative directories where the shared images can be located, one is a common public directory that every developer sees, and the other is an individual private directory, where a given programmer rebuilds only the specific shared images that are needed. Between test runs, the set of shared images that exist in the private directory may vary.

Therefore, re-defining SYS$SHARE with the 2 alternative directories in the proper order seems to work fine with the image activator first picking up my private images if they exist, and otherwise it picks up the public ones.

In order to succeed with logicals, I need to have 1 logical for every shared image, and I need to re-create them before each run of my program so that the full path to all shared images is refreshed.

QUESTION:

If defining SYS$SHARE as a search path is a legal alternative, has this alternative not been properly and explicitly documented perhaps?

[abrsvc]

Negative to the re-assigning logicals all the time. If you set up a logical name table for each programmer, changing the order in which logical name tables are searched can be used. In this fashion, the logical names always exist.

I support a product that makes use of this technique all the time. We have 2 logical name tables (Production and test). By changing the definition of LNM$JOB to be a search list of the "local" table followed by the JOB table, the specific definitions we require are used first. Changing environments becomes siimply a re-define of the LNM$JOB logical name only.

I had hoped to present a session on how this works with a real-life example at the bootcamp, but I won't be around this year for it.

I will resurrect my presentation notes and try an post a more detailed example.

Dan

[John McL]

gaspar2013, I take your point about redefining SYS$SHARE being an easy alternative to having a logical name for each shareable image.  I work in a similar software environment and we do have logical names defined at /SYSTEM for every shareable image.  The big advantage is that the logicals can easily be redefined /PROCESS if we want to test a new or newly modified shareable.

To create your widely used logicals just write a simple looping command procedure that does a wildcard F$SEARCH, uses F$PARSE to extract the NAME part, sets up the equivalent value then uses $ DEFINE/SYS before looping back for the next file.

To redefine the logical for "private" use, just modify your local 'build' command procedure - I assume that you have one to make life easy - by adding $DEFINE/NOLOG/PROCESS on the newly created file. 

[H.Becker]

> To redefine the logical for "private" use, just modify ...

With sys$share re-defined as a search list to find the application images you can still define a logical to point to a specific - test - image and the image activator will activate that and not the one from the search list.

[gaspar2013]

merging strategies ...

Would the following approach be OK?

(it actually worked in my preliminary tests)

1. Define a multivalued logical MYSHRPATH with the search path for the image activator:

DEFINE MYSHRPATH SYS$SHARE,DISK$PROG3:[PGMAGJ.EDA4.DBG]

2. Define logicals for all images using MYSHRPATH at the beginning:

DEFINE ABC MYSHRPATH:ABC.EXE

DEFINE XYZ MYSHRPATH:XYZ.EXE

Note that all logicals are created in the PROCESS_TABLE.

This alternative avoids redefining SYS$SHARE,

but also avoids creating additional shared logical name tables.

[gaspar2013]

Actually I defined MYSHRPATH with both the private path and the public path as follows:

DEFINE MYSHRPATH SYS$SHARE,DISK$PROG3:[PGMAGJ.EDA4.DBG],R729999W:[R729999W.DBG]

...

and the image activator found the private image ABC.EXE before the public one as desired.

[gaspar2013]

Thanks to all for your input and technical observations.