Very old product - FAXSR

[The Brit]

I appreciate that this is probably a pointless exercise since there
are few who even remember this archaic product, however...

I am running a very old product called FAXSR, and I have begun to see
a problem where the COMPOSER process terminates with a

[10:16:00.68] Disk space too low - terminating

message.      I could only find one reference to this issue in a very
old (2004) thread, which didnt really offer any solution.     I tried
to contact the author of this old thread (Gerald Marsh, (anyone know
him)) but of course he is "no longer at that address".

Is there anyone out there who has even a passing familiarity with
FAXSR, and who may be able to help me out with this issue?

As far as I can tell, none of my disks are having any disk-space
issues, and all disks are well below the MAXFILES limit.     From the
old thread, there is reason to suspect the FAXSR_HISTORY file which is
indexed and has the CBT attribute (contiguous best try).      It is
possible (some of) the disk(s) is/are quite fragmented.   is it
possible that this is the cause??     I dont have any defrag software
to analyse the disks.

Are there native DCL commands which will give me this info??    (maybe
in the **bleep**/sys or **bleep**/disk)??

Anyway thanks in advance for any suggestions

by the way, the system is Alpha DS10 running OpenVMS 8.3.

Dave

[abrsvc]

Our system has not experienced this particular message.  If you suspect a fragmentation problem, a backup/restore operation of the entire disk (/image) will resolve the fragmentation issue.  If that clears up the problem, then yes fragmentation was the problem.  I am running V7.3-2 on my machine here not 8.3  Given its age (FAXSR), I would wonder if there are underlying areas that V8.3 supports that FAXSR doesn't know about.

Can you post some specifics about the disk and the directory containing the faxes?

Thanks,
Dan

[Bill Hall]

Dave,

DCL only, count the number of retrieval pointers listed in the output of dump/header.

$pipe dump/header/block=(count:0) <filespec> | search sys$pipe count:,lbn:/match=and/noout/status

If you have DFU installed, you can get it also

$DFU search <device> /file=<filename> /frag=min=1

DFU will also defragment the file for you.

$DFU defrag /besttry <filespec>

Bill

[Hoff]

Boot the OpenVMS Alpha CD media, exit the installation menu to DCL, MOUNT the target disk(s) including your system disk, and then BACKUP /IMAGE /VERIFY your disk to an external backup device, then BACKUP /IMAGE /VERIFY restore it. 

Chances are, your disk(s) have been fragmented and you're hitting a directory file or some other contiguous construct.  Performing a save and restore will defragment your disk, and it'll leave you with a known-good full-disk copy.  If that's not the case and this isn't fragmentation and something else is wrong, you'll still have full, complete, known-good copies of your disks.

As mentioned earlier, recent versions of the OpenVMS Freeware package DFU are available, and can analyze fragmentation.  Here is the DFU web site.   (But I'd just do the BACKUP /IMAGE /VERIFY and restore to some decent external media, and be done with it.)

[The Brit]

OK.    The disk is a 36GB shadow volume with the units presented from an XP10K and and XP24K.    Details are

show dev dsa12/full

Disk DSA12:, device type Generic SCSI disk, is online, mounted, file-oriented

device, shareable, available to cluster, error logging is enabled, device

supports bitmaps (no bitmaps active).

Error count 0 Operations completed 30175

Owner process "" Owner UIC [SYSTEM]

Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W

Reference count 1 Default buffer size 512

Total blocks 75498000 Sectors per track 96

Total cylinders 8193 Tracks per cylinder 96

Logical Volume Size 75497472 Expansion Size Limit 87011328

Volume label "ND12" Relative volume number 0

Cluster size 73 Transaction count 1

Free blocks 37078233 Maximum files allowed 510118

Extend quantity 5 Mount count 4

Mount status System Cache name "_DSA102:XQPCACHE"

Extent cache size 64 Maximum blocks in extent cache 3707823

File ID cache size 64 Blocks in extent cache 0

Quota cache size 0 Maximum buffers in FCP cache 3633

I could do an image restore however this is a production system so such things have to be scheduled.

The product has been running in this environment since February 2009 without any particular issues.   The "terminating" issue started ~4 weeks ago.    The Composer can be restarted and will normally run for a couple of days before abending again.

Most of the active files, (history, Logs, etc.) are on the device above (i.e. system disk for this alpha.)

The other files (bitmaps, covers, forms - mostly static files) and the actual fax files, are on a different, but similar disk, DSA15.

For Bill,

running the suggested command (with output) gives the following;

On DSA102  (System Disk)

Count: 146 LBN: 0

Count: 73 LBN: 1022

Count: 73 LBN: 35639038

Count: 72708 LBN: 35566330

Files searched: 1 Buffered I/O count: 64

Records searched: 58 Direct I/O count: 0

Characters searched: 2406 Page faults: 26

Records matched: 4 Elapsed CPU time: 0 00:00:00.00

Lines printed: 4 Elapsed time: 0 00:00:00.08

On DSA15

Count: 146 LBN: 0

Count: 73 LBN: 1022

Count: 73 LBN: 37769178

Count: 20148 LBN: 37749030

Count: 73584 LBN: 12656448

Count: 62488 LBN: 50963782

Count: 53144 LBN: 15075011

Count: 45187 LBN: 15176481

Count: 38398 LBN: 60925508

Count: 32631 LBN: 72010266

Count: 27740 LBN: 9363564

Count: 23579 LBN: 57321717

Files searched: 1 Buffered I/O count: 84

Records searched: 70 Direct I/O count: 0

Characters searched: 2924 Page faults: 26

Records matched: 12 Elapsed CPU time: 0 00:00:00.00

Lines printed: 12 Elapsed time: 0 00:00:00.08

I dont know how to interpret this output, however.

Comment:    did you notice that my shortening of    "**bleep**/sys"  in the original post got replaced by "**bleep**/sys".

Humm.    Dave.

[The Brit]

Sorry, I just noticed that I gave the information on DSA12 instead of DSA102.

[Hoff]

Check the most-fragmented files, too, and any files related to the software package.  Those too can be severely fragmentated.

There have also been bugs in VMS around fragmentation over the years, and this server is badly down-revision.  Check the available patches, and see if there are missing UPDATE-, XQP- or RMS-related patches.

And yes, that edit is just a naughty word filter somewhere that's being analysis about your abbreviation.

[Bill Hall]

Dave,

Each "Count:" "LBN:" pair found in the header represents a retrieval pointer that consists of a "Count" of contiguous blocks that starts at "LBN".  Each pointer is a fragment.  A contiguous file would list one retrieval pointer.  So your output indicates that the INDEXF.SYS on DSA102 has 4 fragments or extents which is the minimum for INDEXF.SYS.  The INDEXF.SYS on DSA15 has 12 extents.

[Jeremy Begg]

Hi,

I recommend as a starting point you download and install DFU from digiater.nl then run

 $ MCR DFU REPORT disk:

The report will show you assorted information about the disk including a rough guide as to how fragmented it is, and also an indication of how badly the free space is fragmented.  It may well be that the largest free extent is smaller than the initial allocation size requested by the FAXSR software.  Another possibility is that the disk is too fragmented to allow a crucial directory to be extended.  ("Crucial" meaning a directory that's important to FAXSR.)

DFU has good online help, have a play with it.

Regards,

Jeremy Begg

[The Brit]

Some additional information from my investigations.

-

The basic problem was that this issue suddenly cropped up (after years of running fine) and had become a daily issue, with no hope of Vendor support, but WHY did it suddenly become a daily issue.

-

After some investigation I determined that a new "logging" process which was implimented to track down problems with TAXWARE is probably the root of the problem.        The logging process, at peak hours, is generating 10,000 - 12,000 files per hour into a directory on DSA15.    In conjunction with this, there is a Purge process which is moving any logs more than two hour old to an archive, the purge runs hourly.     To avoid the over head of physically moving the data, the purge simply renames the files to a different directory.

-

Unfortunately, DSA15 is also the location some of the FAXSR directories, containing Forms, Cover Pages, Bitmaps, etc., and most importantly, the FAXSR$FAXES directory.    This directory is almost always empty, however is is used by the FAXSR composer as a "work" directory, where the out-going FAX is "built", or composed.    Once the fax is sent, it is deleted from the FAXSR$FAXES directory.

-

Although at peak times there is are very high File-Creation and IO rates to this disk, there is no correllation between Composer terminations and Peak Work times.    The disk IO queue does not show any particular strain.

-

My suspicion regarding the Logging process is simply based on the fact that

-

Logging started on 16th Jan
First problem was on 17th Jan (twice), then the 20th (3)
Logging was stopped on 20th,  (no further issues)
Logging restarted on 24th
Problems started again.    25th (3), 26th (3), 27th (3), 28th (17), 30th, (1), 31st (1), 1st Feb (2), 2nd (2).
Logging stopped on Feb 2nd

No incidents since.

-

It seems pretty open and shut.     What I dont understand is the mechanism that could cause this kind of interference (and without access to the code, I dont expect anyone to tell me).     It does however appear that the error message "Disk space too low - terminating" is most likely a red-herring.

-

Thanks to all who contributed to the thread, and I just hope this is of use to anyone who comes up against the same issue.

-

Dave.