Fragmented ACCOUNTNG.DAT file

[Jack Trachtman]

When I look at the fragmented files on my system disks, the ACCOUNTNG.DAT file usually shows up as a multi-header file.

Each week I issue an SET ACCOUNT/NEW cmd to create a new file. I realize that this is a minor issue, but is there some way I can change the extent growth of this file so it will be more efficient? Thanks

[Dale A. Marcy · Accepted solution]

I have not tried this, but I believe you can accomplish what you want by:

$ set accounting/disable
$ set file/extension= sys$manager:accountng.dat
$ set accounting/enable=

The above assumes the accounting file is in the default location.

[Robert_Boyd]

Here are a couple of ideas:

1. Stop accounting

2. Change file extension sizes

a. Set file/extension= ACCOUNTNG.DAT;* or,
b. set volume/extension= SYS$SYSDEVICE (or whatever place you have ACCOUNTNG pointing to)

3. Restart accounting


2.a is most likely to be effective.

Cheers,

Robert

[Arch_Muthiah]

Jack,

Whenever the system encounters an error while writing to the current accounting file, it automatically closes the current accounting.dat file and opens a new version of it. And you also creating new accounting.dat file each week. So there will be so many accounting files.

Unless otherwise there is a problem while writing info into accouting.dat file, VMS will keep write and extend the accounting.dat file automatically.
I hope we don't need to create new file every week or set the accounting file attribute. And even if we increase the file extend, when there is a problem while writing info into accouting, VMS automatically create the other files.


Archunan

[Jack Trachtman]

Thanks for the info - I'll try setting the file extent each week when I create a new file.

Archunan - we run hundreds of batch and print jobs daily. I reset the accounting file to make it a little easier to pull out information. (I have never seen VMS create a new accounting file on its own.)

[Dale A. Marcy]

Jack said:
"Thanks for the info - I'll try setting the file extent each week when I create a new file."

I believe you will only need to do this once, because I believe subsequent new files will take its defaults from the lower version (i.e., the one just closed).

I also agree that I have not seen VMS create a new accounting file on its own and have seen some systems where a new file has not been created for years.

[Arch_Muthiah]

Jack,

>(I have never seen VMS create a new
> accounting file on its own.)

I accept VMS won't create accounting.dat file for us, but I said ...
> Whenever the system encounters an error
> while writing to the current accounting
> file, it automatically closes the current > accounting.dat file and opens a new
> version of it.

This is correct.


Archunan

[Volker Halle]

Jack,

I'm sorry to disappoint you, but the file extension is not an attribute which gets inherited by the newly created ACCOUNTNG.DAT file.

So you would either have to the change the default extent size on the volume or do the following:

$ SET ACC/NEW
$ SET ACC/DISABLE
$ SET FILE/EXTENSION=n ACCOUNTNG.DAT
$ SET ACC/ENABLE=(list-of-keywords)

Volker.

[Volker Halle]

Jack,

OpenVMS uses a constant value for FAB$W_DEQ, there is no mechanism to change that.

But if you are really interested, you could patch the FAB$W_DEQ field in the ACCOUNTNG FAB(s) of JOB_CONTROL in the running system:

$ ANAL/SYS
SDA> SET PROC JOB_CONTROL
SDA> SHOW PROC ! note Master internal PID
SDA> SHOW PROC/RMS=FAB ! note FAB Address of ACCOUNTNG FAB

SDA> EXA +14 ! will show FAB$W_DEQ

SDA> EXIT

Example: assuming PID=00010011 and FAB$W_DEQ addr=70334, setting DEQ from 100. (0x64) to 200. (0xC8)

When running DELTA, you need to enter:

00010011:1;m ! set context to process for WRITE
[W ! set WORD display mode
70334/ 00C8 ! open location and store new value
exit ! exit from delta

$ RUN SYS$SHARE:DELTA
OpenVMS Alpha DELTA Debugger

Exit 00000001

80071674! LDQ R28,#X0008(SP) 00010011:1;m
00000001
[W

70334/0064 00C8
exit
$
$ SET ACC/NEW

You have to repeat this operation once more, as JOB_CONTROL used 2 FABs and switches them on each FAB-related operation. You'll see that there is another ACCOUNTNG FAB address after each SET ACC/NEW.

Once you've finished the second patch, the subsequent SET ACC/NEW will use your values deposited into FAB$W_DEQ.

This method is - of course - completely unsupported and using DELTA in WRITE mode may cause 'undesired effects' (like process or system crashes), but it's just an example on what you can do with OpenVMS default tools.

Volker.

[Ian Miller.]

A marvelous solution from Volker as usual but parhaps diving a bit deep - fun though :-)

Really there should be a OPC$ logical for the file extent. Time for someone to blow the dust of the OPCOM code and dive in :-)

[Robert_Boyd]

OK ... so obviously as has been stated, the OPCOM/JOBCTL code that manages the ACCOUNTNG file needs some tweaking to make allocation more efficient in its use of storage.

It is possible to preallocate space for the accounting file by having a bit of DCL that uses an FDL file from an ANALYZE/RMS/FDL.

To generate the FDL file

$ ANALYZE/RMS/FDL/OUTPUT=ACCOUNTNG.FDL SYS$MANAGER:ACCOUNTNG.DAT

Producing: ACCOUNTNG.FDL

IDENT "14-MAR-2006 08:07:04 OpenVMS ANALYZE/RMS_FILE Utility"

SYSTEM
SOURCE OpenVMS

FILE
ALLOCATION 120
BEST_TRY_CONTIGUOUS no
CLUSTER_SIZE 5
CONTIGUOUS no
EXTENSION 100
FILE_MONITORING no
GLOBAL_BUFFER_COUNT 0
NAME "SYS$SYSROOT:[SYSMGR]ACCOUNTNG.DAT;2"
ORGANIZATION sequential
OWNER [SYSTEM]
PROTECTION (system:RWED, owner:RWED, group:RE, world:)

RECORD
BLOCK_SPAN yes
CARRIAGE_CONTROL none
FORMAT variable
SIZE 0


Change the ALLOCATION to some really big number that you like(perhaps the typical size of a month's worth of entries? or whatever period you let it grow for). And just for grins, even though it apparently won't help a bit, change the EXTENSION size to something more reasonable than 100.


Then stop accounting ( SET ACC/DISABLE ).

$ BACKUP/OVERLAY

Restart Accounting

Cheers,

Robert

[Jack Trachtman]

Well, since people are still adding responses, I have an additional question:

I'm going to use the idea of:

$ SET ACC/NEW
$ SET ACC/DIS
$ SET FILE/EXT=....
$ SET ACC/ENA=...

New question: Is there an easy way to save the accounting keywords used before the /DIS for use with the /ENA without having to do a SHOW ACCOUNT/OUT=filename and parsing that file?

[Jan van den Ende]

Jack,

that is the easiest one!

$ ET ACCOUN /ENAB
without specifying WHAT to enable just re-enables what WAS enabled before the /DISABLE

hth

Proost.

Have one on me.

jpe

[Duncan Morris]

Jan,

if only it was that simple! Observe the attached result of doing /DISAB then /ENAB.
We have IMAGE accounting turned ON by the /ENAB, although is was off beforehand.
(Alpha 7.3-2)

[Hein van den Heuvel]

Robert wrote:
"It is possible to preallocate space for the accounting file by having a bit of DCL that uses an FDL file from an ANALYZE/RMS/FDL."

hmmm... If you go that route, then why not simply use

stop
COPY/ALLO='large 'old 'new
start

Hein.

[Jack Trachtman]

(I've reopened the thread)

As Duncan has pointed out (and is in the Help doc), a SET ACC/ENA w/o arguments enables *all* accounting. I found this out the hard way yesterday as I tested the answer to my original question. After a SET ACC/ENA caused Image records to be captured, a script we use to parse the SHOW ACCOUNTING/FULL output failed because the format changed.

I've since cobbled a quick script to parse the output of SHOW ACCOUNT/OUT=filename but wanted to know if there is any other way to get/save the present ACCOUNT settings.

[David Jones_21]

For other purposes, I set up the accounting file to be a mailbox and manage the accountng.dat file with my own program. It uses a more reasonable extension size than the 100 blocks hard coded into jobctl.

The trick is to create an ACCOUNTNG logical name for the mailbox in the group logical name table used by the JOBCTL process (LNM$GROUP_0000001). Using the group table instead of the system table means there is less interference to people using the accounting command.

[Ian Miller.]

David - interesting idea:-)

Jack - you can use the logical OPC$LOGFILE_CLASSES to select which classes are enabled - see SYS$STARTUP:SYLOGICALS.TEMPLATE

[Robert_Boyd]

Ian,

Are you SURE that OPC$LOGFILE_CLASSES has anything to do with Accounting? Last I remember this only provides a mechanism for controlling what goes into the Operator Log file.

Robert

[Wim Van den Wyngaert]

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) ?

Wim

[Ian Miller.]

Robert, re OPC$LOGFILE_CLASSES - yes nothing to do with accounting - obviously a momement of madness on my part.

[Robert_Boyd]

Ian,

Madness? or wishful thinking? ;-)

Robert

[Jack Trachtman]

This didn't seem to work for me:

- SET ACC/DIS
- SET FILE/EXTENT.....
- SET ACC/ENA

Monday I changed the file Extend quantity from its default of 100 to an arbitrary 1,000.

Using DUMP/HEADER on the file, I see that it is still growing at multiples of the disk cluster-size.

Did my change get overridden?

[Robert_Boyd]

Jack,

Did you try changing the volume extension size as well as the extension size on the file?

According to the comments about the hardcoded value of the file extend in the job control process code, I think the only thing that's going to help is pre-allocation.

You might try changing the volume extension value and see if that makes any difference -- I'll be surprised thought if it does.

Robert

[comarow]

While changing the allocation seems a great idea, finding an allocated file is often a problem.

It's very simple indeed to do an
analyze/rms/fdl accountng.dat
edit the fdl,
and put a huge number for additional records.

then convert/fdl=accountng.fdl accountng.dat

then purge the file.

It seems a design error on a lot of these files that they are not pre-allocated.