One-off image activation failure, "-SYSTEM-F-IVCHNLSEC, invalid channel for create and map section"

[Mark_Corcoran]

Over the weekend, one of our operations staff logged in to one of the systems (OpenVMS/VAX v6.2, running under CharonVAX) to perform some routine checks.

When he attempted to access the command line interface for one of the applications, he got the following messages:

%DCL-W-ACTIMAGE, error activating image imagename
-CLI-E-IMGNAME, image file device:[directory]imagename.EXE;2
-SYSTEM-F-IVCHNLSEC, invalid channel for create and map section

His second attempt to access the interface worked with no problems, but I've never seen this message before, and its "sudden" appearance causes me some concern.

He was attempting to run one executable image (via a DCL symbol defined in LGICMD as RUN device:[directory]image.exe), and that executable image has three shareable images (of "library" code) linked into it via an options file for the LINK command in the build procedure.

The imagename which DCL reported as being unable to activate, is the first of the 3 images listed in the .OPT file, but the third to be listed from a SHOW PROCESS /ID=pid /CHANNEL when using SDA to look at a process that has successfully started up the "main" executable image and delivered the user to the application command prompt.

I've had a look in the main application log file, OPERATOR.LOG, ERRLOG.SYS, and ACCOUNTNG.DAT, and found nothing untoward.

The Windows event logs for the machine on which the system runs under CharonVAX doesn't record any events around this time (in fact, very few events in general), the IBM Raid Manager software doesn't record any errors as having occurred with any of the RAID sets, and the Charon Service Manager doesn't have any events beyond when the Service was last started (in the past, we've had issues where it couldn't sense the H/W dongle on the USB bus).

The System Messages and Recovery Procedures Reference Manual A-L has the following to say about the IVCHNLSEC message:

Explanation: The channel number specified in a request to create and/or map a section file is busy; the section cannot be mapped.

User Action: Verify that the $OPEN request (to open the section file) completed successfully and returned a valid channel number.

The "main" executable image isn't making a specific request to $OPEN the shareable image, so it's a by-product of the fact that the shareable image is linked in to the .EXE by the .OPT file, so within the code, it can't make any checks that an underlying $OPEN completed successfully.

I considered that maybe it was a resource issue - I did observe an anomally in the quotas for the user account compared to other operator accounts:

Maxjobs:         0  Fillm:       300  Bytlm:       100000
Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0
Maxdetach:       0  BIOlm:        40  JTquota:       4096
Prclm:           2  DIOlm:        40  WSdef:          256
Prio:            4  ASTlm:        40  WSquo:          512
Queprio:         0  TQElm:        40  WSextent:      1024
CPU:        (none)  Enqlm:       200  Pgflquo:      32768

Other accounts have a WSDEF of 1500, a WSQUO of 4000, a WSEXT of 18000 and a PGFLQUO of 80000.

However, I'm not really sure why that would have caused a one-off error (which has never previously been seen since this (or a few other affected) operator account(s) were created), that subsequently didn't occur when the user issued the command again immediately after (without logging out or issuing any other intervening command).

Has anyone seen this message before (a Google search finds a fix in RDB for a similar issue with one of its executable images in batch mode, but gives no further information on the cause)?

Is it potentially some shared resource that was depleted when the user first issued the command but within the next couple of minutes (no timestamp alas) recovered sufficiently to allow the executable to activate all of the shared images?

I'm going to correct the account quotas for the affected accounts, and review the procedure used to create the accounts, but this (to me) is particularly odd/obscure problem.

FWIW, although the applications were running, there was no production input to the system at the time, few users logged on to it, and disks weren't being taken offline to take backups or anything like that.

All suggestions gratefully received.

Mark

[H.Becker]

As you probably know, the error is returned from a system service to create and/or map a section. The image activator is very likely only the messenger. The image activator opens the shareable image file and returns an error if that failed. It then uses the returned channel to create/map the sections. (Yes, it opens an installed image as well, but RMS knows about that being already open and so RMS' only action is to return the channel and the KFE.)

IVCHNLSEC may be caused by a wrong channel number or any wrong/corrupted data structure addressed via a valid channel number. It's unlikely that the channel number, which the image activator saved, was changed or became invalid. (While activating an image, INSTALL can not remove an image.)

A (too) small working set shouldn't be a problem. Not enough channels will show when opening the image file, probably as "%SYSTEM-F-NOIOCHAN, no I/O channel available".

If Google pointed me to the ECO that you mentioned, it describes an update for Alpha (VMS721_UPDATE-V0300). It showed the affected/changed image was SYS$VM.EXE (which is where the map section system services are; it is not the place where the image activator lives). That fix was for a newer VMS version: 7.2-1. So it may have fixed something, which is in VMS/VAX V6.2.

Sorry, I have no suggestion or hint what went wrong or how to find out what this was.

[Mark_Corcoran]

Thanks for the reply Hartmut.

Yep, it seemed unlikely to me that channel number the image activator was trying to use should be invalid, or the data structures relating it to be corrupted (after all, this is way before user code runs which could have any manner of bugs;  I'm not saying DEC/Compaq/HP/VSI are perfect, but it's pretty fundamental to OpenVMS, for there to be a bug in this area (unless a large number of fairly unique and specific conditions must occur at the same time, not least "bit rot").

I've updated my original post after going back to the Charon Service Manager just to check to make sure that it hadn't reported any issues.

My thoughts were that most likely it was a disk issue (e.g. temporarily offline) which might have prevented the image activator from accessing or finding the shareable image it reportedly had an issue with, but as I mentioned, there was nothing in ERRLOG.SYS or in the IBM Raid Manager logs (we have had a RAID issue once in the 5 years I've been here, and that pretty much killed Windows as well).

I've just double-checked, and an ANALYZE /DISK /NOREPAIR on the disk containing all of the application images (shareable and otherwise) reveals nothing either.

When the application command prompt is normally accessed (and without issuing any commands that might open channels to anything else), the total open channel count is 23, with the 18th channel being to the shareable image that there was the one-off problem with (so it seems unlikely that it would be a too-many-open-files issue (the preceding commands* that the user issued don't strike me as having any means of consuming channels whilst the executable images are run, and then leaving them open but still returning back to the DCL prompt).

*3 routine commands from the other application, and MC NCP SHOW KNOWN LINKS

I looked at trying to reproduce the effect by having too many files open on a test system, and trying to access the application command prompt, but a DCL loop to open lots of files gave up (%RMS-F-DME, dynamic memory exhausted) after 28 files (CHANNELCNT is set to 255, the user account FILLM is set to 300).

I'm not in a position to try reducing CHANNELCNT or increasing CTLPAGES on the test systems at the moment to see if it is "%SYSTEM-F-NOIOCHAN, no I/O channel available" that is reported if I try to run the image that the user had problems with, but certainly when reducing the FILLM count, it was a quota error that was reported (when I ran that image).

>If Google pointed me to the ECO that you mentioned

Yep.  I only took a quick glance at the Google results previously, and because of the mention of RDB, I had assumed it was an Oracle-reported bug - I didn't actually check to see where the results came from :-O

I'm not sure if even in the glory days at my second employer, we could still have got more information from (then) Compaq (who were being paid £££ every year) on the specifics of that bug, what the circumstances were under which it occurred, whether or not it might pertain to other image activations, and whether it was AXP-specific.

I feel that I am going to have to start using using my other hand to continue counting the number of problems that I've never got to the bottom of :-(

Mark