VMS 7.3-2 RMS V0300 Patch I need matching fix for Itanium 8.3

[Liz Ball]

In RMS-V0300 there was patch to the EDF which corrected problems with the EDIT/FDL/ANALYSIS/NOINTERACTIVE causing problems when the file was then converted. I have applied this to our Alpha servers and issue corrected.

However I have the same issue on an Itanium running VMS 8.3, anyone know of a patch which contains this fix?

Thanks

[Karl Rohwedder]

Liz,

the RMS V4.0 patch contains some hints to EDF, see here:
ftp://ftp.itrc.hp.com/openvms_patches/i64/V8.3/VMS83I_RMS-V0400.txt
The patch can be found there too.

regards Kalle

[Liz Ball]

Thanks I did see that but it didn't mention the specific issue so I haven't tried it but I will probably take a chance and do so.

[Hein van den Heuvel]

That patch kit is from 2002.
Surely any correction to EDF is rolled into OpenVMS 8.3, not that is mentions any:

http://ftp.support.compaq.com.au/patches/public/vms/axp/v7.2-2/dec-axpvms-vms722_rms-v0300--4.README

Did you actually experience a problem on IPF 8.3 or just preparing?

>> EDIT/FDL/ANALYSIS/NOINTERACTIVE

The analysis switch needs a file, but you probably have that.

>> causing problems

Please elaborate, such that future reader can judge whether they have the same problem or now.
- specific errors messages?
- do you know what is broken in the output FDL when it is broken?
- always a problem for certain input FDL's?
- What _seems_ to be the trigger?

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

[Liz Ball]

Hi,

On Alpha VMS we got the following issue through our application.
"Run-time error '-2147467259 (80004005)':

The UNIFACE operation invocation failed with return code -17, status 0 and activate error code 0: UNIFACE error -17, described as "NETERR_PIPE_BROKEN: Server is gone".

When the RMS file was converted with a known correct FDL the cluster size was amended and all was fine again.
This only seemed to occur for files around the 600,000 block size, the analysis was forcing the convert to change the cluster size.

We currently have the same issue on an Itanium but the error message is slightly different as it is using Uniface 8 rather than Uniface 7.
%CXXL-F-TERMINATE, terminate() or unexpected() called
Uniface error - 150. This is defined as "A hardware or software error occurred. Contact your Uniface representative

When I disable the edit/fdl/analysis on the overnight optimise routine then the file remains readable.

Hope this makes sense - new to this.

[Hein van den Heuvel]

>> On Alpha VMS we got the following issue through our application.
"Run-time error '-2147467259 (80004005)':

That was on the Alpha.
Did you ever get that EXACT same issue under Itanium 8.3? I suspect not, but your message suggests it does.

>> The UNIFACE operation invocation failed with return code -17, status 0 and activate error code 0: UNIFACE error -17, described as "NETERR_PIPE_BROKEN: Server is gone".

So that was a secondary error.
Supposedly the server, before going, stumbled into an RMS error and hopefully reported that in a log file. Go hunt!

>> When the RMS file was converted with a known correct FDL the cluster size was amended and all was fine again.

That makes sense and yet it does not.
Here is why.

The CLUSTER size line is IGNORED on the actual convert... (as long as it is syntactically correct).
For the Convert the BUCKET size is all that matters.

The cluster size IS used by EDIT/FDL/NOINT in combination with the input file size (through the line DATA_RECORD_COUNT) to determining that BUCKET size.

There have been issues with a large cluster size tricking EDF (EDIT/FDL) into generating a large (63) bblock bucket size.
That itself _should_ be transparent to the application, but may cause memory usage issues.

>> This only seemed to occur for files around the 600,000 block size, the analysis was forcing the convert to change the cluster size.

Bad/imprecise wording, but that's ok.

>> We currently have the same issue on an Itanium but the error message is slightly different as it is using Uniface 8 rather than Uniface 7.
%CXXL-F-TERMINATE, terminate() or unexpected() called
Uniface error - 150. This is defined as "A hardware or software error occurred. Contact your Uniface representative

>> When I disable the edit/fdl/analysis on the overnight optimise routine then the file remains readable.

- Does the EDIT/FDL and subsequent CONVERT actually work? Check that log

>> Hope this makes sense - new to this.

Close enough, but lacking detail like the difference between a working and failing FDL. I would still be interested in seeing that. Send me an Email if you prefer.

Also, overnight 'optimises' are all to often poorly implements and more often than not a waste of a (little) time and an increase (proven here) in risk.
Specifically, it is probably using an ANALYZE/RMS which can be avoided.

Supposedly this application has been running for years. So by now it shoudl know what an optimal FDL is, and leave that in place. Reduce the overnight optimize to do just the CONVERT providing a knwon to be tuned and known to be working FDL.

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

[Liz Ball]

Apologies I wrote cluster I meant bucket size!
On the Alpha this was a long standing error that had been fiddled for the last 4 months as people were assuming it was the Uniface software which was causing the problem. Our systems team installed RMS-V0300 patch for me last weekend so I will need to recreate it elsewhere to get any further log files.

On the Itanium the issue from the software point of view is exactly the same but the error messages are different due to different platform and system software.

I will email you any fdls etc when I can.
Thanks for your help.

[Liz Ball]

This is the relevant text from the Alpha patch.

5.2.5 Key Size For Keys With Multiple Segments Incorrectly Calculated

5.2.5.1 Problem Description:

EDIT/FDL failed to calculate accurate bucket sizes for files with segmented keys when executing in /nointeractive mode.

Images Affected:

- [SYSEXE]EDF.EXE

5.2.5.3 Problem Analysis:

This issue was due to EDF not taking into account multiple key segments for segmented keys. If the first key segment provided a small contribution to the total key size, the bucket size could be grossly under valued.
This correction takes into account the total key size for each key and produces output consistent with the interactive mode.

[Hein van den Heuvel]

Ok, Sounds like that would just be a performance issue and can not be expected to stop an application from functioning in and of itself. There may of course be a secondary effect.

It also sounds like it would be verifyable whether you are experiencing that very problem just from the FDL files.
And it sounds like avoidable by picking a good FDl for once and for all (untill the load changes drastically).
And it sounds like you could work around it if you had to by temporarely replace the key description with reduced one with just one (total-key-sized) segment and put the real key back just before production (convert)

I can only urge you to dig deeper for a real error message from the part of the application using the file itself.
Some (server) log file?
Start up in debug mode?...

The server did not come up for a reason, it better leave a reason why.
Contact Uniface support to explain why, if need be.

cheers,
Hein.

[Volker Halle · Accepted solution]

Liz,

look for the problem escalation numbers in the VMS732_RMS-V0300 patch:

QXCM1000251932,WFM3211338338-321

You'll find these same numbers in VMS82I_RMS-V0100 and VMS821I_RMS-V0100. In both patches, it's stated that this problem is solved in V8.3

5.2.1.4 Release Version of OpenVMS that will contain this change:

OpenVMS for Integrity Servers V8.3


Volker.