All the references look to be specific to a leak in the VAX implementation of DECthreads, and there is no indication in any of the release notes that this is seen on Alpha. There have been DECthreads ECOs for Alpha, but the implementations of DECthreads do differ.
I'd look at the usual triggers for INSFMEM as a start. These are NPAGEDYN for system memory, CTLPAGES (image pool) and maybe CTLIMGLIM (image-related structure sizing) too.
A whole lot got fixed in the V7.1-2 release, as that release was a roll-up of all of the fixes for V7.1, V7.1-1H1 and V7.1-1H2. (Poke around in the patch archives; the V7.1-* range had a number of ECOs.) In addition to the aggregation of ECOs, better patch-management mechanism was added in V7.1-2 -- the old VMSINSTAL mechanism was replaced by PCSI.
The next supported release is V7.3-2 (with prior version support) and the current OpenVMS Alpha release is V8.3.
If your customer can't get to V7.1-2 or to V7.3-2 or to current, the other approach would involve loading up the VMSINSTAL ECO kits for V7.1. That's going to involve some downloading and planning around the sequencing of installations and reboots. The early range of V7.1-2 was exactly identical to V7.1 with all then-current ECOs applied. Well, OK, and with PCSI ECO capabilities added.
I'd also analyze the cause for the crash, and take a look at the available physical memory for the box, and at the queue manager's data structures. It would not surprise me to learn there are ECOs relevant for the queue manager, job control and/or DCPS within this range, too -- regardless, there are most certainly a number of mandatory ECOs.
Unfortunately, the trigger for this could be the crash. This could be insufficient physical memory or insufficient parameter settings, and this could also be creeping crud somewhere in the queue management.
Stephen Hoffman
HoffmanLabs
