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! :-)

[Wim Van den Wyngaert]

Hein,

Yes, it is create/fdl that is causing the problem. I have errorhandling but only get the error code, not the message stack. Unless I explecitly ask for it (as I will do from now).

Yes, I used to maintain (generate) fdl's too, 10-15 years ago.

The FDL is a static files that doesn't move and is only accessed by the procedure itself.
I tested if exclusive access is needed and the answer is NO. So, I think it must be something differently.

Filling error messages based upon user complaints is the wrong way to go. You need someway of scanning the sources and checking if all codes are present in the libraries. That's how we used to work in COBOL.

[Hein van den Heuvel]

> Yes, it is create/fdl that is causing the problem.
> I have errorhandling but only get the error code, not the message stack.
> Unless I explecitly ask for it (as I will do from now).

'Normally' it just shows up in the batch log no? Or is this spawned perhaps.
If it is spawned, then I'd strongly recommend to call FDL$CREATE instead.

> Yes, I used to maintain (generate) fdl's too, 10-15 years ago.

I think you mis-read or I did not write clearly enough.
I actually maintained the FDL code for the VMS sources. :-).

> The FDL is a static files that doesn't move and is only accessed by the procedure itself.

As they normally are. So some other 'environmental' condition happened.
Some (pooled) process quota ran out?
Normally the FAB$L_STV field would have those details, not the primary FAB$L_STS.


> I tested if exclusive access is needed and the answer is NO. So, I think it must be something differently.

Well... exclusive access is indeed not needed, just read will do. But it will not work if an other stream already has exclusive access:

$ open x tmp.fdl
$ create/fdl=tmp test
$ close x
$ open/write x tmp.fdl
$ create/fdl=tmp test
%FDL-F-OPENFDL, error opening U$1:[HEIN]TMP.FDL;
-RMS-E-FLK, file currently locked by another user

> Filling error messages based upon user complaints is the wrong way to go.
> You need someway of scanning the sources and checking if all codes are present in the libraries. That's how we used to work in COBOL.

Again, I mis-communicated. Sorry.
It is 99.99% sure that all message are caught in message files. The purpose of filing a full documented report would be to learn how the application got in trouble and maybe fix that somehow or just help the customer to fix the problem... because it will be a customer applicaiton problem, not a 'missing' error message.

There are no missing error messages in VMS. Period.
In the VMS sources error message are never hard coded.
They are always symbolic and the symbols/values are generated from message sources files. If a a message is 'forgotten' a compile / link error (while building VMS) will occur and will be fixed.
The above has to be the assumtion / expectation. Sure, something may have sneeked by, but that's pretty darn unliekly and so an application problem is expected.

Now that application problem, may be due to a sub-optimal VMS setup choice ('surprise' location for an msg file) which VMS may be able to address, but it woudl be kinda od to run into that now, after decades of few / no problems

Groets,
Hein.

[Martin P.J. Zinser]

Hello Wim,

one more thing you could try:

Bracket the create/fdl operation in a

set watch file/class=major
create/fdl...
set watch file/class=none

This should provide addtional information on the attempted file system operations. Yes, I know set watch is undocumented, but I have it from a reliable source that it is save to use ;-)

Greetings, Martin

[Jan van den Ende]

SET WATCH is a real friend!!

(but don't forget it needs CMKRNL)

Jan

[Uwe Zessin]

CMEXEC works for me, too. But, anyone with CMEXEC privilege can get into kernel mode with a small program anyway...

[Wim Van den Wyngaert]

Found the reason.

While the procedure was doing create/fdl, another procedure was changing the protection on the directory in which the FDL was placed. Result : file currently locked by another user.

Wim
(wie zoekt die vindt)