Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
FAXSR
50 views
Skip to first unread message
Dave
Jan 25, 2012, 12:00:14 PM1/25/12
to
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 anal/sys or anal/disk)??
Anyway thanks in advance for any suggestions
by the way, the system is Alpha DS10 running OpenVMS 8.3.
Dave
The current owner of the product is OMTOOL, however they stopped
supporting it way back.
(their primary response is "send us your autograph on a check-shaped
piece of paper, and we will come around and attempt to migrate you to
our new Windowz-based product Genifax."
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 anal/sys or anal/disk)??
Anyway thanks in advance for any suggestions
by the way, the system is Alpha DS10 running OpenVMS 8.3.
Dave
The current owner of the product is OMTOOL, however they stopped
supporting it way back.
(their primary response is "send us your autograph on a check-shaped
piece of paper, and we will come around and attempt to migrate you to
our new Windowz-based product Genifax."
glen herrmannsfeldt
Jan 25, 2012, 12:24:50 PM1/25/12
to
Dave <Bax...@tessco.com> wrote:
> 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
I don't know if VMS has this problem, but it used to be (and
> 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
probably still is) on Windows:
Programs do 32 bit arithmetic computing the available disk space
(or RAM space), and, when it wraps to a negative value decide
that there isn't enough space. That might be especially true
for older programs, before 4GB disks were common.
It might be writing a temporary disk file to wherever they go,
(possibly from an environment variable), so you might check
that out, too.
-- glen
abrsvc
Jan 25, 2012, 12:25:15 PM1/25/12
to
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
Jan-Erik Soderholm
Jan 25, 2012, 3:32:54 PM1/25/12
to
Dave wrote 2012-01-25 18:00:
> 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 anal/sys or anal/disk)??
Yes, get DFU and run a REPORT on your disks. Gives you the
> 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 anal/sys or anal/disk)??
current fragmentation statistics (both used and unused space).
$ mc dfu report dsa100
Disk and File Utilities for OpenVMS V3.2
%DFU-I-REPORT, Reporting on DSA100: (DSA100:)
...
... Snipped info about used disk space...
...
***** Free space statistics (from BITMAP.SYS) *****
Total blocks on disk : 142264000
Total free blocks : 109475467
Percentage free (rounded) : 76
Total free extents : 6618
Largest free extent (blocks) : 57386971 at LBN: 13745073
Average extent size (blocks) : 16542
Free space fragmentation index : 0.006 (excellent)
%DFU-I-READY, REPORT command ready
$
http://www.digiater.nl/dfu.html
Christoph Gartmann
Jan 26, 2012, 2:22:19 AM1/26/12
to
In article <257e1c1a-0b09-41e7...@e3g2000vba.googlegroups.com>, Dave <Bax...@tessco.com> writes:
>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
[...]
>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
Not that I know anything about FAXSR, but did you check diskquotas?
Regards,
Christoph Gartmann
--
Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -80464
Immunbiologie und Epigenetik
Postfach 1169 Internet: gartmann@immunbio dot mpg dot de
D-79011 Freiburg, Germany
http://www.immunbio.mpg.de/home/menue.html
Dave
Jan 26, 2012, 9:41:31 AM1/26/12
to
On Jan 26, 2:22 am, gartm...@nonsense.immunbio.mpg.de (Christoph
Gartmann) wrote:
> In article <257e1c1a-0b09-41e7-b52c-df5925c83...@e3g2000vba.googlegroups.com>, Dave <Baxt...@tessco.com> writes:>I appreciate that this is probably a pointless exercise since there
Thanks for your replies guys. (looks like me and Dan might be the
last couple of hold-outs)
For Christoph: We dont have disk quotas enabled on these systems.
General: We dont have any fragmentation reporting software
installed however a DUMP of the INDEXF file indicated that the system
disk only had a small number of fragments (~4-5 as I recall).
I will try doing an image restore on the system disk this weekend, and
see if that improves the situation.
Thanks
Dave.
Gartmann) wrote:
> In article <257e1c1a-0b09-41e7-b52c-df5925c83...@e3g2000vba.googlegroups.com>, Dave <Baxt...@tessco.com> writes:>I appreciate that this is probably a pointless exercise since there
last couple of hold-outs)
For Christoph: We dont have disk quotas enabled on these systems.
General: We dont have any fragmentation reporting software
installed however a DUMP of the INDEXF file indicated that the system
disk only had a small number of fragments (~4-5 as I recall).
I will try doing an image restore on the system disk this weekend, and
see if that improves the situation.
Thanks
Dave.
Jan-Erik Soderholm
Jan 26, 2012, 10:20:49 AM1/26/12
to
Dave wrote 2012-01-26 15:41:
> On Jan 26, 2:22 am, gartm...@nonsense.immunbio.mpg.de (Christoph
> Gartmann) wrote:
>> In article<257e1c1a-0b09-41e7-b52c-df5925c83...@e3g2000vba.googlegroups.com>, Dave<Baxt...@tessco.com> writes:>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
>>
>> [...]
>>
>> Not that I know anything about FAXSR, but did you check diskquotas?
>>
>> Regards,
>> Christoph Gartmann
>>
>> --
>> Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -80464
>> Immunbiologie und Epigenetik
>> Postfach 1169 Internet: gartmann@immunbio dot mpg dot de
>> D-79011 Freiburg, Germany
>> http://www.immunbio.mpg.de/home/menue.html
>
> Thanks for your replies guys. (looks like me and Dan might be the
> last couple of hold-outs)
>
> For Christoph: We dont have disk quotas enabled on these systems.
>
> General: We dont have any fragmentation reporting software
> installed however a DUMP of the INDEXF file indicated...
> On Jan 26, 2:22 am, gartm...@nonsense.immunbio.mpg.de (Christoph
> Gartmann) wrote:
>> In article<257e1c1a-0b09-41e7-b52c-df5925c83...@e3g2000vba.googlegroups.com>, Dave<Baxt...@tessco.com> writes:>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
>>
>> [...]
>>
>> Not that I know anything about FAXSR, but did you check diskquotas?
>>
>> Regards,
>> Christoph Gartmann
>>
>> --
>> Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -80464
>> Immunbiologie und Epigenetik
>> Postfach 1169 Internet: gartmann@immunbio dot mpg dot de
>> D-79011 Freiburg, Germany
>> http://www.immunbio.mpg.de/home/menue.html
>
> Thanks for your replies guys. (looks like me and Dan might be the
> last couple of hold-outs)
>
> For Christoph: We dont have disk quotas enabled on these systems.
>
> General: We dont have any fragmentation reporting software
The actual command used would make it easier to follow what you
did and what it might be that you are seeing. Does a DUMP of
the index file show the fragmentation of free space ?
What I know that a DUMP of the index files shows, is the
fragmentation of the index file itself.
Jan-Erik.
Jeffrey H. Coffield
Jan 26, 2012, 9:59:04 AM1/26/12
to
On 01/25/2012 09:00 AM, Dave wrote:
>
> The current owner of the product is OMTOOL, however they stopped
> supporting it way back.
> (their primary response is "send us your autograph on a check-shaped
> piece of paper, and we will come around and attempt to migrate you to
> our new Windowz-based product Genifax."
Jeff Coffield
www.digitalsynergyinc.com
Dave
Feb 7, 2012, 9:11:43 AM2/7/12
to
On Jan 26, 9:59 am, "Jeffrey H. Coffield"
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.
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.
GerMarsh
Dec 4, 2012, 10:42:55 AM12/4/12
to
The problem is due to some internal limit coded into FAXsr. Once the free blocks on the disk goes to the max level supported by V5.5-2(!), the program thinks it's out of space. It was not the only systems program affected by this. The free blocks should be kept above 16,777,215.
0 new messages