ISTAT 30 error

[Volker Halle]

LM,

the %DEBUGBOOT message arises, when the image aborts due to an error and the condition handles tries to lactivate TRACE.EXE to print the stack trace information. If there is a resource error (insufficient IO channels available) at that time, you will get this error message.

There should be no problems, if users execute the same code over and over again, EXCEPT if there is a coding error and some channel or file does not get closed.

Watch a user with SDA> SHOW PROC/CHAN/ID=

If there is a channel leak, you will see the no. of open channels increasing.

Volker.

[Steven Schweda]

> [...] I am not sure if it's a system
> (sysgen) issue - or a program issue.

Some of each, I'd guess. In any case, you
know what to look for.

[Volker Halle]

LM,

can you check the value of CHANNELCNT on your old V7.2 system ?

I would also suggest to use SET PROC/DUMP so that you'll get an image dump, if the image incurs an improperly handled condition, but as the %DEBUGBOOT-W-CHN error already indicates, there may be not enough resources (i.e. channels) available for an image dump to be written...

Volker.

[LM_2]

I did check my old system and I had it set to

MIN_CHANNELCNT = 2446


my one cluster does have it in the modparams.dat already with 2446 - so I added it to my other node and as soon as I can reboot - I will see if that will fix the problem.

[Hoff]

FWIW, having a requirement for 2,000 channels implies a fairly unusual application. Your description here could indicate that there are channels being allocated, but not released. In other words, you may have a channel leak somewhere.

Use ANALYZE/SYSTEM and display one of these running Fortran processes at intervals, with SHOW PROCESS/CHANNELS or other such. If you see the numbers of channels increasing over time, then increasing CHANNELCNT is a stopgap on the way to an eventual failure.

And as for rebuilding your source code, there are specific cases were rebuilding is required due to bugs in the generated code. (See the srm_check tool for details of one of the more notable cases where this occurred. http://mvb.saic.com/freeware/freewarev40/21264/ and there's a long-standing case with the VAX C code generation (VCG) and its known problems with MD5 that's not likely going to get fixed.) There are also cases where the newer compilers will better spot latent bugs, or generate better codes. So there can be some advantages to rebuilding from source, even for the many cases where it's not required.

[John Gillings]

LM,

A very common cause of channel leaks is not completing a wildcard search. For example, LIB$FIND_FILE with a wild card needs to be completed with LIB$FIND_FILE_END. If you miss the _END you'll leak one channel for each search that is started. FIND_FILE is a jacket around the RMS service SYS$SEARCH.

You need to be especially careful with these services because sometimes a filespec can be a wildcard without looking like one. For example "SYS$MANAGER:LOGIN.COM". Since SYS$MANAGER is a search list, this is effectively a wildcard search.

[LM_2]

I showed the last response to my programmer and his response was:

"We DO IN FACT use the LIB$FIND_FILE in wave picking but NOT the FIND_FILE_END. I'll put that into the code."

I also put back in the min for the channelcnt in modparams.dat so the next time I reboot - that parameter will be bumped up.

thanks for all of your help!!

[Hein van den Heuvel]

>> I also put back in the min for the channelcnt in modparams.dat so the next time I reboot - that parameter will be bumped up.

Sure, but no need to go all out as before.

Please ask yourself how many channelany application on your box coudl ever reasonably need. I doubt it well be more than 200, and suggest a channelcount of no more than 1000.

You got this problem NOW, exactly because channel count was bumped without full understanding of the reason.

Had it not been bumped, then the programs would have failed consistently and surely the problem would have been addressed years ago.
A quick & dirty workaround years ago, has over time cost days or weeks of agony between enduser, sadministrators and developers.

Cheers,
Hein.

[LM_2]

When I looked at my old modparams.dat - I made a notation that I needed to bump up the channelcnt for Advanced Server 7.3 - that was so long ago - but I am guessing since I put that notation in it - I read that in the Installation and Configuration guide for Advanced Server.

My users are connecting to Advanced Server on the other node - which already has channelcnt bumped up to 2446 - so I guess I will look back through the guides and make sure this setting was correct before I reboot.

[Thomas Ritter]

To John,

just about every time with patch tcpip services for VMS we need to relink. A lot of our application code involves network tasks.



"Just to clear up this misconception.

On OpenVMS it is NEVER necessary to recompile or relink a correct, user mode program after upgrading OpenVMS. ..."