VMS 5.5.2 FORTRAN OPEN error 30 attempting to create file

[William Jones III]

The VAX FORTRAN manual does not provide specific info for this error. The file to be created would contain less than 40 blocks. There were 270K blocks of free diskspace. Directory contained less than 1000 files. Disk error count was zero. The program which creates these files does so for an average of 20 files/day. Each file is named "(nnnnnn_a)_HEAT_FILE.DAT". Ran ANALYZE/REPAIR. Several invalid directory entries repaired in other directories. Same error occurred day after repair. Attempted to recreate error by creating files at DCL command line in the affected directory. Varied results. Consistently succeeds in creating similarly named files. Consistently fails to create other filenames. No obvious pattern. Can provide more info on this error and possible solutions???

[Mike Kier]

What message(s) or $STATUS values do you get from the failed attempts at creating the files from DCL? What was the DCL command that failed?

[Hein van den Heuvel]

Hello William,

Welcome to the OpenVMS ITRC Forum.

I suspect that your problem is lack of CONTIGUOUS free space on the disk.

Directory entries are inserted in alphatical order in the directory blocks. When a block fills, the rest of the directory is shuffled up by a block and the directory may need to grow.
If it needs to grow, then a CONTIGUOS chunk of diskspace, larger then the current directory is allocated. If that fails, then the directory enty insertion fails, and thus the file create fails.

Some file name may be directed to directory blocks with some free space left, while others find a full block and trigger the (failing) growth.

270 K block free is really pittyful.

I recommend DFU to analyze the situation,
and/or the VMS Defrag tool in display mode.

You can also try:

$COPY /CONTIG/ALLO=NNN nl: tmp.tmp
where NNN = current directty size plus a few.
If that fails, then you know you are in trouble.

Good luck,

Hein
HvdH Performance Consulting.

[John Gillings]

William,

Presumably your program has an IOSTAT clause in the OPEN statement to catch the error status. Although that's good programming practice, to control behaviour in the case of errors, but it can obscure useful information, as any failure conditions are reduced to a single number.

If you omit the IOSTAT, the FORTRAN RTL will signal the whole condition, including secondary and tertiary RMS conditions.

If the condition is repeatable, try removing the IOSTAT clause from the OPEN statement, at least while you're debugging.

More generally, you can have the best of both worlds by writing your code like this:

OPEN( whatever... IOSTAT=stat)
IF(stat.EQ.expected-error1)THEN
deal with expected error1
ELSEIF(stat.EQ.expected-error2)THEN
deal with expected error2
ELSEIF (other expected errors)
...
ELSEIF (unknown error) THEN
OPEN(same as above but without IOSTAT)
ENDIF

(Oh, and here's a nickle, go buy youself a GB of disk space! Work out how much of your time 270K blocks of disk is worth - probably just a few seconds)

[Mike Kier]

Also, immediately following an I/O statement that returns an error either via ERR= or IOS=iostat you can call the FORTRAN intrinsic ERRSNS to get the RMS STS and STV values:

ERRSNS ([io-err] [,sys-err] [,stat] [,unit] [,cond])

io-err - Stores the most recent Fortran error number that occurred during program execution. The value is zero if no error has occurred.

sys-err - Stores the most recent RMS STS status code.

stat - Stores the most recent RMS STV status value. This status value provides additional status information.

unit - Stores the logical unit number (if the last the last error was an I/O error).

cond - Stores the actual processor value. This value is always zero.

[Phillip Thayer]

I tend to agree with Hein. I also have seen very strange things happen on disks that get almost full and fragmented. If you don't have a defragmentation tool then you will have to find time to backup the disk to tape, initialize the disk and restore it from tape. Also, when you do an analyze/disk/rep on a drive look in the [SYSLOST] directory and see if it recovered any files. If they are not needed then delete them. You may be able to recover space that way.

Phil