1748036 Members
5050 Online
108757 Solutions
New Discussion юеВ

Re: Patch question

 
SOLVED
Go to solution
Rich Hearn
Regular Advisor

Patch question


Hi all,

OVMS83A_SYS-1000 has a "temporary fix" in place for an Intersystem's app problem stating that it will be removed when corrected - to quote:

"This is a temporary workaround for customers until the underlying problem can be corrected. Once this is done, this change will be removed."

How do I know when it's been removed? (I've found no other references to Intersystem in any of the .txt files in the 8.3 patch dir) Is this change still in OVMS83A_SYS-1600? How I know when it's been removed? Do I still need it? (I do run Intersystems Cach├й on my Alpha)

Thanks ,
Rich
19 REPLIES 19
John Gillings
Honored Contributor

Re: Patch question

Rich,

I'd suggest you ask Intersystems.

My interpretation of what you've posted is that OpenVMS has implemented a workaround to protect you against a problem in Intersystems software (interesting, as I don't recall ever seeing any fix like that in any previous OpenVMS patches). Once Intersystems has fixed their problem, and distributed the fixed software to customers (like you), some future OpenVMS patch will reverse whatever temporary fix they've implemented.

On the other hand, I'd guess that whatever they have done must be fairly benign, as the SYS patch will most likely be installed on far more systems without the Intersystems software than those that have it.

A crucible of informative mistakes
Rich Hearn
Regular Advisor

Re: Patch question


John,

Thanks for the response, tho'I'm still a bit unclear on this.

"Once Intersystems has fixed their problem, and distributed the fixed software to customers (like you), some future OpenVMS patch will reverse whatever temporary fix they've implemented."

How can I tell if that "future OpenVMS patch" has been issued or not? Does one assume the patch is is all versions of SYS until another SYS patch readme.txt *explicitly* states it's been removed?

Thanks for your thoughts,
Rich
Bob Blunt
Respected Contributor

Re: Patch question

The specific text of the release notes:

5.2.3 UNABLCREVA Bugcheck

5.2.3.1 Problem Description: When stopping and starting Intersystem's Cache database product, a fatal "UNABLCREVA, Unable to create virtual address space" bugcheck may occur. The change in this kit makes the UNABLCREVA bugcheck non-fatal. This is a temporary workaround for customers until the underlying problem can be corrected. Once this is done, this change will be removed.

Images Affected:

- [SYS$LDR]EXCEPTION.EXE

- [SYS$LDR]EXCEPTION.STB

- [SYS$LDR]EXCEPTION_MON.EXE

- [SYS$LDR]EXCEPTION_MON.STB

Image details for the EXCEPTION.EXE image from the VMS83A_SYS-V1000 kit:

o [SYS$LDR]EXCEPTION.EXE (new image)

Image Identification Information

image name: "EXCEPTION"
image file identification: "X-5"
image file build identification: "XBCA-0080070066"
link date/time: 29-OCT-2008 14:07:47.53
linker identification: "A13-03"
Overall Image Checksum: 534129896

$ ana/image/inter sys$ldr:exception.exe
to check for the image header information to check which file your system is running. The subsequent kit, VMS83A_SYS-V1100, has a different EXCEPTION.EXE but the latest VMS83A_UPDATE-Vxxxx kit info I have seems to still have the EXCEPTION.EXE listed here.

John's right, Intersystems should know if they've fixed their part. I hope that VMS Engingineering has been informed by Intersystems if it has. HOWEVER, having all the customers running the right Intersystems code in synch with the right OpenVMS/Alpha version AND the right EXCEPTION.EXE could be like trying to identify ball bearings blindfolded while wearing gloves. Put another way, who knows when all the cards will align.
Volker Halle
Honored Contributor

Re: Patch question

Rich,

a word of warning: NOTHING in this text states, that this a problem in the Cache code ! This is your interpretation of this text. It could also be an OpenVMS code problem - which is being triggered by cache database shutdown - for which an immediate solution could not be easily implemented in OpenVMS !

I have seen and reported this problem in MAY-2008 on OpenVMS I64 V8.3. HP had delivered a solution (patched image). The problem had happened again in SEP-2008 with V8.3-1H1 and all patches current at that time.

VMS831HI_SYS-V0300 had then been released on 3-DEC-2008 - with a 'workaround' to make this bugcheck non-fatal.

So you best ask HP about this.

Volker.
Volker Halle
Honored Contributor

Re: Patch question

Rich,

looks like you've found another patch regression !

VMS83A_SYS-V1000 contains EXCEPTION.EXE linked 29-OCT-2008. VMS83A_SYS-V1100 contains the same image - that's o.k. All the UPDATE patches also contain this image, that's fine, but...

But all the subsequent VMS83A_SYS-Vnn00 patches (-V1200 up to -V1600) do - according to the release notes - NOT contain EXCEPTION.EXE. That is NOT allowed, as all patches MUST BE CUMULATIVE !

There was another fix in EXCEPTION.EXE (case QXCM1000830697) in VMS83A_SYS-V1000, which now seems to be 'lost' as well !

Please log a call with HP !

Volker.
Volker Halle
Honored Contributor

Re: Patch question

Rich,

I just checked: VMS83A_SYS_V1600 does NOT contain EXCEPTION.EXE, so this IS A REGRESSION !

Volker.
H.Becker
Honored Contributor

Re: Patch question

As far as I know, this is an Integrity only problem. So the answer is: no, you do not need it to run Intersystems Cache on an Alpha.
Rich Hearn
Regular Advisor

Re: Patch question


Well, nothing like "stiring the pot" - eh?


Bob,

Thanks for the text of the exception. I had been through it which is what prompted my question. I've tried to check all the ovms83*.txt's for "UNABLCREVA","QXCM...","WFM...", "Intersystem" - no avail to finding anything *reliably* indicating it was/was not included in their respective patches. "EXCEPTION.EXE" & "X-5" also did not prove to be a reliable indicator either.

I don't have any EXCEPTION.EXE's anywhere on the systems, so I'm assuming the patch never found it's way to my systems.

Until John mentioned it, I never thought that Intersystems code could cause OVMS to Crash with a stop command - I always thought the Kernel "ring" would prevent that. If it did allow it, I thought that would be an OVMS fix regardless of Intersystems code.


Volker,

I'm running Cache 5.0.21 on a 2 node Alpha OVMS 8.3 (SYS v6.0) cluster (ES47's) - what version are/were you running on integrity when you saw the problem. The last time I had my systems "down" was for the time change for last fall.

Thank you for checking and finding the REGRESSION - I will be submitting a case after I finish here.


Mr Becker,

Unfortunately, I can't chance finding out "the hard way" that this *does* apply to more than just integrity servers. The IDX folks were the ones to tell me about this, but they didn't know if it was more than integrity servers either, so I need to find out so there's no problems on a "go live" date for an upgrade their doing.

Thanks though,
Rich
Volker Halle
Honored Contributor

Re: Patch question

Rich,

I had seen this crash on a customer system. I don't know what version of Cache they were running. An OpenVMS software crash is always a problem, that has to be escalated to HP. And so I did...

Believe me, you do have an EXCEPTION.EXE in SYS$LOADABLE_IMAGES: - it's a basic execlet of OpenVMS, the system won't boot very far without it ;-)

You can trust H.Becker.

You should still raise a call to HP about this 'mess'. And hope to get confirmation about the facts found out here.

Volker.