%dcl-e-open

[nuno vitoria_1]

i have this error:

%DCL-E-OPENOUT, error opening BG_DIGI:[LOGIN] LAST_SETUP_DIGI.COM; as output
-RMS-E-WLK, device currently locked

INTERnet ACP AUXS failure status=%RMS-E-WLK

[marsh_1]

Hi nuno,


it would be helpful if you could provide some more info, e.g operating system version,architecture, what it is you are doing when you get this error, is this new behaviour and if so what else has changed ?

[Joseph Huber_1]

RMS-E-WLK: somebody tries to write to a read-only device, defined through the logical name BG_INI .

Internet AUXS indicates the process trying to write to the file is started as a TCPIP service.

Since BG_DIGI is not a base VMS name, if You don't know to which application-package it belongs, do a
TCPIP SHOW SERVICE
to see if one of the services refers to this name.

[Hein van den Heuvel]

What is being attempted when this error occurs? Did it ever work?

To investigate, start with: $HELP/MESS WLK.
It reads: "The hardware device specified for an RMS file system operation is write-locked for protection, and write access is attempted."

That device pretty much has to be whatever is pointed to by "BG_DIGI".
So do a: SHOW LOG BG_DIGI
As well as: $SHOW DEVICE BG_DIGI

Are you running something from a CD?

Cheers,
Hein.

[Hoff]

You can either debug the DCL command procedure involved here, or pass along a problem report to the individual or organization that is maintaining this DCL command procedure on your behalf.

If you're maintaining this DCL command procedure, enable verification (eg: $ SET VERIFY) or otherwise insert some debugging statements (eg: $ WRITE SYS$OUTPUT "debug message") or such.

In this case, it looks that the DCL command OPEN has failed here; that there is either some faulty prolog code, a change that has adversely effected the OPEN command, or a faulty OPEN command. Or there could be a system-level issue arising here, and one that could easily involve some sort of a configuration issue or hardware error; something that has locked a disk.

If you have a support contract, use it. If you don't have a support contract, call in a specialist and/or get a support contract. That, or you're going to be learning rather more about how to support OpenVMS and the hardware and the software involved here. (See above.)

[Jess Goodman]

To get some more details about the error, do
$ SHOW DEVICE/FULL BG_DIGI:

If, as would seem likely, the device physical name starts with BG then it is an IP socket. Depending on what TCP/IP stack you are using and what VMS version you are runnning (hint: tell us these things), you can get socket details with the command:

$ UCX SHOW DEVICE /FULL BGn

where BGn is the socket's physical device name that was output with the first command.

[Richard J Maher]

Hi,

Did this DCL used to work and has just stopped working? Has the open statement changed?

What does

$ucx show dev bg_digi/full

display?

I have attached an INETd (Auxillary Server) example which is probably of little use to you as it uses the $assign service from a 3GL rather than DCL OPEN (but it does have 2PC between Windows SQL Server and DECdtm/Rdb :-)

Cheers Richard Maher

[Jess Goodman]

Richard,

For some strange reason the UCX - TCP/IP services command UCX SHOW DEVICE does not allow you to use a logical name for the socket device - at least up through TCP/IP Services 5.4.

[nuno vitoria_1]

Welcome to OpenVMS AXP (TM) Operating System, Version V6.2

Username: SYSTEM
Password:
Welcome to OpenVMS Alpha Operating System, Version V6.2 on node LITAX1
Last interactive login on Tuesday, 7-OCT-2008 08:53:31.67
Last non-interactive login on Tuesday, 7-OCT-2008 10:28:39.56
DEFAULT keypad definitions:
F17 = "@BG_GEN:[COM]SETUP DIGI"
F18 = "@BG_COM:SYSMGT"
F19 = "@BG_COM:VBACKUP_SUPERVISOR"
F20 = "@BG_GEN:[COM]SETUPEDD"


$ ucx show dev bg_digi/full
%UCX-E-INETERROR, Error accessing Internet
-UCX-E-INVSOCKNAM, Invalid socket name
$

[nuno vitoria_1]

This station needs de server for to work.

IRIX (litsg3)

login: digi
Password:
IRIX Release 6.3 IP32 litsg3
Copyright 1987-1996 Silicon Graphics, Inc. All Rights Reserved.
Last login: segunda-feira 06 de outubro 2008 17:42:22 on :0

Client: litsg3
Server: litax1

Software version: DIGI V9.4.1 (dd. 1-FEB-1999 10:49)
Maintenance Pack 4 (dd. 17-NOV-1999 09:45)

Software downloaded: yes

Locale "pt" used for: Operating System
Typography

litsg3 1%

[Richard J Maher]

Hi nuno,

As Jess kindly pointed out UCX doesn't seem to like logical names so, as per his note, you need a two step process: -

>>>>>>>>>>>>>>>>>>>
To get some more details about the error, do
$ SHOW DEVICE/FULL BG_DIGI:

If, as would seem likely, the device physical name starts with BG then it is an IP socket. Depending on what TCP/IP stack you are using and what VMS version you are runnning (hint: tell us these things), you can get socket details with the command:

$ UCX SHOW DEVICE /FULL BGn
<<<<<<<<<<<<<<<<<<<<

Is it posible to see the DCL OPEN command that is triggering this error and a few lines above taht?

Cheers Richard Maher

[nuno vitoria_1]

Hi Richard,

i don´t understand to mach this system but if you can help me thanks.

i send you a report what i do.

cheers Nuno

[Karl Rohwedder]

Look at the status:

Volume Status: subject to mount verification, allocation inhibited because of
error on bitmap, write-back caching enabled.

There is an error in the bitmap and the allocation of space is inhibited, i.e. no new files, hence the WLK error.

You may try a
$ ANAL/Disk/Repair DKB0:

but you should make a backup before.

regards Kalle

[nuno vitoria_1]

Hi Kalle,

i do the command and i put the report.

cheers

[Hein van den Heuvel]

"-SYSTEM-F-PARITY, parity error"
The disk is going bad.

Switch over to a new disk.
This may involve restoring a backup.
This may involve loss of data.

If you are lucky all you have to do is find a spare drive (push in a fresh brick) for example DKB100. Now $backup/image dbk0: dkb100:. Dismount DKB0, Mount DKB100, redefine logicals name like bg_digi to point to to new drive. Hint: $SHOW LOG */OUT=logicals.tmp ... $SEARCH logicals.tmp DKB

Over time you may want to put th enew drive in the old slot, or not.

Good luck!
Hein.

[nuno vitoria_1]

$ search logicals.tmp dkb
%SEARCH-W-OPENIN, error opening SYS$COMMON:[SYSMGR]LOGICALS.TMP; as input
-RMS-E-FNF, file not found
%SEARCH-E-NOFILE, no file found
$ sho dev d

Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
DNFS0: Online 0
DNFS1: Mounted 0 litsg1:/ 0 1 0
DNFS2: Mounted 0 litsg2:/ 0 1 0
DNFS3: Mounted 0 litsg:/disk2 0 1 0
LITAX1$DKA0: Mounted 0 AXPVMSSYS 583060 425 1
LITAX1$DKA400: Online wrtlck 0
LITAX1$DKB0: Mounted 9 DISK2 5630778 2 1
LITAX1$DKB400: Mounted 0 DISK3 3510765 1 1
LITAX1$DKB500: Mounted 0 DISK4 4284234 1 1
LITAX1$DVA0: Online 0
$ backup/image dkb0: dkb400:
%BACKUP-F-MOUNTFOR, DKB400:[SYSMGR]*.*;* must be mounted /FOREIGN
$ show log */out=logicals.tmp

this weekend we had light lack and never more I connect with the server.

[nuno vitoria_1]

display...in attach

[nuno vitoria_1]

hi everybody thanks for your help it is now working.

best regards
Nuno

[Hein van den Heuvel]

Dear Nuno,

"take your fingers from that keyboard and slowly step away from the computer"

Please go careful, and try to get some more experienced help.

The commands I suggested were rough directions, not verbatim.
Judging by the output posted you are out of your 'comfort zone' with this set up and risk creating further damage.
Please escalate the problem, internally or externally (vendor, hp, consultant, whatever.).

Good luck!
Hein.

[Hein van den Heuvel]

I guess I spoke to soon!
It sure looked scary there for a moment!
Good to hear it worked out, and thanks for letting us know.
Cheers,
Hein.

[Willem Grooters]

From your last output:

LITAX1$DKB0: Mounted 9 DISK2 5630778 2 1

9 = error count.

Since you had errors on that disk before, and now nine errors since reboot, I wouldn't trust the disk too much and replace the disk ASAP. Keep a close watch on the error count. If it rushes up, you're too late to salvage any data from it.

In general: if a device is locked for write and you KNOW it's not mounted 'readonly', always check the device for errors, and have a look to the error log.

BTW: "BG" is a socket device, when follwoed by a NUMBER. BG can never(?) be a socket device so checking on UCX/TCPIP has no meaning. I would advise to relabel the disk to something less ambiguous, If possible and feasible (because it may require changes in procedure and software)

[Hoff]

>>> %DCL-E-OPENOUT, error opening BG_DIGI:[LOGIN] LAST_SETUP_DIGI.COM; as output
-RMS-E-WLK, device currently locked

That error is very likely from a failed OPEN command and -- no matter what the target OPEN specification might be -- a DCL OPEN command isn't connected to IP nor to the BG port devices in any meaningful fashion in any available OpenVMS release. I'd expect that the AUXS failure message is a bit of a canard, and due to the error not being fielded correctly by the connection; that the DCL error is being reflected and shown in the context of the IP processing or the IP tear-down.

To the OP: confirm your disk archive (BACKUP /IMAGE) is good and current and get a copy of anything you care about copied off this disk. Get set to swap the disk for a replacement. And look at the other disks, since I'm going to bet this box is ancient; once one disk goes, others tend not to be far behind.

Confirm that somebody that set up the local archival strategy did NOT use a BACKUP /IMAGE /IGNORE=INTERLOCK; that command sequence is both common and it won't necessarily get you a complete and consistent copy of your disk data. Or just go get yourself a current BACKUP /IMAGE of the disk now.

And one final caveat: the more you put load on a failing disk and the longer you wait, the more likely you'll increase the errors or to completely fail. Placing an I/O load on a disk with an ANALYZE operation and such is *not* an approach I'd suggest with a failing disk -- not until *after* you have your data off the disk, since a full-disk BACKUP will itself put substantial I/O load on the disk. And might well fail.

[Jon Pinkley]

If you don't have a good backup of the DKB0 drive, and it has critical data that can't be recovered from a backup tape, then I would recommend shutting down, booting from the installation CD, and doing a PHYSICAL backup of the DKB0 device. After that works, then an IMAGE backup. The output of the analyze shows there are areas of the disks that can no longer be read, and I am not confident that an IMAGE backup will be able to save as much (possibly recoverable) data as a PHYSICAL backup will. A Physical backup will also in general put less stress on the drive, as it is just a LBN by LBN copy.

Since this isn't the system disk, you could possibly do the backup without booting from the CD, but unless you can mount the disk privately, you will not be guaranteed to get a good IMAGE backup. If you follow Hoff recommendation and use

$ backup/image dkb0: tape: ...

without the /ignore=interlock, any file that is open for write will just be skipped. If you do use /ignore=interlock you won't be guaranteed that those files are backed up correctly, but in my opinion, a backup /ignore=interlock is better than a backup without /ignore=interlock if you are making a backup of a disk that is mounted for shared write access.

If you backup without /ignore=interlock and get no warning messages, then you do have a reasonable guarantee that the backup is consistent. But if you do get any warning messages, then your backup is definitely incomplete if you did not specify /ignore=interlock.

If you are interested, see

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1191154

Which has both sides of the argument.

On the other hand, if this is just a scratch drive with unimportant files, then it probably isn't work spending the time to try to recover, which will be a very time consuming and therefore expensive operation, without any guarantees of usable results. By far the simplest is to put in a replacement (used) RZ29 and restore from a recent backup.

Jon

[Hoff]

>>>if you backup without /ignore=interlock and get no warning messages, then you do have a reasonable guarantee that the backup is consistent.

That's actually not the case, interestingly enough. Shutting off the interlocks can permit entirely silent corruptions in the output saveset or output copy; that detail was from a direct discussion with one of the engineering folks that was maintaining BACKUP itself, too.

[Jon Pinkley]

I made no claim about a backup /ignore=interlock being guaranteed correct if there were no warnings. I was talking about "without /ignore=interlock".

However, I have not been able to reproduce the "silent corruption scenario", but that does not mean it isn't possible.

Jon