GetJPI, instaklled image: no version?

[Willem Grooters]

OpenVMS 8.3H1-1

We run an interactive image that needs to restart when a new version is available, without the users to take action themselves.
In general, it's a meny tree, the leaves being the actions to be executed.

My thought has been:

* Get the full spec of the running image $GETJPIW, item code JPI$_IMAGE, when the image is started, and retrieve the version number.
* at the end of the menu, before starting the actual function to be executed, compare this version against the version of disk. If different, save choices in a symbol, and restart the program, extracting and executing the saved choices.
This works fine, when the image is run directly from disk.

However, since the image is used by many users, it has been installed /HEADER/SHARED.
Now GETJPI doesn't return a version number.

Second, it's not the version on disk that needs to be looked at. What's more inmportant is to know what version of the image is installed; this check is done at start to find out the version of the current image, and before executing functions to find out if it's the same one as now running.

In DCL, it's not a real problem:
$ INSTALL LIST :[]image.exe
and handle the output. But executing this in a subprocess may be a problem since users run the image from captive accounts (though they have sufficient privs to execute the INSTALL command) and because of the impact, I'd like to prevent this.

Is there a way to get this information by other means from within the execuatble?
If privileged code can be avoided, that would be nice (and preferred).

[Hein van den Heuvel · Accepted solution]

Hello Wim,

While the GETJPI IMAGNAME route sounds promissing I suspect you'll end up digging yourself in deeper and deeper.

Why not just have a system (or group) logical name holding an ident (could equal version, or a date and time or just a word ). When the program starts, read the logical and assume that the image just started matches that logical.
Coming back from a menu leaf, re-read the logical and compare. If different then restart, whether it is higher or lower.
When a new image is provided, after it is installed, set a new value as ident to trigger user processes to pick it up.

KISS.

Regards,
Hein.

[Hoff]

The installed image activation path largely bypasses the file- and version-related processing; that's more or less the point of it all, after all.

I'd first look to get rid of the version specification when the executable is launched, and trump the whole discussion. It'll pick up the installed version, or the most current version available if there's no installed version.

And yes, version tracking is the way to go. that can be done based on file version numbers (which is more cryptic and more prone to errors, but certainly functional), or based on a directory path, or based on the filename; the directory path and the filename typically involving a logical name for the "live" version.

The logical name here being a variant of what Hein is referring to in his reply.

Oracle Rdb uses a variation of this approach for its multi-version support.

The other and more complex) option is to set this up akin to a DVCS or a job control mechanism and have the client ask for the image, and have a central dispatcher provide the context.

The dispatcher-like approach might be using a "shim" image in the user context, and have a connection to the appropriate server process(es); getting as much as feasible out of the UI context, and into servers that can be running on any of a pool of servers on the host, or on the network.

OpenVMS doesn't have these sorts of tools, so you end up writing them or acquiring them.

[Hein van den Heuvel]

Hoff>> The logical name here being a variant of what Hein is referring to in his reply.

Right, just be aware that what would appear to be the simplest approach does NOT work, when installed images should be used.
Defining a logical name with the image to run including a version number will instruct the system not to use the installed images.
So it will work, but not the way you wanted it to.

For an alternative _installed_ image to be used, you'll have to make its name differ somewhere outside the version. Either using a different directory, or file name.
For example test_123.exe instead of test.exe;123. This could get a little messy over time.

That's why I suggested the 'indirection' of using a secondary logical as flag.

Oh, and once you are running an installed image, the GETJPI will keep returning the same string for imagname whether you uninstall, or rename to different file or directory or not.
LIB$FID_TO_NAME could give you the current name, but with a good bit of work for the system.

groetjes,
Hein.

[Willem Grooters]

Thanks for your suggestions and explanations, it made things clear.
To complete the story: After the question was raised and I started to investigate the solution, it became clear it didn't need to be that 'difficult':
Given the way the image is placed into production (Copy it to the production environment and immediately INSTALL the new version) it may be assumed that the image started will be the one with the highest version on disk, when it askes for the filespecification. So if the program does not receive a version number by GETJPI, it could search for the same file on disk, with version ;0, giving it the highest version number. It may be wrong in some cases but none is found problematic (these cases will be exceptional, and probably be expected).

The only problem I got is when all files are deleted, and even the installed file is removed from disk (I guess this file will be 'marked for deleteion' and be actually deleted when no references are left. However, the file remains 'installed').
If all processes have exited the image, the program can no longer be started; even if it is still know as an installed (shared) image. I guess this behaviour is to be expected.

If you don't have that guarantee, the solution using logicals is quite useful. But you could do without

[Willem Grooters]

In this particular case, it's not a problem to rely on RMS version numbers, but in other environments it could cause problems.
So I have another question/solution.
It is possible to force an ident into an executable during LINK. On Alpha and Itanium, you can specify IDENT=, on Itanium you specify BUILD_OPTION the same way *though it seems to be 'reserved for HP' - I wonder why.
It is possible to retrieve this information and store it somewhere so the program can find out (via the logicals that Hein and Hoff talked about). It would be even nicer if that information could be retrieved from the running image directly, by itself; regardless if it's installed, or not.

Just curiousity: Can an imaghe analyze itself and get the information, and from files on disk without running ANALYZE/IMAGE? (I doubt the latter)

[Hoff]

So implement a restart flag? That sort of run-time control also ties into getting a good and consistent backup of open files, and other assorted and sundry maintenance issues.

For some applications, this test would occur at the top of whatever passes for a main loop.

With applications that "sweep" a data file for some particular task, that would involve waiting, or would lead to a checkpoint-restart design.

Traditional OpenVMS image management and the open-file mechanisms are comparatively simple (as you're finding), but you can build and can get where you want. Included in the omissions here is a lack of any facilities for updating applications and images.

Stuffing everything behind a comparatively simple UI tool can be a helpful approach here, as it hides the housekeeping, and it also means you can collect crash data and restart and such after crashes.

[Zeni B. Schleter]

If I understand the problem correctly , someone outside of the menu will be in control of deploying and installing the image. The menu just needs to know whether a new image has been deployed. Seems like a system logical of your choice defining a unique string would be captured in a process symbol or logical at the beginning and then compared at the end against the system-controlled logical to inform it to restart.

-zbs

[Willem Grooters]

All true, and food for thought.

Indeed, as stated, it's all about:
* Finding out what identification the image has when starting
* Finding out what version is considered 'current', at a convenient location.

No matter what way. This environment is happy with useing the RMS version, in other cases symbols, system, or group logicals would be more convenient.

And there will be more to consider: Don't delete installed files, for instance, and deplpyment of new versions. But that is left for another occasion.

Thanks all for your thoughts.

[Jess Goodman]

You asked:
"I have another question/solution.
It is possible to force an ident into an executable during LINK. On Alpha and Itanium, you can specify IDENT=, on Itanium you specify BUILD_OPTION the same way *though it seems to be 'reserved for HP' - I wonder why.
It is possible to retrieve this information ... from the running image directly, by itself; regardless if it's installed, or not."

I have no idea how to do that on Itanium, but my attached Macro32 routine can do it on Vax and Alpha. It is called with one argument (address of a quadword) and it returns in it the current image ident as a counted string. Must LINK with /SYSEXE on Alpha.