ABS command results just complaint about missing sys$share:abc$ussshr_84.exe. And indeed the entire ABS kit does not contain such image. It sure contains
I.e said image for older versions. Of course ABS V4.5 predates actually OpenVMS V8.4 so that is way but
why then is ABS claimed to be ok with OpenVMS V8.4.
Even latest DEC 2011 conold ABS does not offer any better.
Whilst just merely copying ABS$USSSHR_83.EXE to ABS$USSSHR_84.EXE allowed succesful invokation of ABS and maybe even the actual backups will be succesful...
As you have found, renaming the image will get things going again. The other option would be to reinstall ABS.
An ABS install would always create corresponding ABS$USSSHR_<OS-VERSION> images. Creating an image with OS version became a standard practice on account of the contents that make up this image. This image especially will contain kernel mode routines.
So you might think this implies all VMS upgrades require ABS be reinstalled. This is not necessarily so, it's all a matter of ABS qualification against VMS version. If ABS is qualified for the first time on the OS version, then it requires reinstallion of ABS.
For example, in case of ABS 4.5(1201) release, it has been qualified with OpenVMS version 8.4. No earlier releases of ABS were qualified on 8.4. In such cases, it would require the reinstallion of ABS.
ABS 4.5(1200) is not a new qualification of ABS on OpenVMS version 8.3. And that's the reason why ABS 4.5 (1200) works fine by just renaming the image.
How do I identify these different ABS kits with the same version number; how do I identify the 1200 versus 1201 baselevels from the installed environment, other than seeing it blow up, or by scrounging through the installed files?
Inferred from this whole thread, there isn't an generic error handler built into the ABS image activation path to contend with these missing images after a VMS upgrade, and to provide the end-user with information on an ABS update or a workaround that might be available for end-users that have upgraded VMS and run into this case?
It's also somewhat odd that the kernel-mode components of this package haven't been migrated into and incorporated into base OpenVMS; that this package hasn't followed DECwindows, Disk Encryption or the DECram RAMdisk software, and been partially or completely rolled into the base OS distribution. DECwindows started out with this "split kit" design, and has the version-dependent portions tied into the VMS distribution, and the version-independent portion is installed separately.
it would seem feasible for an ABS$USSSHR image (with no VMS version, or maybe with an ABS-API-based version) to be rolled into the base OpenVMS kit. (It looks to be three years or so (Kittson-era) before V8.next arrives per the available presentations, so there's probably some time to fit this image and this change into the V8.next work, and into the ABS kits.)
Re "How do I identify these different ABS kits with the same version number; how do I identify the 1200 versus 1201 baselevels from the installed environment, other than seeing it blow up, or by scrounging through the installed files?"
BLONDY> abs show version Version of SYS$LIBRARY:ABS$SHR.EXE is ABSV4.5(1200) Version of ABS$USSSHR is ABSV4.5(1200) Version of SYS$SYSTEM:ABS$COORDINATOR.EXE is ABSV4.5(1200) Version of SYS$SYSTEM:ABS$DCL.EXE is ABSV4.5(1200) Version of SYS$SYSTEM:ABS$UBS.EXE is ABSV4.5(1200)
