NOMSG + create failed

[Wim Van den Wyngaert]

To monitor free space, we create a file of 10.000 contiguous blocks in the root of each disk. And delete it afterwards.

However, 1 on 5000 creates fails for an unknown reason. I get FDL-F-NOMSG, Message number 10b4808c. I searched all error message libraries for this code and without result.

There was no activity on the disk, there is no highwater marking, no defragmenting running (was just finished) and there were 33.000.000 blocks free, of which the largest contiguous was 5.000.000 blocks.

1) what does this means ?
2) when is HP going to complete their error message libraries ? I know VMS since 1986 and have regularly seen these messages.

[Uwe Zessin]

Wim,
how did you attempt to decode the message?

The following commands work for me on OpenVMS V7.3-1:

$ set message sys$message:shrimgmsg
$ write sys$output f$message(%x10b4808c)
%FDL-F-OPENFDL, error opening !AS
$

I assume you know that !AS is a SYS$FAO() argument and why the filename cannot be shown here.

[Wim Van den Wyngaert]

Oeps. Must have made an error.
But the problem remains. Why did the create fail (I don't have a log).

[Uwe Zessin]

Oh, sorry, I didn't paste the rest of the answer...

I assume that just that status code is returned to DCL, no? How are you creating that file? With CREATE/FDL or some code of your own? You somehow need to get at the 'lower' condition codes from OpenVMS. I don't recall if FDL$CREATE can supply them or can raise a condition.

If nothing helps here, you can still use RMS to create a file that way. I know then RMS does provide the XQP status codes (look for STS and STV) in its access blocks (the FAB, if I recall correctly).

I am curious: is there a reason that you don't use something like the following command to just get the free space of there disks or are you definitely after largest contiguous blocks?

$ write sys$output f$getdvi("dsk","freeblocks")

[labadie_1]

You should have a procedure which loops in sys$message and tries

here is one, found in comp.os.vms




$! MESSAGE.COM - get text of a message number
$!
$! P1 = message number (integer)
$!
$! Sample usage:
$! @TRYMSG %X0000002A
$!
$! EDIT DATE EDIT BY DESCRIPTION
$! --------- ---- --- ---------------------------------------
$! 2-SEP-92 102 DGW Handle and display errors caused by
$! "%SYSTEM-F-IVSECIDCTL".
$! 13-AUG-92 101 DGW Added SET MESSAGE/DELETE (per David P. Murphy,
$! ) to remove effect of SET
$! MESSAGEs.
$! 13-AUG-92 100 DGW Documented, upcased, added 'no message found'.
$!
$!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
$
$
$ IF F$TYPE(P1) .NES. "INTEGER"
$ THEN
$ WRITE SYS$OUTPUT "P1 must be an INTEGER"
$ GOTO DONE
$ ENDIF
$
$ P1 = F$INTEGER(P1)
$ WRITE SYS$OUTPUT F$FAO("Searching for all messages with value %X!XL",P1)
$ MESSAGE_FOUND = 0
$
$LOOP:
$ FILENAME = F$SEARCH("SYS$MESSAGE:*.EXE;")
$ IF FILENAME .EQS. "" THEN GOTO DONE
$
$ WRITE SYS$OUTPUT F$FAO("!5* Checking !AS", FILENAME)
$ DEFINE/USER_MODE SYS$OUTPUT NLA0: ! ignore "%SYSTEM-F-IVSECIDCTL" errors
$ DEFINE/USER_MODE SYS$ERROR NLA0:
$ SET noON
$ SET MESSAGE 'FILENAME'
$ IF .NOT. $STATUS THEN WRITE SYS$OUTPUT "(Error using above file: ", F$MESSAGE($STATUS), ")"
$ SET ON
$ TEXT = F$MESSAGE('P1')
$
$ IF F$EXTRACT(0,7,TEXT) .EQS. "%NONAME" THEN GOTO LOOP
$ IF F$LOCATE("-NOMSG,",TEXT) .NE. F$LENGTH(TEXT) THEN GOTO LOOP
$ WRITE SYS$OUTPUT TEXT
$ WRITE SYS$OUTPUT ""
$ MESSAGE_FOUND = 1
$ GOTO LOOP
$
$DONE:
$ IF .NOT. MESSAGE_FOUND THEN WRITE SYS$OUTPUT -
F$FAO("No messages found in SYS$MESSAGE for %X!XL",P1)
$ SET MESSAGE/DELETE
$ EXIT

[Wim Van den Wyngaert]

Labadie,

That's the procedure I used. I made an error.

Uwe : free blocks is useless if they are not somewhat contigious. I saw several times that an application failed due to missing contiguous place, esp. when using RMS indexed files.

[Willem Grooters]

Wim,

a suggestion:
I have had a similar problem with directories containing a lot of files, on a disk where contiguous free space was scarce.
Creating a file _may_ require an extension of the directory file (by XQP). That will fail if not enough contiguous free space is available. File craete will then fail.
In your case, it _may_ be able to create a 10K-block file, but by that, space to allocate a new (contiguous) directory file will fail - giving the impression file creation failed.
(There is a thread in this forum about this)

[Uwe Zessin]

There is, BTW, another useful ressource:

$ help/message/status=%x10b4808c

I understand that the explanation does not really help right now, but I thought a reminder would not hurt.

[Wim Van den Wyngaert]

I added a capture of the complete error message. Now wait for some 5000 creates before I have the msg.

Willem : it must be a very big directory extend that takes 4.000.000 blocks.

[Hein van den Heuvel]

1) what does this means ?

It means that the FDL code has trouble opeing the FDL file.

It says nothing about the file to be created as other replies suggest!

It also suggests that the error handling in your script is messed up or maybe, pretty unlikely though, it means that the system could not get to "sys$message:shrimgmsg.exe".
Is the message image installed (shareable)?

Normally, using the FDL utilities you'll nicely get a full message for example:

$ create/fdl=nl: aap:[noot]mies
%FDL-F-CREATE, error creating AAP:[NOOT]MIES.;
-RMS-F-DEV, error in device name or inappropriate device type for operation
$ show symb $status
$STATUS == "%X10B4806C"
$

And for your specific error:

$ create/fdl=aap:[noot]mies test
%FDL-F-OPENFDL, error opening AAP:[NOOT]MIES.FDL;
-RMS-F-DEV, error in device name or inappropriate device type for operation
$ show symb $status
$STATUS == "%X10B4808C"


Are you using an FDL Utility? Or calleable?

I agree with Uwe that you should perhpas consider a program calling RMS directly for your test to be more close to the source of a problem, if there is a problem. Such that you can print out STS and STV and FNM and the likes.

On the Other hand the FDL Utilities normally do a fine job signalling all errors and theri arguments.

2) when is HP going to complete their error message libraries ? I know VMS since 1986 and have regularly seen these messages.

As soon as someone logs an official report with explicit circumstances of missing errors. I *never* get 'these' messages unless I mucked up error handlers in my program 'trying to be smart'.
Best VMS knows the message libraries are complete ( but not always used correctly .)

Met vriendelijke groetjes,

Hein. (RMS/FDL maintainer/engineer 10 years ago! :-)