1748179 Members
3922 Online
108758 Solutions
New Discussion юеВ

Re: Allocation Error

 
SOLVED
Go to solution
odwillia
Frequent Advisor

Allocation Error

We received this error in the afternoon and the same process completed fine earlier today.
Any suggestions? Thanks as always for your assistance. Let me know if you need more info.

%RENAME-E-OPENOUT, error opening DB$ROOT:[TRANS]DB_CX_DEL_DBO_TRANS__4SEP200814130351.DAT; as output
-RMS-E-ENT, ACP enter function failed
-SYSTEM-W-DIRALLOC, allocation failure on directory file
%SYSTEM-F-ABORT, abort
11 REPLIES 11
Hein van den Heuvel
Honored Contributor
Solution

Re: Allocation Error


Ah, cute one.

This means there is not enough CONTIGUOUS free space on the drive to re-allocate that directory 'one size bigger'

Workarounds
1) delete or rename away, some files from teh problem directory.
2) delete some large files which hopefully occupied contiguus space
3) compress the directory (DFU)
3) compress the directory slowly:
$SET DEF DB$ROOT:[000000]
$RENAM TRANS.DIR OLD.DIR
$CREATE/DIR [.TRANS] /prot... /own...
$RENAM [.OLD]*.*;* [.TRANS]

Be sure to download and check out DFU: http://www.digiater.nl/dfu

DFU REPORT DB$ROOT:
Soem privs to read bitmap.sys and a keen eye for details is all you need:
"Largest free extent (blocks)...."

The reason it may have worked before is that directories are ordered, but the blocks can be sparsely filled.
A delete can leave room to be filled by a futreu file in the same name range.
However, when a file name needs to be inserted where the block is full, and all the block in the directory file are used, then the systems needs to make space by allocating an entire fresh directory .. CONTIGUOUSLY... which failed.

Enjoy,
Hein.



Robert Gezelter
Honored Contributor

Re: Allocation Error

odwilla,

To amplify somewhat Hein's correct comments. Directories are required to be contiguous. Thus, if the amount of available contiguous space on the volume changes, the ability of the directory to expand can change.

As earlier noted, directories can become quite sparsely populated and substantially compressed. Either of the solutions that Hein mentions:
- using DFU
- using RENAME and a scratch directory (In such situations, I prefer to use a scratch directory to retain the original contiguous directory for the somewhat inevitable expansion).

- Bob Gezelter, http://www.rlgsc.com
Hein van den Heuvel
Honored Contributor

Re: Allocation Error



Btw...

Any such rename as I an bob suggested can get rather slow for large directories.
This is because blocks being emptied will be expunged as it proceeds.

Savvy folks for use $SET FILE/ENTER to populated a compressed parallel directory, rename and/or delete the old, and rename the new to the real name. See example below

But savvy folks possibly would not have asked this question to begin with!

$ set def [.tmp]
$ cre /dir [.a]
$ copy nl: [.a]x.1
$ copy nl: [.a]x.2
$ copy nl: [.a]x.3
$ copy nl: [.a]x.3
$ copy nl: [.a]x.1
$ dir/file [.a]
Directory [HEIN.TMP.A]
X.1;2 (129739,55,0)
X.1;1 (129731,47,0)
X.2;1 (129733,27,0)
X.3;2 (129738,63,0)
X.3;1 (129734,18,0)
Total of 5 files.$ cre /dir [.b]
$ cre /dir [.b]
$ set file/enter=[.b] [.a]*.*;*
$ set prot a.dir
$ set file/nodir a.dir
$ delete a.dir.
$ renam b.dir a
$ dir/file [.a]
Directory [HEIN.TMP.A]
X.1;2 (129739,55,0)
X.1;1 (129731,47,0)
X.2;1 (129733,27,0)
X.3;2 (129738,63,0)
X.3;1 (129734,18,0)
Total of 5 files.

odwillia
Frequent Advisor

Re: Allocation Error

Quite Savy indeed. Thanks for the quick responses.
Jon Pinkley
Honored Contributor

Re: Allocation Error

As with many shortcuts, there is a price to pay for using the set file/enter shortcut.

It leaves the backlink pointer in the file header pointing to the wrong directory (and when the directory is deleted, a non-existent directory).

The price is that lib$fid_to_name will not be able to return a valid path to the file.

$ dfu directory/compress does not suffer from that problem.

Attached is a zip file with a command procedure that demonstrates the problem, and a log file of its use.

Another thing to note is that the fid display returned by DCL's f$file_attributes(file,"FID") and the output of directory/file are the same. Also
the output returned by lib$fid_to_name and show device/file are the same. But the f$file_attributes(file,"FID") format is different than lib$fid_to_filename. Dump/header agrees with f$file_attibutes.

Excerpt from log file after the set file/enter, delete a.dir

$ open/read tmp [.A]X.1
$ ppf tmp
$ show symbol *_file*name
FID_FILE_NAME = "DISK$USER1:[436157,29,0]X.1;1"
ORG_FILE_NAME = "ROOT$USERS:[JON.SCRATCH.A]X.1;1"
PHY_FILE_NAME = "DSA1200:[USERS.][JON.SCRATCH.A]X.1;1"
$ show dev/file sys$disk

Files accessed on device DSA1200: on 5-SEP-2008 08:20:34.97

Process name PID File name
00000000 [000000]INDEXF.SYS;1
00000000 [000000]QUOTA.SYS;1
JON 202D3683 [436157,29,0]X.1;1
$ close tmp
$ exit
$ dir/file [.a]

Directory ROOT$USERS:[JON.SCRATCH.A]

X.1;1 (436187,33,0)

Total of 1 file.
$ exit
$! note difference in FID displayed by directory and show device/files (436187,33,0) vs. [436157,29,0]
$! which is correct? (it appears directory output is)
$ dump/wid=80/rec a.dir ! let's see what is in the directory

Dump of file ROOT$USERS:[JON.SCRATCH]A.DIR;1 on 5-SEP-2008 08:21:32.14
File ID (441691,13,0) End of file block 1 / Allocated 8

Record number 1 (00000001), 16 (0010) bytes, RFA(0001,0000,0000)

06000021 A7DB0001 00312E58 03007FFF ....X.1...├Г ├В┬з!... 000000
$ fid$w_num=%xA7DB
$ fid$w_seq=%x0021
$ fid$b_rvn=%x00
$ fid$b_nmx=%x06
$ fid_num=fid$b_nmx*%x10000+fid$w_num
$ fid=f$file_attributes("[.a]x.1","FID")
$ sho sym fid*
FID = "(436187,33,0)"
FID$B_NMX = 6 Hex = 00000006 Octal = 00000000006
FID$B_RVN = 0 Hex = 00000000 Octal = 00000000000
FID$W_NUM = 42971 Hex = 0000A7DB Octal = 00000123733
FID$W_SEQ = 33 Hex = 00000021 Octal = 00000000041
FID_NUM = 436187 Hex = 0006A7DB Octal = 00001523733
$

Looks like a bug in what lib$fid_to_name displays when path cannot be determined from backlinks.

The attached .zip file was created using the "-l" switch on VMS so it would create DOS compatible text files on windows. To unzip on VMS, set your default directory to where you want the files created, then use the command:

$ unzip "-aa" itrc_dir_compress

if you do not use "-a" or "-aa", every line will have a appended to the end.

Jon
it depends
Jess Goodman
Esteemed Contributor

Re: Allocation Error

You can fix the back-link problem on all the files in the directory by a simple:

$ RENAME [.A]*.*;* [.A]*.*;*

but of course that has the side-effect of resetting each file's modification date.
I have one, but it's personal.
Jon Pinkley
Honored Contributor

Re: Allocation Error

Jess,

I actually tried that, and it didn't do anything. If you rename to a different name or directory, it does fix the backlink, but there must be an optimization that makes the rename to the same directory/name a no op.

Jon
it depends
Jon Pinkley
Honored Contributor

Re: Allocation Error

For future reference, the testing I did was on Alpha VMS 7.3-2.
it depends
Jon Pinkley
Honored Contributor

Re: Allocation Error

My babbling about show dev/file showing the incorrect FID was bogus. It is displaying the DID'ed directory name, in this case the FID specified as the Back link identification, which is no longer valid.

Output from dump/header/block=(count:0) shows this:

Dump of file ROOT$USERS:[JON.SCRATCH.A]X.1;1 on 5-SEP-2008 13:57:26.95
File ID (436187,33,0) End of file block 0 / Allocated 0

,,,
File identification: (436187,33,0)
Extension file identification: (0,0,0)
...
Back link file identification: (436157,29,0)
...
Identification area
File name: X.1;1

So that's where the [436157,29,0]X.1;1 comes from. It isn't FID of the file, but of the directory the file was originally created in.

Sorry for the confusion.

Jon
it depends