Error creating File on disk.

[Craigers01]

I had an issue the other night where I could no longer create a file on disk. I am running OpenVMS 6.2. I do not recall the exact error message. It was along the lines of "ACP header full'. It definately started "ACP", and said somethig was full. This was in the middle of the night, I was foggy.

There was plenty of free space on the disk. I purged the files on the disk and it resolved the issue. I would love to understand better what the issue was so that I could monitor for it and fix proactively (in the daytime :).

What approach can I take to figure out what the problem was and how to monitor for it on this as well as my other disks.

Thanks in advance,

Craig

[Volker Halle]

Craig,

VSI has published all the old 'Ask the Wizard' articles.

Could this be related: (0065) Resolving HEADERFULL Errors - VSI OpenVMS Forum (vmssoftware.com)

There is also a lengthy discussion here in this forum:

unable to create file on the disk - Hewlett Packard Enterprise Community (hpe.com)

Volker.

[Craigers01]

I agree. I think this is my problem. I would like to be able to quantify the issue so that I could create a DCL script to check all my disks and alert if they approach this limit. If do not have the DFU installed. The articles recommend dumping the header as well as a "dir/full". I can see that I have numerous Map Areas. But I do not see clearly, how to determine the maxium. Below are the results of those tests:

sh dev/full cam1

Disk DSA214:, device type (type not yet identified), is online, mounted, file-
    oriented device, shareable, available to cluster, error logging is enabled.

    Error count                    0    Operations completed           26621809
    Owner process                 ""    Owner UIC            [CXXM,SYSINIT]
    Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,W
    Reference count               11    Default buffer size                 512
    Total blocks             8378028    Sectors per track                    53
    Total cylinders             2928    Tracks per cylinder                  54

    Volume label              "CAM1"    Relative volume number                0
    Cluster size                   9    Transaction count                    10
    Free blocks              5625468    Maximum files allowed            418901
    Extend quantity                5    Mount count                           4
    Mount status              System    Cache name             "_DSA2:XQPCACHE"
    Extent cache size             84    Maximum blocks in extent cache   562546
    File ID cache size            64    Blocks currently in extent cache  22644
    Quota cache size               0    Maximum buffers in FCP cache       6640
    Volume owner UIC          [11,3]    Vol Prot    S:RWCD,O:RWCD,G:RWCD,W:RWCD

  Volume Status:  subject to mount verification, do not unload on dismount,
      write-back caching enabled.
  Volume is also mounted on EXX01, PXX02, PXX01.

Disk $100$DUA2162:, device type (type not yet identified), is online, member of
    shadow set DSA214:, served to cluster via MSCP Server, error logging is
    enabled.

    Error count                    0    Shadow member operation count  26595473
    Host name               "VHSD00"    Host type, avail              HSCX, yes
    Alternate host name     "PXX02"    Alt. type, avail      VAX 7000-630, yes
    Allocation class             100

dump/head/block=count:0 cam1:[000000]indexf.sys


Dump of file CAM1:[000000]INDEXF.SYS;1 on  7-MAR-2023 15:51:10.45
File ID (1,1,0)   End of file block 200142 / Allocated 200142

                             File Header

Header area
    Identification area offset:           40
    Map area offset:                      100
    Access control area offset:           255
    Reserved area offset:                 255
    Extension segment number:             0
    Structure level and version:          2, 1
    File identification:                  (1,1,0)
    Extension file identification:        (0,0,0)
    VAX-11 RMS attributes
        Record type:                      Fixed
        File organization:                Sequential
        Record attributes:                <none specified>
        Record size:                      512
        Highest block:                    200142
        End of file block:                200143
        End of file byte:                 0
        Bucket size:                      0
        Fixed control area size:          0
        Maximum record size:              512
        Default extension size:           0
        Global buffer count:              0
        Directory version limit:          0
    File characteristics:                 Contiguous best try
    Map area words in use:                155
    Access mode:                          0
    File owner UIC:                       [11,3]
    File protection:                      S:RWED, O:RWED, G:RE, W:
    Back link file identification:        (4,4,0)
    Journal control flags:                <none specified>
    Active recovery units:                None
    Highest block written:                200142

Identification area
    File name:                            INDEXF.SYS;1                          
    Revision number:                      4717
    Creation date:                        20-APR-1993 10:42:11.01
    Revision date:                         6-MAR-2023 09:13:07.76
    Expiration date:                      <none specified>
    Backup date:                           6-MAR-2023 13:55:39.31

Map area
    Retrieval pointers
        Count:         18        LBN:          0
        Count:          9        LBN:       1026
        Count:          9        LBN:    4250313
        Count:      61056        LBN:    4189257
        Count:       6138        LBN:    7691688
        Count:       8973        LBN:    7639488
        Count:       6039        LBN:    7096104
        Count:       5283        LBN:    6931755
        Count:       5076        LBN:    6898455
        Count:       4797        LBN:    7552440
        Count:       4500        LBN:    7061481
        Count:       4410        LBN:    6996807

Dump of file CAM1:[000000]INDEXF.SYS;1 on  7-MAR-2023 15:51:10.45
File ID (1,1,0)   End of file block 200142 / Allocated 200142

        Count:       4158        LBN:    8084718
        Count:       3411        LBN:    7995231
        Count:       3249        LBN:    7365213
        Count:       3195        LBN:    7217190
        Count:       3078        LBN:    6731370
        Count:       2943        LBN:    8252775
        Count:       2727        LBN:    6472791
        Count:       2718        LBN:     354492
        Count:       2655        LBN:    6276492
        Count:       2637        LBN:    4176144
        Count:       2583        LBN:    8197938
        Count:       2556        LBN:    7287732
        Count:       2430        LBN:    8178651
        Count:       2412        LBN:    7408521
        Count:       2412        LBN:    7954344
        Count:       2394        LBN:    7386741
        Count:       2313        LBN:    8024319
        Count:       2241        LBN:    6086574
        Count:       2223        LBN:    6261606
        Count:       2223        LBN:    8065845
        Count:       2214        LBN:    6829812
        Count:       2196        LBN:    7439256
        Count:       2196        LBN:    7023753
        Count:       2160        LBN:    6114798
        Count:       2097        LBN:     399024
        Count:       2052        LBN:    6495354
        Count:       2043        LBN:    6705234
        Count:       1998        LBN:    4138956
        Count:       1998        LBN:    6766362
        Count:       1971        LBN:    7030179
        Count:       1935        LBN:     440406
        Count:       1926        LBN:    6104421
        Count:       1872        LBN:    6482169
        Count:       1836        LBN:    7880400
        Count:       1818        LBN:    6927741
        Count:       1800        LBN:     283995
        Count:       1863        LBN:    4416300
        Count:       1791        LBN:    7027992
        Count:       1764        LBN:    7443882
        Count:       1746        LBN:    2967489

Checksum:                                 45965

[Volker Halle]

Craig,

there are 52 retrieval pointers in your INDEXF.SYS file header. The first 3 of them would be 4 bytes long, the rest wil be 6 bytes long. The Map Area begins at offset 100*2 = 200. The space used in the file header, which is 512 bytes long minus 2 bytes for the checksum word, is filled: 200 + 3x4 + 49*6 + 2 = 508.. So there is no room in the INDEXF.SYS file header for another retrieval pointer, which means that the index file cannot be expanded anymore, if all file headers in INDEXF.SYS are used up and you want to create another file.

You could dump block 4050313, which should be the Backup Index File header (at beginning of 4th cluster in INDEXF.SYS). It should be filled with retrieval pointer data up to the end of the disk block. Use DUMP/BLOCK=(START=4050313, COUNT=1)  DSA214:

To format this block as a file header use DUMP/FILE/BLOCK=(START=4050313,COUNT=1)  DSA214: - use this to verify my calculation. It should show INDEXF.SYS.

You could then calculate the no. of possible file headers, which would fit into the current INDEXF.SYS file: size of INDEXF.SYS - 4x9 - size of Index File Bitmap in blocks (available from HM2$W_IBMAPSIZE field in Home Block = LBN 1 of disk). This should give you the maximum no. of possible files on this disk.  

Then check the no. of files already on the disk (DIR/TOTAL DSA214:[*...]) against the maximum no. of possible file headers calculated above.

Volker.

[Craigers01]

Both DUMP commands show this:

DUMP/FILE/BLOCK=(START=4050313, COUNT=1)  DSA214:



Dump of device DSA214: on  8-MAR-2023 11:51:03.56

Logical block number 4050313 (003DCD89), 512 (0200) bytes

 4554002E 313B4941 4D2E3739 30303530 30304137 42384139 4538244C 49414D5D ]MAIL$8E9A8B7A00050097.MAI;1..TE 000000
 30304241 34313331 3039244C 49414D5D 324C4155 515F545B 3A314345 50534D52 RMSPEC1:[T_QUAL2]MAIL$901314AB00 000020
 324C4155 515F545B 3A314345 50534D52 4554002E 313B4941 4D2E3739 30303530 050097.MAI;1..TERMSPEC1:[T_QUAL2 000040
 4554002E 313B4941 4D2E3739 30303530 30303232 36464432 3039244C 49414D5D ]MAIL$902DF62200050097.MAI;1..TE 000060
 30303136 44433934 3039244C 49414D5D 324C4155 515F545B 3A314345 50534D52 RMSPEC1:[T_QUAL2]MAIL$9049CD6100 000080
 324C4155 515F545B 3A314345 50534D52 4554002E 313B4941 4D2E3639 30303530 050096.MAI;1..TERMSPEC1:[T_QUAL2 0000A0
 4554002E 313B4941 4D2E3639 30303530 30303046 36443642 3039244C 49414D5D ]MAIL$90B6D6F000050096.MAI;1..TE 0000C0
 30304331 32443233 3139244C 49414D5D 324C4155 515F545B 3A314345 50534D52 RMSPEC1:[T_QUAL2]MAIL$9132D21C00 0000E0
 324C4155 515F545B 3A314345 50534D52 4554002E 313B4941 4D2E3739 30303530 050097.MAI;1..TERMSPEC1:[T_QUAL2 000100
 4554002E 313B4941 4D2E3739 30303530 30303239 39454436 3239244C 49414D5D ]MAIL$926DE99200050097.MAI;1..TE 000120
 30303839 31443631 3339244C 49414D5D 324C4155 515F545B 3A314345 50534D52 RMSPEC1:[T_QUAL2]MAIL$9316D19800 000140
 324C4155 515F545B 3A314345 50534D52 4554002E 313B4941 4D2E3639 30303530 050096.MAI;1..TERMSPEC1:[T_QUAL2 000160
 4554002E 313B4941 4D2E3739 30303530 30304245 38364632 3339244C 49414D5D ]MAIL$932F68EB00050097.MAI;1..TE 000180
 30304546 42333841 3339244C 49414D5D 324C4155 515F545B 3A314345 50534D52 RMSPEC1:[T_QUAL2]MAIL$93A83BFE00 0001A0
 324C4155 515F545B 3A314345 50534D52 4554002E 313B4941 4D2E3739 30303530 050097.MAI;1..TERMSPEC1:[T_QUAL2 0001C0
 4554002E 313B4941 4D2E3739 30303530 30304341 35314134 3439244C 49414D5D ]MAIL$944A15AC00050097.MAI;1..TE 0001E0

[Volker Halle]

Craig,

sorry about that. I used the LBN from my system - instead of yours ;-(

Please try again with:   4189257

I did not get a mail notification about your reply, otherwise I would have replied earlier.

Volker. 

[Craigers01]

I posted the new output below.

Once I can quantify my issue, I would like to prevent this issue through maintenance or application redesign. Can you explain at a high-level, what is going on?

Is it true that INDEXF.SYS has a limit of how many "extents" it can have and that the term "extents", in this context, mean how many times the file can be enlarged. I am doing a lot of research on Defrag (we have Polycenter File Optimizer). I feel like I may be getting defrag extents muddled with file extents.

How does the fragmentation of my disk contribute to this issue (if at all). If I defrag my disk, would it decrease the size of INDEXF.SYS?

This disk contatins a lot of log files that grow continuously over a long time. Defrag cannot defrag these files since they are always open. Would I benefit from closing these log files on occasion so that they would remain less fragmented? is this or any other approach helpful?

DUMP/FILE/BLOCK=(START=4189257, COUNT=1)  DSA214:

Dump of device DSA214: on  9-MAR-2023 08:43:35.42

Logical block number 4189257 (003FEC49), 512 (0200) bytes

 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 000000
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 000010
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 000020
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 000030
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 000040
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 000050
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 000060
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 000070
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 000080
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 000090
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 0000A0
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 0000B0
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 0000C0
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 0000D0
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 0000E0
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 0000F0
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 000100
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 000110
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 000120
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 000130
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 000140
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 000150
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 000160
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 000170
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 000180
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 000190
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 0001A0
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 0001B0
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 0001C0
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 0001D0
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 0001E0
 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................ 0001F0

[Volker Halle]

Craig,

sorry - still wrong ;-(

Craig,

I wrote: Backup Index File header (at beginning of 4th cluster in INDEXF.SYS)

        Count:         18        LBN:          0
        Count:          9        LBN:       1026
        Count:          9        LBN:    4250313

On your disk, each cluster is 9 blocks in size. The 4th cluster starts at LBN:  4250313 - my '4050313' was just a typo ;-(

Once you've dumped the correct INDEXF.SYS header block and you'll see, that it is filled up with retrieval pointers to the end, we can discuss the rest...

The fine details of the OpenVMS File System are documented here:

EY-F575E-DP_VMS_File_System_Internals_1990.pdf (bitsavers.org)

Volker.

[Craigers01]

Here is the new DUMP. I added "/oct" to help with formatting. It was a mess without.

DUMP/BLOCK=(START=4250313, COUNT=1)  DSA214:/oct 

Dump of device DSA214: on  9-MAR-2023 11:49:49.08

Logical block number 4250313 (0040DAC9), 512 (0200) bytes

 00000000000 00000200001 00200200000 37777662050 (d.............. 000000
 01563600003 01563400003 00200000001 00000000000 ..........Î...Ï. 000020
 00000000000 00000000000 00000001000 00000000000 ................ 000040
 00002200003 00046777000 00000000040 00000000000 .... .......... 000060
 00000606717 00000000000 00000000004 00001175000 .ú..........Ï... 000100
 04010020040 06116651531 12313443130 10521047111 INDEXF.SYS;1     000120
 14150000226 26474164615 11210011146 04010020040     f. J.é...a 000140
 13750000000 00000000000 00000000270 05541023751 é'.-.........._ 000160
 04010020040 04010020040 04010000270 06045160102 Bà.0.           000200
 04010020040 04010020040 04010020040 04010020040                  000220
 04010020040 04010020040 04010020040 04010020040                  000240
 04010020040 04010020040 04010020040 04010020040                  000260
 00400440010 00000040021 04010020040 04010020040         .@...@.. 000300
 22776200077 35422367177 30000000100 33262300010 ..ÉÚ@..À.îIì?.ù. 000320
 00033043450 22745400164 22160121414 00035256650 ¤]u..£À.t...(Gl. 000340
 07556111274 00032241427 22364600151 30512712242 ¢.+Åi.Ó..Ci.¼.= 000360
 22017200152 30321710471 00032737751 22144600163 s...é¿k.9.GÃj.=. 000400
 00034061135 21454000171 37727706522 00036656356 î\{.R._.y.°.]bp. 000420
 35531705576 00031533152 21401200156 04011506172 z.& n...j¶f.~.gí 000440
 21227400005 15057105235 00030542127 21251400175 }..WÄb...¼h..^. 000460
 00037213462 21205400077 27104105114 00027742614 .Å_.L..¹?...2.}. 000500
 01342304553 00037145733 21137200157 06355104773 û.3o.}.ÛË|.k... 000520
 21102000160 26635304531 00036257650 21132600161 q.k.¤_y.Y.u¶p... 000540
 00027705546 21053400134 33753504300 00036470377 .pz.À.ß\..f._. 000560
 20346104223 00032033364 21051200173 02315304256 .5.{.¥.ô6h..... 000600
 21014000135 11573504157 00032626211 21044600161 q....,k.o.îM].0. 000620
 00031450122 20776400143 03436504003 00001413260 °.....z.c.ú.RPf. 000640
 10550703662 00031637432 20763200077 04763103715 Í.Ì'?.Í..?g.².£E 000660
 20723600135 04531303605 00001534126 20743400153 k...V....e%].O. 000700
 00032332575 20706200170 07664103453 00030564371 ùèb.+.>x...}µi. 000720
 07506103376 00020661454 20721400004 12526703407 ..[U..F.,cC...= 000740
 37323200055 10760303321 00034312652 20670600153 k.ã.ª.q.Ñ.ÁG-.Mû 000760

DUMP/FILE/BLOCK=(START=4250313, COUNT=1)  DSA214:


Dump of device DSA214: on  9-MAR-2023 11:44:27.10

Logical block number 4250313 (0040DAC9), 512 (0200) bytes

Header area
    Identification area offset:           40
    Map area offset:                      100
    Access control area offset:           255
    Reserved area offset:                 255
    Extension segment number:             0
    Structure level and version:          2, 1
    File identification:                  (1,1,0)
    Extension file identification:        (0,0,0)
    VAX-11 RMS attributes
        Record type:                      Fixed
        File organization:                Sequential
        Record attributes:                <none specified>
        Record size:                      512
        Highest block:                    200142
        End of file block:                200143
        End of file byte:                 0
        Bucket size:                      0
        Fixed control area size:          0
        Maximum record size:              512
        Default extension size:           0
        Global buffer count:              0
        Directory version limit:          0
    File characteristics:                 Contiguous best try
    Map area words in use:                155
    Access mode:                          0
    File owner UIC:                       [11,3]
    File protection:                      S:RWED, O:RWED, G:RE, W:
    Back link file identification:        (4,4,0)
    Journal control flags:                <none specified>
    Active recovery units:                None
    Highest block written:                200142

Identification area
    File name:                            INDEXF.SYS;1                                                                          
    Revision number:                      4710
    Creation date:                        20-APR-1993 10:42:11.01
    Revision date:                        26-FEB-2023 16:02:14.33
    Expiration date:                      <none specified>
    Backup date:                           2-MAR-2023 13:39:29.05

Map area
    Retrieval pointers
        Count:         18        LBN:          0
        Count:          9        LBN:       1026
        Count:          9        LBN:    4250313
        Count:      61056        LBN:    4189257
        Count:       6138        LBN:    7691688
        Count:       8973        LBN:    7639488
        Count:       6039        LBN:    7096104
        Count:       5283        LBN:    6931755
        Count:       5076        LBN:    6898455
        Count:       4797        LBN:    7552440
        Count:       4500        LBN:    7061481
        Count:       4410        LBN:    6996807
        Count:       4158        LBN:    8084718
        Count:       3411        LBN:    7995231
        Count:       3249        LBN:    7365213
        Count:       3195        LBN:    7217190
        Count:       3078        LBN:    6731370
        Count:       2943        LBN:    8252775
        Count:       2727        LBN:    6472791
        Count:       2718        LBN:     354492
        Count:       2655        LBN:    6276492
        Count:       2637        LBN:    4176144
        Count:       2583        LBN:    8197938
        Count:       2556        LBN:    7287732
        Count:       2430        LBN:    8178651
        Count:       2412        LBN:    7408521
        Count:       2412        LBN:    7954344
        Count:       2394        LBN:    7386741
        Count:       2313        LBN:    8024319
        Count:       2241        LBN:    6086574
        Count:       2223        LBN:    6261606
        Count:       2223        LBN:    8065845
        Count:       2214        LBN:    6829812
        Count:       2196        LBN:    7439256
        Count:       2196        LBN:    7023753
        Count:       2160        LBN:    6114798
        Count:       2097        LBN:     399024
        Count:       2052        LBN:    6495354
        Count:       2043        LBN:    6705234
        Count:       1998        LBN:    4138956
        Count:       1998        LBN:    6766362
        Count:       1971        LBN:    7030179
        Count:       1935        LBN:     440406
        Count:       1926        LBN:    6104421
        Count:       1872        LBN:    6482169
        Count:       1836        LBN:    7880400
        Count:       1818        LBN:    6927741
        Count:       1800        LBN:     283995
        Count:       1863        LBN:    4416300
        Count:       1791        LBN:    7027992
        Count:       1764        LBN:    7443882
        Count:       1746        LBN:    2967489

Checksum:                                 64333

[Volker Halle]

Craig,

you're confusing me by using DUMP/OCTAL - please don't do this. DUMP/HEX is the default on OpenVMS.

Now you've dumped the correct backup index file header. And you can see, that the Map Area in the index file header is completely filled with retrieval pointers. So there is no room for more retrieval pointers in the INDEXF.SYS header. The INDEXF.SYS file cannot be expanded/extended anymore, because it can only have ONE file header. All file headers of the files on that disk are stored in INDEXF.SYS. If all file headers are in use, you can't create any more files on this disk, because each file needs a file header and all file header storage in INDEXF.SYS is filled up.

DFO has a DEFRAGMENT_OFFLINE command to defragment INDEXF.SYS, but the disk can not be mounted during this operation.

BACKUP/IMAGE would also 'defragment' your INDEXF.SYS - again the disk must be dismounted to do this.

Check whether the no. of files on that disk ($ DIR/TOT DSA241:[*...]) is near Maximum files allowed: 418901. If so, you would need to INIT/MAXIMUM_FILES=n a new disk and use BACKUP/IMAGE/NOINIT to backup up your existing disk to the newly inited one.

'Extents' are the chunks of contiguous blocks, which make up the allocated space for a file. Each 'extent' is described by a retrieval pointer. The retrieval pointers are stored in the file header of that file. If a file has many extents, it's said to be 'fragmented'.  If you have many files with lots of extents, than your disk is 'fragmented'. DFO can help to defragment the disk - at least the closed files - and consolidate free space on your disk.

Volker.

[Craigers01]

Here is the dump format you asked for.

DUMP/BLOCK=(START=4250313, COUNT=1)  DSA214:




Dump of device DSA214: on 10-MAR-2023 12:06:34.45

Logical block number 4250313 (0040DAC9), 512 (0200) bytes

 0DCF0003 0DCE0003 02000001 00000000 00000000 00010001 02010000 FFFF6428 (d........................Î...Ï. 000000
 00090003 009BFE00 00000020 00000000 00000000 00000000 00000200 00000000 .................... .......... 000020
 20202020 313B5359 532E4658 45444E49 00030DCF 00000000 00000004 0004FA00 .ú..........Ï...INDEXF.SYS;1     000040
 5FA00000 00000000 000000B8 2D8427E9 61A00096 B4F0E98D 4A201266 20202020     f. J.é...aé'.-.........._ 000060
 20202020 20202020 20202020 20202020 20202020 20202020 202000B8 3094E042 Bà.0.                           000080
 20202020 20202020 20202020 20202020 20202020 20202020 20202020 20202020                                  0000A0
 97F9003F EC49EE7F C0000040 DAC98008 04024008 00004011 20202020 20202020         .@...@....ÉÚ@..À.îIì?.ù. 0000C0
 3DB892BC 00694317 93D30069 C52B94A2 006C4728 97960074 91C0A30C 00755DA8 ¤]u..£À.t...(Gl.¢.+Åi.Ó..Ci.¼.= 0000E0
 0070625D 8CB00079 FF5F8D52 007B5CEE 903D006A C3479139 006BBFE9 91930073 s...é¿k.9.GÃj.=.î\{.R._.y.°.]bp. 000100
 8A5E0005 68BC8A9D 0062C457 8AA6007D ED678B7E 0066B66A 8C05006E 20268C7A z.& n...j¶f.~.gí}..WÄb...¼h..^. 000120
 0B89896B 007CCBDB 897D006F 33B489FB 007D1732 8A16003F B9108A4C 005FC58C .Å_.L..¹?...2.}.û.3o.}.ÛË|.k... 000140
 005F8B66 88AE005C DFAE88C0 007A70FF 89080070 B6758959 00795FA8 896B0071 q.k.¤_y.Y.u¶p....pz.À.ß\..f._. 000160
 8830005D 4DEE886F 006B2C89 88930071 83988893 006836F4 88A5007B 133588AE .5.{.¥.ô6h.....q....,k.o.îM].0. 000180
 45A387B2 00673F1A 87CD003F 27CC87CD 00665052 87FA0063 1C7A8803 000616B0 °.....z.c.ú.RPf.Í.Ì'?.Í..?g.².£E 0001A0
 0069B57D 87190078 3ED0872B 0062E8F9 874F005D 25658785 0006B856 878E006B k...V....e%].O.ùèb.+.>x...}µi. 0001C0
 FB4D002D 47C186D1 007195AA 86E3006B 3D1886FE 0043632C 87460004 555B8707 ..[U..F.,cC...=k.ã.ª.q.Ñ.ÁG-.Mû 0001E0

I have started reading the document you linked about VMS file org. I am learning, but I have more reading to do.

I think I understand the issue of INDEXF.SYS being at its maxium extents. If I were to take the disk offline and Defag OFFLINE_VOLUME, would that free up all of its extents? The disk is not neart the maxium files; it has 31,235 files.

[Volker Halle]

Craig,

a quick check:

Checksum:                                 64333

FB4D

AXPVMS $ sho sym x
X = 64333 Hex = 0000FB4D Octal = 00000175515

YES, the last word in the dump of this block matches the Checksum: reported in DUMP/HEADER , so this is the correct backup index file header.

For DEFRAG OFFLINE_VOLUME to be able to reduce the no. of extents of INDEXF.SYS , the disk would need enough free contiguous free space.

Your INDEXF.SYS is 200142 blocks long, so there is room for about 200142-36=200106 file headers (including possible file extension headers for heavily fragmented files !) If there are currently only 31,235 files on that disk, those will most likely be very heavily fragmented files and will have - on average - about 6 extension file headers. If files are getting extended and there is no room in the (primary) file header, another file header has to be allocated (an extension file header).

You would see this in DUMP/HEADER as a non-zero extension file ID:

Extension file identification:        (0,0,0)

The above is from INDEXF.SYS, which can not have an extension file header.

Did you ever let DEFRAG report on the status of this disk ? It should be severely fragmented ! DEFRAG will also tell you the biggest free extent on this disk. A DEFRAG report can not do any harm to the disk.

The easiest thing to do would be BACKUP/IMAGE - if you have a spare disk or another disk with enough space to accomodate a backup saveset of this disk. This should eliminate all the extents of INDEXF.SYS and also the - believed - fragmentation of your disk.

Volker.

[Craigers01]

The disk was terribly fragmented, like 80ish index. The defragger could not do much due to the numerous open log files. I restarted all of the processes in order to close the existing/long/fragmented log files. I then purged the disk. I then started the defrag process on the disk, and we are in much better shape:

DFO> show /volume cam1

                   F r a g m e n t a t i o n    R e p o r t

CAM1                                                     13-MAR-2023 12:37:09.80

The fragmentation index is 36.3
      1 - 20.9 is excellent
     21 - 40.9 is good
     41 - 60.9 is fair
     61 - 80.9 is poor
     81 - 100 indicates a badly fragmented disk
Approximately 26.9 (out of 80.0 possible) is due to file fragmentation
Approximately 9.3 (out of 20.0 possible) is due to freespace fragmentation


Freespace Summary:
        Total free space:       6081084 blocks
        Total free extents:        2188
        Maximum free extent:     262188 blocks, LBN: 936738
        Minimum free extent:          9 blocks, LBN: 1640232
        Average free extent:       2779 blocks
        Median free extent:          63 blocks


File Fragmentation Summary:
        Number of files (with some allocation):  25637
        Total file extents on the disk:          27495
        Average number of file extents per file: 1.072473
        Median number of file extents per file:  1

Most Fragmented File:
        [AANDERSON.MAIL]MAIL.MAI;1 (262 extents)

We have an opportunity in two weeks to shutdown the applications. We could even dismount the disk. It seems easiest to defrag OFFLINE_VOLUME versus using backup to rebuild the disk. Our virtual VAX attaches to SAN storage, and that involves cooridation with our SAN people and some configuration to map the new disk. Do you think the defag should be sufficient, or should I commit to rebuilding?

Thanks!

Craig

[Volker Halle]

Craig,

your INDEXF.SYS has space for about 200000 file headers. You only have 25637 files on your disk now and a little bit more than 1 extent per file.

I won't worry about compressing your index file. DEFRAG has done it's job to reduce the extents and possibly gotten rid of lots of  file extension headers ! Look at the first DEFRAG report (with fragmentation index of 80%) for the Median of file extents per file.

Volker.

[Craigers01]

Surprisingly, the median file extents was "1", lol. The average was 1.44. I think the PROBLEM was that numerous files had hundreds. After app restarts, and purges, those have gone away. My INDEXF.SYS still has 52 extents though. I was expectign those to go down.

DEFRAG SHOW/VOLUME CAM1
POLYCENTER File Optimizer for OpenVMS DFG V2.1A
© 1995, Digital Equipment Corporation

                   F r a g m e n t a t i o n    R e p o r t

CAM1                                                      6-MAR-2023 09:28:31.19

The fragmentation index is 86.4
      1 - 20.9 is excellent
     21 - 40.9 is good
     41 - 60.9 is fair
     61 - 80.9 is poor
     81 - 100 indicates a badly fragmented disk
Approximately 66.4 (out of 80.0 possible) is due to file fragmentation
Approximately 20.0 (out of 20.0 possible) is due to freespace fragmentation


Freespace Summary:
        Total free space:       5423247 blocks
        Total free extents:       26586
        Maximum free extent:      18225 blocks, LBN: 671328
        Minimum free extent:          9 blocks, LBN: 1721529
        Average free extent:        203 blocks
        Median free extent:          63 blocks


File Fragmentation Summary:
        Number of files (with some allocation):  46683
        Total file extents on the disk:          67670
        Average number of file extents per file: 1.449564
        Median number of file extents per file:  1

Most Fragmented File:
        [ACT_MGR]ITRAV_CS_CSCOM.LOG;52 (1150 extents)

[Volker Halle]

Craig,

if your application is creating and writing lots of sequential log files on this disk, you might want to set meaningful file extend sizes:

$ SET RMS/EXTEND_QUANTITY=n  [/SYSTEM]        ! for each process or system-wide 

$ SET FILE/EXTENSION=n                                             ! for existing files

$ MOUNT/EXTENSION=n                                               ! for all NEW files created on the disk

This could prevent unnecessary extends of the file, which would lead to disk fragmentation again.

So if a file grows by 100 blocks per day, you could SET FILE/EXTENSION=10000, so it only needs to be extended about every 3 months.

Volker.

[Craigers01]

I am having no luck coercing my log file to use 10000 extents. I am trying to avoid doing this for all files on the disk. My DCL script, which runs periodically to restart the application process (TCP server), runs a detached process. I tried setting the extend value for the process that creates the detached process, as well as including it in the script the the detached proecss uses. Both of these appear to be ignored (both methods are in the code snippet below).

I even tried creating a new log file, and setting the extents on the log file (which worked). I then passed this specific file/version as the "/output" parameter, and DCL overwrote the file/version I had created with a new one. I was confused as to why my extents mysteriously changes until I saw the FILEID had changed.

$     SET RMS/EXTEND_QUANTITY=10000
$     open/write OutFile 'cscom_name
$         write OutFile "$ SET PROC/PRIV=ALL"
$         write OutFile "$ SET OUTPUT_RATE=00:00:01.00"
$         write OutFile "$ SET RMS/EXTEND_QUANTITY=10000"
$         write OutFile "$ ACS :== ""$CAM1:[ACT_MGR]ACT_CONNECTION_SERVER.EXE"""
$         write OutFile "$ ACS ''proc_port'"
$     close OutFile
$     ! Launch This Process
$     run -
      /detach -
      /authorize -
      /proc='proc_name' -
      /priority=4 -
      /input='cscom_name -
      /output='cscom_log -
      sys$system:loginout

[Volker Halle]

Craig,

using SET RMS/EXTEND=10000 does not work in this context, as it's getting set too late. A new detached process is getting created and opens the LOG file as it's SYS$OUTPUT. When the login procedure executes SET RMS/EXT=10000, the LOG file has already been created.

You may try using SET RMS/EXTEND=10000/SYSTEM before creating the detached process and then reset it to the default value again with SET RMS/EXTEND=0/SYSTEM again.

Volker.

[Craigers01]

Thanks for your amazing help. Sorry this keeps draging on. Making that setting at the system level helped one of my log files; the log files for my TCP server. That process, however, creates numerous subprocesses. They, in turn, are not getting my extent setting. We are very close though. Can I make an RMS_DEFAULT setting change from C code? Is there a Run Time Library or something?

p.s. There as so many places to mark this thread as the correct solution. If I pick one now, we can still post here, right?

Thanks!

Craig

[Volker Halle]

Craig,

if your log files are all created indirectly by LOGINOUT, there is no way to control their extend size other than by the system- or volume-wide RMS_DEFAULT parameters. If your application manually creates LOG files, you could probably specify a default file extension size during the Open/Create call.

File fragmentation by itself may not be a problem, except if

- it causes file extension headers filling up your INDEXF.SYS (as you've experienced)

- it causes IO performance problem (MONITOR FCP -> Window Turns), if those files are read frequently. BACKUP will run much slower, if it has to process many and heavily fragmented files

Look at the file headers and retrieval pointers of some of your bigger log files. Consider to set a meaningful extent size on this disk at MOUNT time. Use a multiple of the cluster size (=9 on this disk), maybe 90 or 900 . Your average file size on this disk is about 58 blocks - before the cleanup. And run DEEFRAG REPORT from time to time so see, how the fragmentation develops over time.

Volker.

PS: we can continue this discussion endlessly, even if you've marked an answer as a solution.

[Steven Schweda]

> [...] Can I make an RMS_DEFAULT setting change from C code? [...]

   If you're opening a file in your program:

      help crtl creat arguments

and/or (for parameter values not known at compile time):

   There's code in the Info-ZIP programs (both Zip 3.x and UnZip 6.x) to
do things.  Get one of the source kits, and look for "acc_cb" in the
VMS-specific code ([.vms]vms.c, et al.)  It uses an access callback
routine to do the serious work, and can sense the user-specified values
from (DCL) SET RMS_DEFAULT using GETJPI.

   I wasn't worried about fragmentation, but increasing the "Default
extension quantity" made a big difference in the speed when writing
large files.

[Volker Halle · Accepted solution]

Craig,

if your VMS system is an emulated one, you have a nice option to defragment your disk using BACKUP/IMAGE/NOINIT - without involving your SAN people

- create a local .vdisk file with the same size as your DSA214: disk

- configure this disk into your emulator with the SAME geometry (cyl/sect/tps) as dkcnn:

- add the newly configured disk into the DSA214: shadowset and let shadow-copy do it's work

- once shadow-copy is finished, you have a block-by-block identical copy of your DSA214: on a emulator-local disk

- Dismount DSA214:

- INIT previous DSA214: mbr on the SAN with the same attributes as DSA214:, but add /HEADERS=418901

- MOUNT/FOR newly inited disk (on the SAN)

- BACKUP/IMAGE/NOINIT dkcnn:   SAN-member-of-DSA214:

- re-mount DSA214: with the SAN-member (then add 2nd member, if there was one before)

Note: you still have the old copy of the disk as dkcnn: locally - if anything goes wrong !

Using this technique, you can completely defrag your DSA214: disk and make INDEXF.SYS big enough for the next century

Volker.

[Craigers01]

I have implemeted the approach in which I set the extend quantity at the system level from 99 to 999, in my process startup script. This causes all of the main server process log files (largest log files) to have the larger extents. The TCP server instanceates sub processes, using the LOGINOUT.EXE, so there's no easy way to manage those log files.

I think this addresses the low hanging fruit. I have some code prepped on the remote side of things that can disconnect/reconnect the TCP connection occasionally, freeing up the sub process log files. I'm not sure if I will need/choose to implement that code.

Thanks so much for your support!

Craig

[Craigers01]

As just a final review, does the disk look healthy now, given these results?

DUMP/BLOCK=(START=4250313, COUNT=1)  DSA214:

Dump of device DSA214: on 16-MAR-2023 16:38:45.71

Logical block number 4250313 (0040DAC9), 512 (0200) bytes

 00000000 00010001 02010000 FFFF6428 (d.............. 000000
 0DCF0003 0DCE0003 02000001 00000000 ..........Î...Ï. 000010
 00000000 00000000 00000200 00000000 ................ 000020
 00090003 009BFE00 00000020 00000000 .... .......... 000030
 00030DCF 00000000 00000004 0004FA00 .ú..........Ï... 000040
 20202020 313B5359 532E4658 45444E49 INDEXF.SYS;1     000050
 61A00096 B4F0E98D 4A201266 20202020     f. J.é...a 000060
 5FA00000 00000000 000000B8 2D8427E9 é'.-.........._ 000070
 20202020 20202020 202000B8 3094E042 Bà.0.           000080
 20202020 20202020 20202020 20202020                  000090
 20202020 20202020 20202020 20202020                  0000A0
 20202020 20202020 20202020 20202020                  0000B0
 04024008 00004011 20202020 20202020         .@...@.. 0000C0
 97F9003F EC49EE7F C0000040 DAC98008 ..ÉÚ@..À.îIì?.ù. 0000D0
 006C4728 97960074 91C0A30C 00755DA8 ¤]u..£À.t...(Gl. 0000E0
 3DB892BC 00694317 93D30069 C52B94A2 ¢.+Åi.Ó..Ci.¼.= 0000F0
 903D006A C3479139 006BBFE9 91930073 s...é¿k.9.GÃj.=. 000100
 0070625D 8CB00079 FF5F8D52 007B5CEE î\{.R._.y.°.]bp. 000110
 ED678B7E 0066B66A 8C05006E 20268C7A z.& n...j¶f.~.gí 000120
 8A5E0005 68BC8A9D 0062C457 8AA6007D }..WÄb...¼h..^. 000130
 007D1732 8A16003F B9108A4C 005FC58C .Å_.L..¹?...2.}. 000140
 0B89896B 007CCBDB 897D006F 33B489FB û.3o.}.ÛË|.k... 000150
 89080070 B6758959 00795FA8 896B0071 q.k.¤_y.Y.u¶p... 000160
 005F8B66 88AE005C DFAE88C0 007A70FF .pz.À.ß\..f._. 000170
 83988893 006836F4 88A5007B 133588AE .5.{.¥.ô6h..... 000180
 8830005D 4DEE886F 006B2C89 88930071 q....,k.o.îM].0. 000190
 00665052 87FA0063 1C7A8803 000616B0 °.....z.c.ú.RPf. 0001A0
 45A387B2 00673F1A 87CD003F 27CC87CD Í.Ì'?.Í..?g.².£E 0001B0
 874F005D 25658785 0006B856 878E006B k...V....e%].O. 0001C0
 0069B57D 87190078 3ED0872B 0062E8F9 ùèb.+.>x...}µi. 0001D0
 3D1886FE 0043632C 87460004 555B8707 ..[U..F.,cC...= 0001E0
 FB4D002D 47C186D1 007195AA 86E3006B k.ã.ª.q.Ñ.ÁG-.Mû 0001F0

DUMP/FILE/BLOCK=(START=4250313, COUNT=1)  DSA214:
Dump of device DSA214: on 16-MAR-2023 16:39:34.48

Logical block number 4250313 (0040DAC9), 512 (0200) bytes

Header area
    Identification area offset:           40
    Map area offset:                      100
    Access control area offset:           255
    Reserved area offset:                 255
    Extension segment number:             0
    Structure level and version:          2, 1
    File identification:                  (1,1,0)
    Extension file identification:        (0,0,0)
    VAX-11 RMS attributes
        Record type:                      Fixed
        File organization:                Sequential
        Record attributes:                <none specified>
        Record size:                      512
        Highest block:                    200142
        End of file block:                200143
        End of file byte:                 0
        Bucket size:                      0
        Fixed control area size:          0
        Maximum record size:              512
        Default extension size:           0
        Global buffer count:              0
        Directory version limit:          0
    File characteristics:                 Contiguous best try
    Map area words in use:                155
    Access mode:                          0
    File owner UIC:                       [11,3]
    File protection:                      S:RWED, O:RWED, G:RE, W:
    Back link file identification:        (4,4,0)
    Journal control flags:                <none specified>
    Active recovery units:                None
    Highest block written:                200142

Identification area
    File name:                            INDEXF.SYS;1                          
    Revision number:                      4710
    Creation date:                        20-APR-1993 10:42:11.01
    Revision date:                        26-FEB-2023 16:02:14.33
    Expiration date:                      <none specified>
    Backup date:                           2-MAR-2023 13:39:29.05

Map area
    Retrieval pointers
        Count:         18        LBN:          0
        Count:          9        LBN:       1026
        Count:          9        LBN:    4250313
        Count:      61056        LBN:    4189257
        Count:       6138        LBN:    7691688
        Count:       8973        LBN:    7639488
        Count:       6039        LBN:    7096104
        Count:       5283        LBN:    6931755
        Count:       5076        LBN:    6898455
        Count:       4797        LBN:    7552440
        Count:       4500        LBN:    7061481
        Count:       4410        LBN:    6996807
        Count:       4158        LBN:    8084718
        Count:       3411        LBN:    7995231
        Count:       3249        LBN:    7365213
        Count:       3195        LBN:    7217190
        Count:       3078        LBN:    6731370
        Count:       2943        LBN:    8252775
        Count:       2727        LBN:    6472791
        Count:       2718        LBN:     354492
        Count:       2655        LBN:    6276492
        Count:       2637        LBN:    4176144
        Count:       2583        LBN:    8197938
        Count:       2556        LBN:    7287732
        Count:       2430        LBN:    8178651
        Count:       2412        LBN:    7408521
        Count:       2412        LBN:    7954344
        Count:       2394        LBN:    7386741
        Count:       2313        LBN:    8024319
        Count:       2241        LBN:    6086574
        Count:       2223        LBN:    6261606
        Count:       2223        LBN:    8065845
        Count:       2214        LBN:    6829812
        Count:       2196        LBN:    7439256
        Count:       2196        LBN:    7023753
        Count:       2160        LBN:    6114798
        Count:       2097        LBN:     399024
        Count:       2052        LBN:    6495354
        Count:       2043        LBN:    6705234
        Count:       1998        LBN:    4138956
        Count:       1998        LBN:    6766362
        Count:       1971        LBN:    7030179
        Count:       1935        LBN:     440406
        Count:       1926        LBN:    6104421
        Count:       1872        LBN:    6482169
        Count:       1836        LBN:    7880400
        Count:       1818        LBN:    6927741
        Count:       1800        LBN:     283995
        Count:       1863        LBN:    4416300
        Count:       1791        LBN:    7027992
        Count:       1764        LBN:    7443882
        Count:       1746        LBN:    2967489

Checksum:                                 64333

[Volker Halle]

Craig,

what do you expect ? The INDEXF.SYS file header usage has not changed: same no. of retrieval pointers, which use up all the space in the INDEXF.SYS header.

You can only solve this by BACKUP/IMAGE[/NOINIT] of this disk - as described above.

But if you now have reduced the fragmentation of your disk, which prevents lots of file extension headers filling up the file header space in INDEXF.SYS, you should be all set for the next couple of years.

Just run DEFRAG REPORT from time to time and PURGE the LOG files and DEFRAG the disk, if the fragmentation index indicates so.

You could also 'count' the bits set in the Index File Bitmap, which indicate, which file header block in INDEXF.SYS is 'in use'. This would give an absolute representation of 'free file headers' on this disk. Read chapter 2.5.1.6 Index File Bitmap in the VMS File System Internals book (pointer provided above).

Volker.