Discussion:
VMS faxing
(too old to reply)
Rich Jordan
2021-08-13 21:22:35 UTC
Permalink
Looking back into the dark past of facsmile transmission. Hoping someone here remembers some details.

OpenVMS IA64 HPE V8.4 running NDC Compufax. We have been working with NDC. The site has four faxmodems (Multitech ZDX series) that were running off of a DECserver 200 (now deceased). We dropped in a DECserver 700-08 running the pre-DNAS V1.5 firmware using identical port settings, and while it works we're getting complaints about quality issues on the receiving end; we've confirmed this is a send-side issue, not line or recipient. Currently testing to a real fax machine at the site but the hashing and lines we get there perfectly match what some customers scanned and emailed back to us.

If so this is the first time we've had a situation where a DS700-08 brought in problems when replacing a DS200-MC

NDC had us try a delay logical that introduces a small delay between sending lines (value between 1 and 'unknown' but we tested a range between 1 and 200). We see minor changes in the output but quality issues remain the same. If you send the same textfile several times with the same delay factor (or none) the output is identical; same hashing and streaking on the page except for one (so far) delay value that was cleaner but dropped entire scanlines. NDC has notes that this delay option was put in for DECserver 700s.

We can put DNAS on this DECserver instead of the older firmware; it is a non flash model but with 4MB RAM. We may be able to sub a DS90M also but would have to fabricate cables.

Anyone recall if there's tweaks we could make on the DECserver itself, old or DNAS firmware, to change its flow control response speed (sort of like DELAY_ACK on the TCPIP front)? Or perhaps recall having issues like this before? I really don't want to try to find a working DS200 MC.

Thanks.

Yes, alternatives like using a mail-out fax service may be considered but for now we need this working properly again.
gah4
2021-08-14 08:30:53 UTC
Permalink
Some years ago, I thought about how to make a fax send system, but never did it.

As well as I remember, getting the handshaking right on the serial port was the important part.

If you get it wrong, you overrun the buffer.

But the other possibility is that you aren't getting the data out fast enough,
and underrun the buffer. Increasing the delay between lines would help.

Otherwise, a higher serial port baud rate might help.

Lowering the baud rate on the fax side might help, too.

In faxing through VoIP lines, even with 711u encoding, it is best
at lower baud rates.
Grant Taylor
2021-08-14 22:57:18 UTC
Permalink
In faxing through VoIP lines, even with 711u encoding, it is best at
lower baud rates.
I've always tried to avoid faxing (and data modem) over VoIP. I've read
about T.37 and T.38, but have never used them. I would try to do T.38
if at all possible if I /needed/ to send fax via VoIP channels. Keep it
in the data domain and avoid time sensitive (pseudo) analog as much as
possible.
--
Grant. . . .
unix || die
Rich Jordan
2021-08-15 16:54:31 UTC
Permalink
In faxing through VoIP lines, even with 711u encoding, it is best at
lower baud rates.
I've always tried to avoid faxing (and data modem) over VoIP. I've read
about T.37 and T.38, but have never used them. I would try to do T.38
if at all possible if I /needed/ to send fax via VoIP channels. Keep it
in the data domain and avoid time sensitive (pseudo) analog as much as
possible.
--
Grant. . . .
unix || die
Grant,
thanks, we do have a query in to determine what the actual phone lines are using. However since the problem started with the entrance of the DS700 after the DS200 died I doubt it is a VOIP or line issue.
gah4
2021-08-15 17:04:13 UTC
Permalink
On Sunday, August 15, 2021 at 9:54:32 AM UTC-7, Rich Jordan wrote:

(snip)
Post by Rich Jordan
thanks, we do have a query in to determine what the actual phone lines are using.
However since the problem started with the entrance of the DS700 after the DS200 died I doubt it is a VOIP or line issue.
There are two things to get right. The baud rate from the DS700 to the fax modem,
and the baud rate of the fax transmission itself.

The serial port baud rate should be enough faster, and there should be flow control
(handshaking) between the DS700 and the modem.
Rich Jordan
2021-08-15 16:52:33 UTC
Permalink
Post by gah4
Some years ago, I thought about how to make a fax send system, but never did it.
As well as I remember, getting the handshaking right on the serial port was the important part.
If you get it wrong, you overrun the buffer.
But the other possibility is that you aren't getting the data out fast enough,
and underrun the buffer. Increasing the delay between lines would help.
Otherwise, a higher serial port baud rate might help.
Lowering the baud rate on the fax side might help, too.
In faxing through VoIP lines, even with 711u encoding, it is best
at lower baud rates.
We are going to try lower baud rates before trying faster, if at all. The DS200 topped out at 19200, the DS700 can go a lot faster.

We have queries out to their phone vendor to determine what the phone lines in use actually are; their paper docs said they were POTS lines but they were 11 years old, so maybe its been changed in the background.
Scott Dorsey
2021-08-16 00:45:27 UTC
Permalink
I don't know, but I'll check your old DECServer out. If it's the usual
power supply problem, it'll be about $150 to rebuild the supply.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Rich Jordan
2021-08-16 14:26:45 UTC
Permalink
I don't know, but I'll check your old DECServer out. If it's the usual
power supply problem, it'll be about $150 to rebuild the supply.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Scott,
I doubt that is the problem. We replaced the power supply about a year ago and I still have another spare from a 16 port unit that got recycled. There is no indication of fault on the DS700 and it was tested before installing there.

I can't see a power supply issue causing comm issues that exactly duplicate the same flaws/hashing/lines on a given fax no matter what machine it is sent to. Or that change to plain old dropped scan lines with two specific inter-line delay settings in the fax software (the faxes come out clean, with some lines vertically compressed because entire scan lines are missing); it really has to be something on the communication side.

Thanks for the offer.

Rich
Jan-Erik Söderholm
2021-08-16 14:32:55 UTC
Permalink
Post by Rich Jordan
I don't know, but I'll check your old DECServer out. If it's the usual
power supply problem, it'll be about $150 to rebuild the supply.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Scott,
I doubt that is the problem. We replaced the power supply about a year ago and I still have another spare from a 16 port unit that got recycled. There is no indication of fault on the DS700 and it was tested before installing there.
I can't see a power supply issue causing comm issues that exactly duplicate the same flaws/hashing/lines on a given fax no matter what machine it is sent to. Or that change to plain old dropped scan lines with two specific inter-line delay settings in the fax software (the faxes come out clean, with some lines vertically compressed because entire scan lines are missing); it really has to be something on the communication side.
Thanks for the offer.
Rich
I think that Scott was refering to the *old* DS200, not the DS700...
Scott Dorsey
2021-08-16 22:03:26 UTC
Permalink
I don't know, but I'll check your old DECServer out. If it's the usual=20
power supply problem, it'll be about $150 to rebuild the supply.=20
I doubt that is the problem. We replaced the power supply about a yea=
r ago and I still have another spare from a 16 port unit that got recycled.=
There is no indication of fault on the DS700 and it was tested before ins=
talling there.
No, no, I am offering to fix the DS200, so that you can go back to the
original configuration. The old decserver, not the new one.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Rich Jordan
2021-08-17 14:13:00 UTC
Permalink
Post by Scott Dorsey
I don't know, but I'll check your old DECServer out. If it's the usual=20
power supply problem, it'll be about $150 to rebuild the supply.=20
I doubt that is the problem. We replaced the power supply about a yea=
r ago and I still have another spare from a 16 port unit that got recycled.=
There is no indication of fault on the DS700 and it was tested before ins=
talling there.
No, no, I am offering to fix the DS200, so that you can go back to the
original configuration. The old decserver, not the new one.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Sorry for misreading. I'll let you know, but right now the customer is considering getting DS200s again so its possible.

We tried setting everything to 9600 baud, and that eliminated the hashing but not the scan line drops; the output looked about the same as when running at 19200 with the fax$send_delay logical set to 5 or 6 (every other value generates the hash). Problem was that every job 'failed' even though it generated a fax. So with retry set to 2 it would send three copies of the fax then generate a failure report. Every time. Switched back to 19200 and that problem went away.

May still try putting DNAS software on the DS700 when its less busy. During our half our or so test window nearly 100 faxes piled up, so we're going to have to do early morning or Sunday...
gah4
2021-08-17 02:00:06 UTC
Permalink
On Monday, August 16, 2021 at 7:26:46 AM UTC-7, Rich Jordan wrote:

(snip)
Post by Rich Jordan
I can't see a power supply issue causing comm issues that exactly duplicate
the same flaws/hashing/lines on a given fax no matter what machine it is sent to.
Or that change to plain old dropped scan lines with two specific inter-line delay
settings in the fax software (the faxes come out clean, with some lines vertically
compressed because entire scan lines are missing);
it really has to be something on the communication side.
The serial port is about the only thing that uses a -12V power supply on most
systems, so in theory a problem on that could cause mysterious serial port problems.

I do agree that it isn't likely in this case, though.
V***@SendSpamHere.ORG
2021-08-14 12:20:43 UTC
Permalink
Looking back into the dark past of facsmile transmission. Hoping someone h=
ere remembers some details.
OpenVMS IA64 HPE V8.4 running NDC Compufax. We have been working with NDC.=
The site has four faxmodems (Multitech ZDX series) that were running off =
of a DECserver 200 (now deceased). We dropped in a DECserver 700-08 runnin=
g the pre-DNAS V1.5 firmware using identical port settings, and while it wo=
rks we're getting complaints about quality issues on the receiving end; we'=
ve confirmed this is a send-side issue, not line or recipient. Currently t=
esting to a real fax machine at the site but the hashing and lines we get t=
here perfectly match what some customers scanned and emailed back to us.
If so this is the first time we've had a situation where a DS700-08 brought=
in problems when replacing a DS200-MC
NDC had us try a delay logical that introduces a small delay between sendin=
g lines (value between 1 and 'unknown' but we tested a range between 1 and =
200). We see minor changes in the output but quality issues remain the sam=
e. If you send the same textfile several times with the same delay factor =
(or none) the output is identical; same hashing and streaking on the page e=
xcept for one (so far) delay value that was cleaner but dropped entire scan=
lines. NDC has notes that this delay option was put in for DECserver 700s.
We can put DNAS on this DECserver instead of the older firmware; it is a no=
n flash model but with 4MB RAM. We may be able to sub a DS90M also but wou=
ld have to fabricate cables.
Anyone recall if there's tweaks we could make on the DECserver itself, old =
or DNAS firmware, to change its flow control response speed (sort of like D=
ELAY_ACK on the TCPIP front)? Or perhaps recall having issues like this be=
fore? I really don't want to try to find a working DS200 MC. =20
Thanks.
Yes, alternatives like using a mail-out fax service may be considered but f=
or now we need this working properly again.
Rich, what is the port configuration for these modems?

This is what I have configured for a FAXmodem on a DS90M.

Port 1: Server: DS90M1

Character Size: 8 Input Speed: 2400
Flow Control: XON Output Speed: 2400
Parity: None Signal Control: Disabled
Stop Bits: Dynamic

Access: Remote Local Switch: None
Backwards Switch: None Name: PORT_1
Break: Disabled Session Limit: 4
Forwards Switch: None Type: Ansi
Default Protocol: LAT Default Menu: None
Autolink Timer One:10 Two:10 Dialer Script: None

Preferred Service: None
Authorized Groups: 0
(Current) Groups: 0

Enabled Characteristics:
Input Flow Control, Output Flow Control
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Rich Jordan
2021-08-15 16:50:10 UTC
Permalink
Post by V***@SendSpamHere.ORG
Looking back into the dark past of facsmile transmission. Hoping someone h=
ere remembers some details.
OpenVMS IA64 HPE V8.4 running NDC Compufax. We have been working with NDC.=
The site has four faxmodems (Multitech ZDX series) that were running off =
of a DECserver 200 (now deceased). We dropped in a DECserver 700-08 runnin=
g the pre-DNAS V1.5 firmware using identical port settings, and while it wo=
rks we're getting complaints about quality issues on the receiving end; we'=
ve confirmed this is a send-side issue, not line or recipient. Currently t=
esting to a real fax machine at the site but the hashing and lines we get t=
here perfectly match what some customers scanned and emailed back to us.
If so this is the first time we've had a situation where a DS700-08 brought=
in problems when replacing a DS200-MC
NDC had us try a delay logical that introduces a small delay between sendin=
g lines (value between 1 and 'unknown' but we tested a range between 1 and =
200). We see minor changes in the output but quality issues remain the sam=
e. If you send the same textfile several times with the same delay factor =
(or none) the output is identical; same hashing and streaking on the page e=
xcept for one (so far) delay value that was cleaner but dropped entire scan=
lines. NDC has notes that this delay option was put in for DECserver 700s.
We can put DNAS on this DECserver instead of the older firmware; it is a no=
n flash model but with 4MB RAM. We may be able to sub a DS90M also but wou=
ld have to fabricate cables.
Anyone recall if there's tweaks we could make on the DECserver itself, old =
or DNAS firmware, to change its flow control response speed (sort of like D=
ELAY_ACK on the TCPIP front)? Or perhaps recall having issues like this be=
fore? I really don't want to try to find a working DS200 MC. =20
Thanks.
Yes, alternatives like using a mail-out fax service may be considered but f=
or now we need this working properly again.
Rich, what is the port configuration for these modems?
This is what I have configured for a FAXmodem on a DS90M.
Port 1: Server: DS90M1
Character Size: 8 Input Speed: 2400
Flow Control: XON Output Speed: 2400
Parity: None Signal Control: Disabled
Stop Bits: Dynamic
Access: Remote Local Switch: None
Backwards Switch: None Name: PORT_1
Break: Disabled Session Limit: 4
Forwards Switch: None Type: Ansi
Default Protocol: LAT Default Menu: None
Autolink Timer One:10 Two:10 Dialer Script: None
Preferred Service: None
Authorized Groups: 0
(Current) Groups: 0
Input Flow Control, Output Flow Control
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
VAXman,
the settings are straight from the defunct DS200, and were also in the Compufax documentation. THis is still the pre-DNAS firmware.

I can try disabling the other characteristics but they never mattered before, Dropping speed to 9600 is our next test but will be done Monday when there's someone there to report results because the faxes start at 5:30 AM monday and I need to be certain they are working at least somewhat.


Port 1: (Remote) Server: SERV9

Character Size: 8 Input Speed: 19200
Flow Control: XON Output Speed: 19200
Parity: None Modem Control: Disabled
Stop Bits: Dynamic

Access: Remote Local Switch: None
Backwards Switch: None Name: PORT_1
Break: Local Session Limit: 4
Forwards Switch: None Type: Soft
Default Protocol: LAT Default Menu: None

Preferred Service: None

Authorized Groups: 0
(Current) Groups: 0

Enabled Characteristics:
Autoprompt, Input Flow Control, Loss Notification, Message Codes,
Output Flow Control, Verification
abrsvc
2021-08-15 11:22:05 UTC
Permalink
Looking back into the dark past of facsmile transmission. Hoping someone here remembers some details.
OpenVMS IA64 HPE V8.4 running NDC Compufax. We have been working with NDC. The site has four faxmodems (Multitech ZDX series) that were running off of a DECserver 200 (now deceased). We dropped in a DECserver 700-08 running the pre-DNAS V1.5 firmware using identical port settings, and while it works we're getting complaints about quality issues on the receiving end; we've confirmed this is a send-side issue, not line or recipient. Currently testing to a real fax machine at the site but the hashing and lines we get there perfectly match what some customers scanned and emailed back to us.
If so this is the first time we've had a situation where a DS700-08 brought in problems when replacing a DS200-MC
NDC had us try a delay logical that introduces a small delay between sending lines (value between 1 and 'unknown' but we tested a range between 1 and 200). We see minor changes in the output but quality issues remain the same. If you send the same textfile several times with the same delay factor (or none) the output is identical; same hashing and streaking on the page except for one (so far) delay value that was cleaner but dropped entire scanlines. NDC has notes that this delay option was put in for DECserver 700s.
We can put DNAS on this DECserver instead of the older firmware; it is a non flash model but with 4MB RAM. We may be able to sub a DS90M also but would have to fabricate cables.
Anyone recall if there's tweaks we could make on the DECserver itself, old or DNAS firmware, to change its flow control response speed (sort of like DELAY_ACK on the TCPIP front)? Or perhaps recall having issues like this before? I really don't want to try to find a working DS200 MC.
Thanks.
Yes, alternatives like using a mail-out fax service may be considered but for now we need this working properly again.
Have you attempted to replace the 200s with other 200s? These are readily available (I have a couple I don't need/use) and are cheap.

Dan
Lee Gleason
2021-08-16 16:41:54 UTC
Permalink
Post by Rich Jordan
Looking back into the dark past of facsmile transmission. Hoping someone here remembers some details.
OpenVMS IA64 HPE V8.4 running NDC Compufax. We have been working with NDC. The site has four faxmodems (Multitech ZDX series) that were running off of a DECserver 200 (now deceased). We dropped in a DECserver 700-08 running the pre-DNAS V1.5 firmware using identical port settings, and while it works we're getting complaints about quality issues on the receiving end; we've confirmed this is a send-side issue, not line or recipient. Currently testing to a real fax machine at the site but the hashing and lines we get there perfectly match what some customers scanned and emailed back to us.
If so this is the first time we've had a situation where a DS700-08 brought in problems when replacing a DS200-MC
I have no idea what's causing this, but for troubleshooting it I
recommend a good ole ASCII serial line monitor stuck between the DS and
the faxmodem, to let you see what's really going on.

HP 4951 family ASCII line monitors are available for under $100 these
days, and I've used them to figure out serial comms issues in minutes
that had me scratching my head previously for weeks.

--
Lee K. Gleason N5ZMR
Control-G Consultants
***@comcast.net
Loading...