HP OpenVMS Systems

ask the wizard
Content starts here

I/O Channel Available Leak? (NOIOCHAN)

» close window

The Question is:

On a AXP2000 with OpenVMS 7.1-2 we have since a couple of months a very
 sporadic :
%DEBUGBOOT-W-CHN, assign channel system service request failed
%COB-F-OPEN_ERROR, Error during OPEN on file DSA.... (actual filename was
-RMS-F-CHN, assign channel system service request failed
-SYSTEM-F-NOIOCHAN, no I/O channel available
The problem occurs only once or twice a month, in various Cobol programs
 opening sequential files, although these and other similar Cobol-programs run
 hundreth times a week and create a couple of thousands seq. files a week. At
 least 6 months prior to the
 first problems, no system software changes nor upgrades took place. The load
 on the system remained also stable.
In an attempt to solve the problem, the FILLM of the user concerned was
 gradually increased together with the CHANNELCNT sysgen-parameter. After
 reaching the double of the initiale value (FILLM 1000 -> 2000 / CHANNELCNT
 2000 -> 4000) the problem still exi
Are there any means to further troubleshoot the cause of the problem ? Any
 other remedies ?

The Answer is :

  It would appear that you have a channel leak.
  Increasing the number of channels would only postpone the incidence
  of the reported failure.  See the attached text for a characteristic
  footprint of an application channel leak.
  You will want to check the PGFLQUOTA setting and the other process
  quotas -- in addition to FILLM -- and you will want to determine if
  the system is configured with sufficient available physical memory.
  You will also want to use SDA to check for open channels, to see if
  you have a supervisor-mode (the DCL command OPEN) or other I/O
  channels left open.
  While the DEBUGBOOT prefix can indicate the error occurs early in
  the image activation, it is possible that the error handlers have
  exited as far as those used for the debugger bootstrap.
  Details of the particular image and of the process and system
  environment will be required when you contact the Compaq Customer
  Support Center -- that the debug bootstrap fails indicates that
  this failure occurs very early in the application image startup,
  long before (most) user-written executable code is invoked.
  The OpenVMS Wizard is entirely unfamiliar with an "AXP2000" system,
  and will assume this is a DEC 2000 model 300 or model 500 series.
  When using SDA to observe the running process, the characteristic
  footprint of a LIB$FIND_FILE leak looks like this:
(second page of output from SHOW PROCESS/CHANNEL)
Process index: 0045   Name: _FTA9:   Extended PID: 20200145
Channel  Window           Status        Device/file accessed
-------  ------           ------        --------------------
  0090  00000000                        FTA9:
  00A0  80EBDBC0                        $1$DKA0:[VMS$COMMON.SYSLIB]DECC$SHR.EXE;1 (section file)
  00B0  80EBD240                        $1$DKA0:[VMS$COMMON.SYSLIB]DPML$SHR.EXE;1 (section file)
  00C0  80EBB780                        $1$DKA0:[VMS$COMMON.SYSLIB]CMA$TIS_SHR.EXE;1 (section file)
  00D0  00000000                        $1$DKA100:
  00E0  00000000                        $1$DKA100:
  00F0  00000000                        $1$DKA100:
  0100  00000000                        $1$DKA100:
  0110  00000000                        $1$DKA100:
  0120  00000000                        $1$DKA100:
  0130  00000000                        $1$DKA100:
  0140  00000000                        $1$DKA100:
  0150  00000000                        $1$DKA100:
    Press RETURN for more.
Process index: 0045   Name: _FTA9:   Extended PID: 20200145
Channel  Window           Status        Device/file accessed
-------  ------           ------        --------------------
  0160  00000000                        $1$DKA100:
  0170  00000000                        $1$DKA100:
  0180  00000000                        $1$DKA100:

answer written or last revised on ( 8-MAY-2001 )

» close window