OK, so it's clear that you have some malfunctioning startup code.
By way of introduction, V5.5 is a fossil version, and long out of support. Your "VAX 3100" — unfortunately no such model exists, which means this is probably a VAXstation 3100, MicroVAX 3100, or VAXserver 3100 of some sort — is also very old, and a number of these are failing. There are probably a dozen different models across those three VAX series, too. None of these details likely particularly matter here (yet), as this problem is probably secondary to a hardware error — that is, unless somebody's been modifying the startups since this system was last rebooted and this stuff was restarted and was working, and has gone and broken something.
The writeable shareable image stuff is usually for what's known as a common and it's fairly common with older programming styles and older languages, and it's basically a spot where some site-specific application is storing some information in memory. (Using a writeable shareable for this is an old and inflexible technique, but it does still work.)
This writeable shareable is installed by a product-specific startup procedure invoked from SYSTARTUP_VMS.COM or occasionally from some other startup-related procedure or tool, or the writeable shareable might be installed directly from within the OpenVMS system startup procedure SYSTARTUP_VMS.COM itself. (Details here vary by product and site, so there's no specific recipe for how this stuff gets installed and started, nor for troubleshooting this stuff.)
In this particular case, there's probably something leading up to that startup procedure and that installation that's failing, or there's a failure in the startup that's causing the necessary startup procedure here to be omitted. With old gear, that's usually a disk that's failed, or some other hardware, though there are many other potential triggers for a failed startup procedure.
Troubleshooting: tou can boot that VAX conversationally and set STARTUP_P2 to enable startup logging, and that will provide a detailed command trace of the startup output. There'll be a lot of data logged into that STARTUP.LOG file, too. You'll probably find that a disk or some other hardware related to this particular application is not available due to a glitch or due to a failure, given the fossil vintage of this gear, though there could be other errors shown in the log if somebody's been modifying the startups. Look through this startup log data after the boot completes, and particularly search for the error messages and filenames that you've reported, then work backwards to the trigger.
As was mentioned upthread, it's probably going to be far more efficient for y'all to get yourself an escalation path for these sorts of OpenVMS questions, as these are pretty easy for an experienced OpenVMS system manager to resolve, but they're definitely a confusing mess for somebody that hasn't been around and working with OpenVMS for, um, too many years. This can also get somebody to have a look at whether the backups are working and are likely able to be restored, or if there are other latent software or hardware errors within the configuration. (Full disclosure: I and various other folks posting here can and variously do provide these services.)
