OpenVMS Cluster - SYSTEM-W-ENDOFFILE problem

[Ken USA]

Hi all:

We have a cluster of three nodes as follows:

Node-A (Alphaserver DS-10 OpenVMS 7.3-2)
Node-B (ES-40 OpenVMS 8.3)
Node-C (ES-40 OpenVMS 8.2)

We use Node-A for development and cutting release savesets.

We run tests on Node-B and Node-C. The testing includes several benchmark tests in which we create and update a database from one of the nodes and update from the other node.

We occasionally get SYSTEM-W-ENDOFFILE errors when a server attempts to read a database file that had been extended by one node and the other node tried to read.

I understand that with OpenVMS 8.3 we have 10-12 new SYSGEN parameters and among them are
GB_CACHEALLMAX (set to 50000) and
GB_DEFPERCENT (set to 35).

Are these parameters need to be changed?

Is having an 8.2/8.3 cluster with one node (8.3)having GB_CACHEALLMAX/etc affects in any way the other node's behavior with respect to updating file headers when a database file is extended?

Thank you.
-Ken

[Karl Rohwedder · Accepted solution]

I think the GB_ parameter come into play if you set the /GLOBAL_BUFFER=DEFAULT for a RMS file. If you specify numeric values, as you must do on the V7.3-2 node, they have no effect.

You know that V7/V8 is only supported for 'migration' purposes :-)


regards Kalle

[Jan van den Ende]

Ken,

>>>
Node-A (Alphaserver DS-10 OpenVMS 7.3-2)
Node-B (ES-40 OpenVMS 8.3)
Node-C (ES-40 OpenVMS 8.2)
<<<

well, I am not too surprised that it works, but OTOH, I am really not surprised by some minor glitches (after all, -W- ).

I have always been of the impression, that two-version clusters were supported "for migration only", and I have NO recollection of ANY support for 3-version variants....

just my EUR 0,02

PS. Why do you not edit "My Profile", and change your personal name to be Ken ? The CA1460725 will always be your ID anyway.

Proost.

Have one on me.

jpe

[Guenther Froehlin]

"We occasionally get SYSTEM-W-ENDOFFILE errors when a server attempts to read a database file that had been extended by one node and the other node tried to read."

Yes, so? Maybe that's what it is...your apllication tried to read beyond the current end-of-file and has - maybe - nothing to do with the extension at all.

What kind of files are these? From a database product? RMS index-sequential files?

What's the application written in? C? Which function failed with SS$_ENDOFFILE?

I don't see an issue with running multiple versions in a cluster. Not with this problem at this point of the discussion.

/Guenther

[Hein van den Heuvel]

>> We occasionally get SYSTEM-W-ENDOFFILE errors when a server attempts to read a database file that had been extended by one node and the other node tried to read.

ENDOFFILE generally means just that.

If it comes as a surprise then 1000 of 1000 times that was as a result of broken synchronization techniques between application components, sometimes based on false assumptions of database semantics.

What I am trying to say here is the you should look closely at the application first, then look again at the application, and then once again, before suspecting a problem with the Operating System.

The lack of pertinent information in the question suggest that the first steps have not yet been taken, but it could also reflect an oversimplyfication of the problem statement.

What is 'a database' for you?
This is not an OpenVMS native concept.

Are we talking about Oracle? RDBMS? MySQL?
Or does this refer to basic RMS files?
Indexed files? Sequential? Relative?
QIO access? Direct calls to RMS or through a languege RTL (C RTL?
Block-IO or Record-IO ($GET, $PUT),
Sharing configuration?

What is the basic sync method between prcocesses? How does a reader know there is new data? How does it know how much new data there is?

>> I understand that with OpenVMS 8.3 we have 10-12 new SYSGEN parameters and among them are
GB_CACHEALLMAX (set to 50000) and
GB_DEFPERCENT (set to 35).

Those are only used when an (RMS) file is marked with SET FILE/GLOBAL=DEFAULT.
Is your application doing that?
[you could be the first one on the planet doing so and thus is would be a tad more likely to run into a bug]


>> Are these parameters need to be changed?

If you use them then they likely should be changed, but at the same time they are unlikely to have any effect on a 'ENDOFFILE' problem. No relation.

>> respect to updating file headers when a database file is extended?

You seem to know much more than you shared here. Please provide details such that we can try to help.

- what constitues a database for your application?
- what is the meaning of 'extended' for your application? Just a call to SYS$EXTEND (unlikely) an APPEND (call to SYS$PUT with RAC=SEQ (0) after connecting with ROP=EOF?)
A call to SYS$WRITE?
Does teh application maintain its own EOF or does it use RMS for that?

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

[Ken USA]

Hi all:

>>>> What kind of files are these?
>>>> From a database product?
>>>> RMS index-sequential files?

These are databse files.

>>>> What's the application written in? C?
>>>> Which function failed with SS$_ENDOFFILE?

Yes, the application is written in C. Both nodes Node-B (8.3) and Node-C (8.2) are updating the database. We get into the problem only when the file is extended. For smaller tests, things work fine.

We just got this (8.3) machine recently. Before that we used to run the same benchmark tests with nodes running OpenVMS 8.2 and 7.3-2 and we never had this problem.

Thanks,
-Ken

[Hein van den Heuvel]

[Guenther, Notes collision ! :-) ]

>>>> From a database product?
>>>> RMS index-sequential files?

Ken>These are databse files.

Huh? Sorry, that does not translate/explain.
Names! Numbers! Types!


>>>> What's the application written in? C?

Yes, the application is written in C.

Ok, and now for the significant details...
Does it call a DB product for IO?
Does it use native C built-in IO like 'fwrite' or RMS calls like SYS$PUT? Does the open statement specify "ctx=rec" ? "shr=???" ?

>> For smaller tests, things work fine.

Probably not. You may have the bad luck that it just appeared to work fine.

>> We just got this (8.3) machine recently. Before that we used to run the same benchmark tests with nodes running OpenVMS 8.2 and 7.3-2 and we never had this problem.

More likely it was there all along, just not visible yet. Then again, there is always that small possibility that the application stumbled into a actual bug.

Maybe new LOCK REMASTER logic is playing a (timing) role?

Cheers!
Hein.

[Guenther Froehlin]

Ken,

"These are databse files."

that's not a lot of information. :-) Are these files of a database product like Oracle Server or Rdb or Sybase or what?

I doubt because typically a database would not return SYSTEM-W-ENDOFFILE and would do the file extension totally transparent.

You need to know a bit more about "the application" returning the error.

/Guenther

[Ken USA]

Hi all:

Sorry for the late reply. The development team confirmed that they had a minor bug in their "C" routine that was doing QIO. All is working fine now.

Thank you.
-Ken

[Ken USA]

Thank you all for the help.
-Ken