|
HP OpenVMS Systemsask the wizard |
|
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 removed) -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 sts. Are there any means to further troubleshoot the cause of the problem ? Any other remedies ? thanks. 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.
SDA>
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:
(etc...)
|