ISTAT 30 error

[Willem Grooters]

For what it's worth: If you need to have a contunious view on evolving process quota, PQUOTA is a program that might be of help:
http://vms.process.com/scripts/fileserv/fileserv.com?PQUOTA

WG

[John Gillings]

re: DECxchange:

>Have any of these FORTRAN programs
>been recompiled since the OS upgrade?
>Have you made sure your version of the
>FORTRAN compiler is compatible with the
>new OS?"

Just to clear up this misconception.

On OpenVMS it is NEVER necessary to recompile or relink a correct, user mode program after upgrading OpenVMS. User mode code is guaranteed to be upwards compatible (OpenVMS engineering go to great lengths to fulfill that promise). It may be necessary for some other operating systems, but not OpenVMS (indeed, I believe there are some programs in the VAX Fortran regression test suite that were compiled and linked on VMS V1.0 in 1978)

There's unlikely to be any significant benefit to be gained from recompiling (with the possible exception of forcing you to make sure you know where your sources are so you don't lose them!).

You don't even need to recompile or relink to benefit from improvements or bug fixes in run time libraries, as you will automatically use the newer version.

Since compilers are essentially usermode text processers, there is no such thing as a compiler which becomes "incompatible" with a new version of OpenVMS. Many compilers support having multiple versions installed on the same system.

The biggest benefit of most new compilers is new features, which, by definition aren't required for existing code. There may be some bugs fixed (but again, working code doesn't need them), and there may be some improvements in generated code quality (but rarely significant enough to warrant dredging out all your old code for recompiling).

[LM_2]

After implementing the ERRSNS calls as recommended - we now see this - which is what I was expecting and does confirm my suspicions that the cause of the ISTAT = 30 is the fact that the process has exhausted all available channel allocation space. I cannot find any reason for this allocation failure within the code.

IN MODULE: BLINK_WAVE_WORK_ORDER
ERROR DURING OPEN
STATUS: 30
%RMS-F-CHN, assign channel system service request failed
%SYSTEM-F-NOIOCHAN, no I/O channel available

HOWEVER - we are also seeing this within the user log files - I have not seen this before, but is most likely related to the problem we're seeing with the istat 30 issues. ( Read the HP Wizard response below) I am not saying that we have the EXACT situation - but the "%DEBUGBOOT" prefix of the message worries me. This should not happen - it is my understanding that the DEBUGBOOT handler only kicks in after all other means have failed.

%DEBUGBOOT-W-CHN, assign channel system service request failed
%DEBUGBOOT-W-CHN, assign channel system service request failed
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000003000000
0000, PC=000000000019DCFC, PS=0000001B
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000003000000
0000, PC=000000000019DCFC, PS=0000001B

[Steven Schweda]

mcr sysgen show CHANNELCNT

Done an AUTOGEN lately?

[Steven Schweda]

Motivation:

alp $ help /mess NOIOCHAN

NOIOCHAN, no I/O channel available

Facility: SYSTEM, System Services

Explanation: The process exceeds the number of I/O channels that can be
assigned at one time.

User Action: Deassign another channel, or close a file and retry the
operation. Check for a program error that fails to deassign
channels or close files. Also check the SYSGEN parameter
CHANNELCNT to see if it is high enough.

[LM_2]

I have a two node cluster - here is what the channel count is on both nodes:

SYSGEN> SHOW CHAN
Parameter Name Current Default Min. Max. Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
CHANNELCNT 2446 256 31 65535 Channels


SYSGEN> SHOW CHAN
Parameter Name Current Default Min. Max. Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
CHANNELCNT 256 256 31 65535 Channels

[Volker Halle · Accepted solution]

LM,

the SYSGEN parameter CHANNELCNT specifies the maximum number of channels, a process can have assigned at one time. This parameter does get monitored by AUTOGEN. Consider to check and increase this parameter. The parameter is not dynamic, so you have to reboot to change it.

You can check running processes with:

$ ANAL/SYS
SDA> SET PROC/id=
SDA> SHOW PROC/CHAN
SDA> EXIT

to see, whether the no. of open channels gets near the value of CHANNELCNT. There may be a channel leak, i.e. a process may forget to deassign channels.

Volker.

[Volker Halle]

LM,

typo warning - I meant to say: CHANNELCNT dooes NOT get monitored by AUTOGEN feedback.

CHANNELCNT=256 seems a little bit low on the 2nd node. Consider to set it to the same value as on the first node. Could 'randomly' mean, that processes on the 2nd node see the error, while those on the first node seem to work ?

Volker.

[LM_2]

I have been monitoring a few users - and what it seems like to me is.......these users's continually use the same "custom code" over and over again without exiting out of the command......the more times they use this piece of code continually - the more likely the chance they will get this error message. So, to clarify -they are in our picking software, pick a part, continue on to pick a different part......so they could be in the exact same command for over an hour.....and it seems like they reach a limit and are kicked out. That's why I am unsure about bumping up some parameters - cause at this point - I am not sure if it's a system (sysgen) issue - or a program issue.

I am not sure if it is happening on just one particular node or not. I can watch to clarify this.

[Steven Schweda]

Around here:

ALP $ mcr sysgen show CHANNELCNT
Parameter Name Current Default Min. Max. Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
CHANNELCNT 4096 256 31 65535 Channels


It's been a while, but there was probably
some reason for the "MIN_CHANNELCNT = 4096"
in my MODPARAMS.DAT. For some possibilities:

seach sys$help:*.RELEASE_NOTES channelcnt