Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Modem line data transfer failing 1

Status
Not open for further replies.

1148tr

MIS
Mar 15, 2007
53
US
We have tried both PBX extensions (Avaya S8720s) and POTS lines but are having problems with data transfers from our AS/400 and retail server modems dialing out to other locations not completing/failing. Switching from PBX to POTS or the other way sometimes seems to help a bit (or coincidence) but does not resolve the issues and the transfers will fail and quite often. The data guys swear it is a line problem and not a hardware problem. The modem off the AS/400 has been replaced. Should we try conditioned POTS lines or have conditioning testing done on the POTS line, but that does not explain the problem when on the PBX extensions. Any suggestions or suggestions on how to prove whether or not it is a line problem? Thanks.
 
I ran into an issue fairly recently where a fax machine couldn't connect. It involved an S8300 with a PRI, analog ports (for the fax) and DID. Turns out that there was a very weird software bug that had to do with PRI syncronization that prevented any analog fax or modem traveling through that PRI from connecting properly. Avaya ultimately resolved the issue.

That being said, I still wouldn't want to jump to the conclusion that we have an issue with the S8720.

What is the history here? Was your current setup working just fine, and then suddenly went awry? Or has something changed or been moved recently?

Also, you mention that the AS/400 dials out to "retail server modems". What are the modems at the retail end talking to...a terminal controller? One thing about AS/400 serial connections is that they are synchronous, rather than asynchronous.

Synchronous data connections send entire blocks of data along with timing signals, which is used to synchronize both ends. What that means in English is that it is somewhat harder to establish and maintain such a modem connection (at least compared to asynchronous connections). Soooo, a marginal voice line might allow both modems to handshake / negotiate fine, but still pass contaminated data. It's also possible that one of the DTE devices are giving up prematurely because data throughput is too slow (also possibly due to dirty lines).

Lastly, there's a possibility that someone changed the modem setup string on the AS/400 side. Also, some modems are front-panel configurable, which means that a curious IT guy could be to blame too.

Hopefully some of my post will make sense, or at least inspire you to look at a couple of areas that you haven't yet explored. Post back and I'll help any way I can.

Tim Alberstein
 
One thing that might help is low pass filters on both ends of analog lines. They have done wonders for some and completely worthless on others. But it will cost $20 to see.

Ed Fair
Give the wrong symptoms, get the wrong solutions.
 
Thanks for the replies. The history is that we moved recently but have always had some problems with these connections even prior to the move but now the issue seems to be more often and too often and it does not matter whether we use POTS or PBX extensions. We have tried different lines. We have gone over the modem config. The lines seem to be clean using a butt set. The retail modems are a seperate issue. There we have 16 lines that come into what they refer to as a digi box that accepts the analog lines to interface with the retail server but they seem to fail often as well and again it doesn't seem to matter whether they are POTS or PBX. We only seem to have analog modem issues and everything else seems to be fine including faxes. We will try another port off the AS/400 to see if that helps but probably not. Are there other ways to test the lines? We have tried just using them to dial-out with a laptop and that seems to work fine and the lines sounds clean with a butt set. Thanks again. Tom
 
It could be that the dialing string is corrupt.

If you have a butt set with an amplifier, connect it across one of the incoming lines and monitor a dial out session to listen to the dialing.

We had a fax machine giving us fits, dials out fine sometimes, and won't work other times. I listed in with the but set and heard the fax go off hook and start to dial, but then when it went into the synchronization train, it locked up. Turns out it was a bad modem board on the fax.

The point being, that if the dial out string is corrupt, it may not be dialing correctly. Perhaps it is trying to dial before it gets good dial tone. Perhaps it is dialing a bad number.
Another helpful tool would be a DTMF decoder test set. When placed across the line it would display the digits as they are dialed.
 
I'd love to know what brand and model number of the modems it is that you're using.

I believe that this is much more likely a modem problem than it is a line problem.

More detail about the Digi boxes...please! Digi.com makes a RAS box, and I wonder if that what you're using as some kind of device server.

All this analog stuff is old and painful for the new talent, but I'm sure I can help you if I have enough info.

Tim Alberstein
 
Thanks for the continued advice. The modem is a Motorola 3260. I have been busy with other things and have not gotten back to this issue the last few days but I will have to do my best to figure this out Monday since it is becoming critical. I will get more info on the digi boxes and let you know ASAP.
Thanks again, Tom.
 
Thanks for the continued advice. The modem is a Motorola 3260. I have been busy with other things and have not had a chance to work on this for the last few days but I will need to get this resolved within the next few work days as it is becoming critical. I will get some more info on the digi boxes ASAP.
Thanks again, Tom.
 
I'm rather familiar with the Motorola 3260.

If you have a manual, load up option set #3 into RAM and save the config. If you don't have a manual, check out
One question: On the front cover of the modem, is there anything with the letters SDC (synchronous data compression) or 3260 FAST (proprietary compression technique, prior to the V.32 standard)?

Email me if you'd prefer.

Tim Alberstein
 
We tried changing the modem to option set #3 and the modem hung twice when the job ran so we went back to option set #1. We found out today that there are two pieces of the job, a transmit and receive session. It dials out to transmit the job to an outside company, disconnects then dials again 10 minutes later to receive the data back. The failure almost always seems to be on when it dials out to receive the data back. The transmit and receive jobs have the same amount of records. At this point in time we have the line connected through our PBX. Thanks.
 
Interesting. Option set #1 is for async...what I might use on my PC for a Slip/PPP connection to the Internet or to a Magix diagnostic modem. That's counter to what I originally imagined that your application was all about.

I see that you've sent me a personal email. We'll correspond that way for a bit, then post the results here when this problem is solved.

Tim Alberstein
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top