Fragmented ACCOUNTNG.DAT file

[Duncan Morris]

Volker has provided the definitive explanation above. Whilst we can set a default extension quantity for the file, this is being overriden by the explicit value from JOB_CONTROL (as observed by Jack).

I would ignore ANALYZE options as this is just a sequential file. By far and away the simplest solution was provided by Hein. Use copy/alloc=nnn to pre-extend the file to a reasonable value.

As you are doing a weekly file creation, you will probably already have a good idea of what size you require for a week's worth of data.

[Hein van den Heuvel]

"comarow" wrote...
"It's very simple indeed to do an analyze/rms/fdl "
...which was pretty much the same as what Robert Boyd wrote.
Why bother (us)?

Wim wrote...
"This has nothing to do with the subject but when is HP going to check all VMS sources and enable a logical to set the initial allocation and the extent size (where it is not yet used of course) ?"

They did that once already, almost two decades ago. This is pretty much what caused this problem in the first place.
From jobctldef.req:
"WGP0005 ... 26-Jul-1989
! Add literals ACCT_FILE_ALQ and ACCT_FILE_DEQ for
! the initial allocation (currently disk default) and
! extend quantities (currently 25) for the Accounting file.
:
ACCT_FILE_DEQ= 100, ! Accounting file default ext size"

There are many, many offenders. MAIL.MAI and SYSUAF.DAT to name but a two. It is almost impossible (read: not worth the effort) for 'the system' to get it right for all users, all usages. IMHO the best thing the system can do is to do as little as possible, getting it mostly right but not prohibiting smart workarounds.

And now an other attempt to draw a smile, or at least a shake of the head in disbelieve...

As Volker said, JBC hardcodes DEQ to 100 and this overwrites the file/volume defaults.
So let's fix that!

Note, this is UNTESTED, but it should work (famous last words).

It helps (but is not critical :-) to have the listings. From account.lis
:
. 3 1811 $FAB_INIT(FAB=ACCOUNT_FAB_A,
:
P 3 1818 DEQ=ACCT_FILE_DEQ,
:

$SEARCH ACCOUNT.LIS "100," --->
47EC9415 0594 MOV 100, R21

That is a short literal for #100 in bits 13-20 there.
This can be changed readily to the max value of 255, or replaced by a register with a convenient value (up to 65535).
The 255 is not a major improvement over 100, so why not change it to 0 (R31) and make the system accept the file default?

See: Alpha AXP Ref Man, 3.3.3 Operate Instruction Format

$DUMP/OUT=JBC.EXE JBC.TMP
$SEARCH JBC.TMP 47EC9415,number
$PERL -ne "$b=$1 if /number (\d+)/;print $b,$_ if /47EC9415/" tmp.tmp

We find that block 66 (on my system) at offset 0xC0 contains:
B3F30200 42A09535 E320012B BF380000 47EC9415 47300419 47FD0413 4B360059
So our instruction 47EC9415 is at offset 0xCC

Ok... Onwards...

$ZAP JBC.EXE
(##, X##, S##, Debug, Format, Write, Exit) Option: 66
VBN=00000042, RSZ=0200, Data:
Dump: 4A7D0178 AEBB0040 4720F110 233D0041 B7FD0058 B7FD0050 43F60016 B7FD0048
(##, X##, S##, Debug, Format, Write, Exit) Option: d
%DEBUG-I-SSINOTSET,...
DBG> set rad hex
DBG> ex @r2+0cc
00000000000200CC: 47EC9415
DBG> ex/ins .
00000000000200CC: BIS R31,#X64,R21
DBG> exa/bin .
00000000000200CC: 0100011111101100 1001010000010101
DBG> dep . = 47FFF415
DBG> exa/bin .
00000000000200CC: 0100011111111111 1111010000010101
DBG> ex/ins .
00000000000200CC: BIS R31,#XFF,R21
DBG> dep . = 47FF0415
DBG> exa/bin .
00000000000200CC: 0100011111111111 0000010000010101
DBG> ex/ins .
00000000000200CC: BIS R31,R31,R21
DBG> go
(##, X##, S##, Debug, Format, Write, Exit) Option: w
(##, X##, S##, Debug, Format, Write, Exit) Option: e
%DEBUG-I-EXITSTATUS, is '%RMS-S-NORMAL, normal successful completion'


That ZAP program is one I wrote two decades ago.
It is published on the OpenVMS freeware in [RMS_TOOLS] and attached here.
It just reads and writes file blocks and uses the VMS debugger as main UI.
It specializes in indexed files (knows bucket size, first vbn and bucket header format), but can do any file as show here.
66 = read VBN 66
d = go into debugger with R2 pointing to block
go = exit from debugger
w = write current buffer to file
e = exit.

To those crazy/intrigued enough to read this far:
I know who you are (Ian, Duncan, Volker,... :-) and I salute you!

Regards,
Hein.

[Jack Trachtman]

And here I thought I was asking a pretty simple question ;-)

Combining the COPY/ALLOC with my weekly file recreate gets tricky (and is probably NOT worth doing) because I would then wind up with 2 new accounting files each week unless I did something like:

$ SET ACC/DIS
$ SET ACC/NEW
$ RENAME ACCOUNTNG.DAT; ACCOUNTNG.TMP
$ COPY ACCOUNTNG.TMP ACCOUNTNG.DAT/ALLOC=xxx
$ SET ACC/ENA=list
$ DELETE ACCOUNTNG.TMP;

[Duncan Morris]

Jack,

you can get sneaky with the copy

copy/alloc=xxxx nl: accountng.dat

Then you only have the "empty" new file, pre-allocated and ready to roll

[Hein van den Heuvel]

Jack, that series of commands seems perfectly right to me. it nicely preserves a valid forward link in the prior file.
Anyway, a dangling single extent (cluster) temp file is not too bad is it?

Duncan,
I like and use the COPY NL: a lot for simple variable lengt record file creates, however, ACCOUNTING maintains forward and backwards links in the last, resp first, records in the files. So i don't like this suggestion.

Cheers,
Hein.

[Duncan Morris]

Hein,

just a practical observation that 99% of system managers do not bother with the forward/backward links, but point taken.

[Ian Miller.]

A fasicinating discussion this has been.

Hein - I have a program called ZAP too - mine was intended to be like the RSX11 ZAP program for patching image files which I spent many hours with 20+ years ago.

Ideally hp would provide a logical to specify an allocation size or at least pick up the system default values which can be changed.

[Jan van den Ende]

Ian,



Ideally hp would provide a logical to specify an allocation size or at least pick up the system default values which can be changed.


Worth an Advocacy Issue?

My EUR 0.02

Proost.

Have one on me.

jpe

[Jack Trachtman]

Thanks all