RMS DME and ISI errors from batch

[PaulGavin]

The process RMS defaults are set to BLOCK=16, NETW=8, EXTEND=8 and all others are zero. System defaults are much higher with BLOCK=120 and EXTEND=90. Setting the process defaults lower did not make a difference. In reviewing one of the jobs, I found three possible causes of recursive GOSUBs and corrected those, but the problem persisted.

I am able to duplicate the probelm on a backup node that, other than having a single CPU instead of four, is a duplicate of the the node where the failure started. After more looking and monitoring, I first raised the dynamic parm PIOPAGES by 50, with no change. Put PIOPAGES back where it was, raised CTLPAGES by 50 and rebooted, again no change. Then raised PIOPAGES as well and the DME error went away.

I plan to test using a smaller increase. Concerned what these increases might cause on the other cluster nodes. The node where the DME was a problem is mission critical, averages 300+ users and 677 processes. Moving the offending jobs to another node and raising the two parameters on that node only may be an option.

Hein, I think I remember that day as well.

[Hein van den Heuvel]

Those are all puny default/value.

blocks=16 has been the default for the first two decade. For this decade VMS switched to 32. That's still small for application writing and reading large sequential files. Your sys default seems to reflect that thought. You probably should also set buffers to 4 or so. 2 is pretty much the minimum and after 4 we often get rapidly diminishing returns for the average case.

extend=8 is ridiculous. A step back if anthying. RMS will at least give the file 2 buffers worth, the file systems rounds that up to ne nearest multiple of the clustersize.
Such low extent is only acceptable if the application only make lots of little file.
It is often not unreasonable to set this to 1024 or more. The system will truncate back to the nearest cluster on close.

>> I plan to test using a smaller increase

Don't wast too much time there.
That 50 is a small increase, unless you need to support many thousands of processes. I would say if 50 more fixed it for now, then give it 256 more (for both) and sleep more easily. It is still VIRTUAL memory. If the bulk of those hundreds of processes do not need it, they will not touch it and no real memory will be instantiated for that flavor of process memory. And normally, unlike P0 space perhpas, there is not too much competition for P1 address space to that should not be an issue. Only processes going wild will be stopped a little later having more resources to exhaust.

fwiw,
Hein.

[Hein van den Heuvel]

Side note... I was refering to an other Paul Gavin. You worked in Colorado back then. I was thinking of a bloke from Scotland who actually still works for HP, now in Cupertino doing SQLserver stuff. He did a presenation @ HP Tech Forum back last September in Houston, where I just missed him when I did my RMS presenations.

Hein.

[PaulGavin]

I met so many folks the last few years at DEC that I cannot remember many names. I spent quite a bit of time in the Spitbrook facility in relation to arious projects. The group I worked for supported global sales efforts and we were constantly lobbying engineering for enhancements to gain any little bit of comptetitve edge. I do remember demonstrating a still missing feature in RMS to a group of people in a lab at ZKO. So if someone says they met me, I am not going to dispute it.

Unfortunately I also know the fellow you are talking about and wondered if you had us confused.

Back on the topic, we plan to increase the PIOPAGES and CTLPAGES parameters during a very short shutdown period Christmas day. Thanks for all of the input.