Error activating image ...

[H.Becker]

> in case the image activator reports the wrong image name

As far as I can see, the error shows in relocation of a shareable image. At that time the reported image name is correct. An incorrect image name may be reported in processing after mapping and relocating all the images. Then the last mapped image name is printed for any error and that may not be correct.

[labadie_1]

Hein

>>>You have to have CMKRNL privs to use it.

Unless this has changed, you need CMEXEC to use it, which is not a highest privilege as CMEXEC (which quickly givess you all the privileges)

[Hein van den Heuvel]

Right, I guess it's 'just' CMEXEC that's needed, but that is still the same as 'all' in my book.

__int64 all=-1;
int args[] = { 4,1,(int)&all), 1, 0 };
sys$cmexec (&sys$setprv, args);

Hein.

[John McL]

Could it be a physical memory fault and this job at midnight, with its specific job mix, just hits the wrong spot? Have you tried running your midnight batch job on the other machine?

[John Gillings]

>you need CMEXEC to use it

Klaus,
Sorry I should have posted commands to turn it on and off... As Hein showed:

$ SET WATCH/CLASS=MAJOR FILE ! ON

$ SET WATCH/CLASS=NONE FILE ! OFF

For even more verbose output use /CLASS=ALL, but for this issue MAJOR should be more than sufficient.

You need CMEXEC or CMKRNL, but if there's an issue granting privilege to the account, another option is to install the image:

$ INSTALL SYS$SYSTEM:SETWATCH /PRIVILEGE=CMKRNL

(or CMEXEC). Not much risk, as all it can do is enable or disable watch.

One caveat.. although it's been around forever, this is NOT a supported utility. Rumour has it that it can crash systems (though I've been using it for more than 20 years, and never seen a proven case). The vulnerable time is allegedly process rundown, so make sure you SET WATCH/CLASS=NONE before logging off. (that warning has been around since VAX days, so it's entirely possible that any potential bugchecks have been fixed).

[Klaus Heim]

I have changed all batch jobs and include DCL command set watch. At Friday I got the error again. The image las$cre_sh_batch.exe (foreign command cre_sh_batches) is started with different input parameters:

cre_sh_batches 901 !ok
cre_sh_batches 902 !ok
..
cre_sh_batches 918 !ok
cre_sh_batches 919 !error
cre_sh_batches 920 !error
cre_sh_batches 921 !error

See attachment for a part from the logfile.

The image syscom.exe with the file id (3483,5277,0) is a writeable common and is installed with /open/header/share/write.

The writeable image is linked to the shareable image lvsshr.exe. In the batch logfiles I've not found any reference to the file or the file id.

[H.Becker]

>>>
The image syscom.exe with the file id (3483,5277,0) is a writeable common and is installed with /open/header/share/write.

The writeable image is linked to the shareable image lvsshr.exe. In the batch logfiles I've not found any reference to the file or the file id.
<<<

That's OK, you will not find any XQP activity like open or close, because it is installed /open.

That there are writeable shareable images involved, wasn't mentioned before. Is this a pattern?

It's still not obvious what's happening. /header moves the DYNTBL into the non-paged pool. So at activation time it is not read from the image file. It looks like after the activation "ofcre_sh_batches 918 !ok" There is a corruption in the pool. However, I do not see a match with the previous entries in the thread. The last entry shows that (all?) subsequent activations fail. I was under the impression, that the next activation would succeed.

Are there other problems with/on this system with devices, drivers or even pool corruption, etc.?

[Klaus Heim]

>>>That there are writeable shareable images involved, wasn't mentioned before. Is this a pattern?

I forgot this fact. The image didn't use the writeable shareable images. These are linked to lvsshr.exe which is linked to lvs$tashr.exe. And lvs$tashr.exe is used by the image las$cre_sh_batch.exe.

>>>The last entry shows that (all?) subsequent activations fail. I was under the impression, that the next activation would succeed.

I agree. I'm also impressed. This is a relatively new batch job. This time the error occurs when the same image is started with different input parameters. In case of error this batch job will continue (set noon). The other batch jobs stop after the error case. The next activation would succeed - in an other dcl or batch environment.

>>>Are there other problems with/on this system with devices, drivers or even pool corruption, etc.?

I didn't know or see any problem. Can we monitor something? I will check the systems for errors.

[H.Becker]

It looks like this problem can't be solved in this forum. You may want to get in contact with the local HP office. There is expertise on this topic outside of HP but having access to the system, looking at the images, the whole environment seems necessary. As already said, this is not a common or known problem, it doesn't look like an image activation problem, but a person with knowledge in this area should have a close look at the system.

That said,
>>>
The image didn't use the writeable shareable images. These are linked to lvsshr.exe which is linked to lvs$tashr.exe. And lvs$tashr.exe is used by the image las$cre_sh_batch.exe.
<<<
using an image is transitive.

>>>
This time the error occurs when the same image is started with different input parameters. In case of error this batch job will continue (set noon).
<<<

With an installed image, this is expected. If the dynamic table in the non-paged pool is corrupt it will stay corrupt until the image is de-installed (manually or with a shutdown). The big question is, what happens after successfully activating the image (cre_sh_batches 918) and before trying to activate the very same images in (cre_sh_batches 919)?

[John McL]

I'm puzzled. In the log file that you included, why are images xxxx$TASHR.EXE;118 and FHSHR.EXE;159 being activated after TPSHR.EXE;5 in the successful batch job? These don't appear in the failed batch jobs that just after the reference to TPSHR.EXE;5 report a problem with image SYSCOM.EXE.

You said that LIB$FIND_IMAGE_SYMBOL wasn't being used, so surely we should see SYSCOM.EXE activated in the successful job. I think you said that one of your other images is linked against SYSCOM - why does this comment system not allow me to see the entire thread as I type this? - and my understanding is that the image should therefore be activated.

Why also do we see all the "deaccess" diagnostics in the failing jobs but not in the successful job? I also see that the deaccess diagnostics are almost in the order of activation, except for DBMSHR.EXE;7 which is deaccessed last of the 6 rather than 4th.

Does file DSA3:[xxxxLVS0.][LVSLIB]SYSCOM.EXE
have FID (76514,5,0)? It seems to be trying to access that file twice, which suggests a failure or corruption of the image activator work list. The first access to SYSCOM might be resolving the dynamic table but when it comes to the second access the image might be recognised as already present and the DYNTBL data is accesses in the already activated SYSCOM.EXE.

Have you checked for
(a) any logical names that might be pointing to incorrect images?
(b) whether any of your image names clash with system images (This shouldn't be a problem in normal situations but your crashes don't seem normal.)
(c) Is DBMSHR.EXE your own code or or from SYS$SHARE and if the second, then does its fixup vector give us any clues?

Can you get a process dump and examine the internal lists for the Image Activator and (I think) the image fixup list.

We're looking for anything odd, like duplicate FIDs or FIDs to images that we don't believe should be activated. (I'm writing this from memory of the image activation described in the Internals and data Structures book but maybe things have changed. I'm sure someone will correct me if I'm wrong!)

Finally, are you running any software like a disk defragger that might be trying to move .EXEs while you are trying to use them? There shouldn't be a problem but if we find that this software is running then try running your jobs with that other software stopped.