PA8250@UTKVM1.BITNET ("Larry Scollard ", UNT) (06/06/91)
Greetings,
We are about to embark on our first use of automated outbound calling
from a 3725 communications front-end. The application is TRACS software
(on a 3090 running MVS) sending Bisync 3780 data to a remote JES2 site.
Bisync 3780 RJE protocol is the only choice at the remote JES2 end.
My current level of understanding is that we will need a syncronous
switched network modem (RS-232C / V.24) connected to a 3725 port as well
as an Automatic Calling Unit (RS-366 / V.25) connected to a **second**
3725 port. The modem and ACU are then connected together in some manner.
This configuration would support the host (TRACS) use of the 3725 Dial
CCW (handled by the EP code in the 3725 front-end).
I have two questions for anyone who has been down this road before:
1.) Is my understanding of the 3725 requirements correct?
2.) Can someone recommend an ACU or modem and ACU pair that has worked
well in the past (and is reasonably priced)?
I am aware that with a modem that implements V.25bis this configuration
could be reduced to just one 3725 port. Neither the microcode nor the
EP in my 3725 supports V.25bis.
Thanks in advance for any information that you might be able to provide.
Since this is a topic that may not have wide interest perhaps responses
back to me directly would be more appropriate.
Thanks again,
Larry Scollard, Sr. Systems Programmer/Analyst
--------------
University of Tennessee Computing Center
Knoxville, Tennessee
USAlstowell@PYRNOVA.PYRAMID.COM (Lon Stowell) (06/07/91)
In article <9106061438.AA01868@lilac.berkeley.edu> you write: >Greetings, > >We are about to embark on our first use of automated outbound calling >from a 3725 communications front-end. The application is TRACS software >(on a 3090 running MVS) sending Bisync 3780 data to a remote JES2 site. >Bisync 3780 RJE protocol is the only choice at the remote JES2 end. Poor baby. A moment of silence is in order here..... > >My current level of understanding is that we will need a syncronous >switched network modem (RS-232C / V.24) connected to a 3725 port as well >as an Automatic Calling Unit (RS-366 / V.25) connected to a **second** >3725 port. The modem and ACU are then connected together in some manner. >This configuration would support the host (TRACS) use of the 3725 Dial >CCW (handled by the EP code in the 3725 front-end). > >I have two questions for anyone who has been down this road before: > >1.) Is my understanding of the 3725 requirements correct? There is an alternative IF you always call the same telco number on any given physical link. >2.) Can someone recommend an ACU or modem and ACU pair that has worked > well in the past (and is reasonably priced)? > You can buy an ACU and hook it to ANY modem that has A/A1 or M1 signalling on it's telco jack. I would recommend staying with a single vendor though. We did this at Amdahl using the Codex ACU and the Codex 2264 V.32 modem. This gives 9600 bps. Their newer V.32bis modem works as well, and offers 14,400 for list price of about $1100. If you are using switched 56, most offer optional RS-366 ACU's. One warning, RS-366 and V.25 parallel dial have a few subtle differences. We did manage to get a V.25 port to talk to the RS-366 dialler without too much trouble after we stopped getting fancy with 2 stage dialling. There are also a LOT of problems with the timing of the DSR lead and the time the V.32 modems are ready to actually xmit...these are noted below. >I am aware that with a modem that implements V.25bis this configuration >could be reduced to just one 3725 port. Neither the microcode nor the >EP in my 3725 supports V.25bis. I am almost certain that IBM Europe has V.25bis HDLC dial available.....their ISDN Terminal Adapter supports this as well as X.21. However, back to the alternative. IF and only IF you are always dialling the same number from any given link, you can use the "Direct Dial" mode of V.25bis with the '25. Any fully V.25bis compliant modem will dial a pre-stored number when you raise DTR. If you are able to try this, I would HIGHLY recommend only a V.32bis modem (the Codex still win's my vote) as their training procedures are much faster. What you will have to do is set the ENABLETO timer in NCP to a long enough value to allow the dial to complete and allow for at least TWO initial training events. I seem to remember the maximum value is 57 seconds...which is just about right. The bad news is that ENABLETO is a GLOBAL parameter for the entire NCP....and you cannot bring down NCP if there are any unexpired timers running. IMHO the NCP dwarfs overstate this...as I have yet to see 57 seconds make a bit of difference in recycling NCP or VTAM. You will also have to set the RETRY's parameters to make sure that the modem always has AT LEAST 16 seconds to perform retrains on noisy connections. This is just a combination of time-outs and retry counts which would allow the entire link to take a break for this period. Again, use a V.32bis modem....the V.32's take up to 48 seconds or more to retrain. (You may guess that the 3725 has yet to be brought up to date with MODERN smart modems like V.32's. You would be right. In implementing these suckers at Amdahl, I learned considerably more about NCP parameters and V.32 modems than I ever cared to know....) Tuning NCP for V.32's is not trivial.... I dunno if you know what the ENABLETO parameter does, so ignore if you do... When you raise DTR, the ENABLETO is how long NCP will wait for DSR before it notifys VTAM which takes the line INOP. You will either need a VTAM CLIST (barf....chews machine cycles also) or manual intervention to vary the line back up. On a switched line with switched RTS/CTS (HIGHLY recommended) as soon as DSR comes up, NCP will raise RTS and expect CTS. NCP uses the ENABLETO timer for the COMBINATION of DSR on and CTS in combination with RTS to detect the line is available. NOTE that this sequence is ONLY used by NCP for the initial raising of CTS after DSR comes on....after that the RETRIES parameters determine how long NCP will wait for a modem in-data retrain. The V.32 modem will dial the number, then as soon as it notices that the other modem is a V.32 with a compatible feature set (takes dial time + about 8 seconds) it will raise DSR. It is STILL not ready to communicate. It takes a few more seconds to equalize the line and correct for any echoes. After it has done all this and is ready to communicate, it will raise Carrier Detect...and allow CTS to respond to RTS. If you have a soldering iron, you can actuall help NCP out a little by taking the modem's Carrier Detect lead and wiring it over to the DSR lead. This will keep the NCP from seeing DSR (now CxDet) until the modem is ready to give CTS. > If I haven't turned you off on using V.32 modems, keep my e-mail address handy for when you actually try to implement this. For a small pile of unmarked bills, I should be able to save you a lot of experimentation time. >:-) Lon Stowell Staff Consultant Pyramid Technology lstowell@pyrnova.pyramid.com
lstowell@PYRNOVA.PYRAMID.COM (Lon Stowell) (06/07/91)
In article <9106061438.AA01868@lilac.berkeley.edu> you write: >Greetings, > >We are about to embark on our first use of automated outbound calling >from a 3725 communications front-end. The application is TRACS software >(on a 3090 running MVS) sending Bisync 3780 data to a remote JES2 site. >Bisync 3780 RJE protocol is the only choice at the remote JES2 end. Poor baby. A moment of silence is in order here..... > >My current level of understanding is that we will need a syncronous >switched network modem (RS-232C / V.24) connected to a 3725 port as well >as an Automatic Calling Unit (RS-366 / V.25) connected to a **second** >3725 port. The modem and ACU are then connected together in some manner. >This configuration would support the host (TRACS) use of the 3725 Dial >CCW (handled by the EP code in the 3725 front-end). > >I have two questions for anyone who has been down this road before: > >1.) Is my understanding of the 3725 requirements correct? There is an alternative IF you always call the same telco number on any given physical link. >2.) Can someone recommend an ACU or modem and ACU pair that has worked > well in the past (and is reasonably priced)? > You can buy an ACU and hook it to ANY modem that has A/A1 or M1 signalling on it's telco jack. I would recommend staying with a single vendor though. We did this at Amdahl using the Codex ACU and the Codex 2264 V.32 modem. This gives 9600 bps. Their newer V.32bis modem works as well, and offers 14,400 for list price of about $1100. If you are using switched 56, most offer optional RS-366 ACU's. One warning, RS-366 and V.25 parallel dial have a few subtle differences. We did manage to get a V.25 port to talk to the RS-366 dialler without too much trouble after we stopped getting fancy with 2 stage dialling. There are also a LOT of problems with the timing of the DSR lead and the time the V.32 modems are ready to actually xmit...these are noted below. >I am aware that with a modem that implements V.25bis this configuration >could be reduced to just one 3725 port. Neither the microcode nor the >EP in my 3725 supports V.25bis. I am almost certain that IBM Europe has V.25bis HDLC dial available.....their ISDN Terminal Adapter supports this as well as X.21. However, back to the alternative. IF and only IF you are always dialling the same number from any given link, you can use the "Direct Dial" mode of V.25bis with the '25. Any fully V.25bis compliant modem will dial a pre-stored number when you raise DTR. If you are able to try this, I would HIGHLY recommend only a V.32bis modem (the Codex still win's my vote) as their training procedures are much faster. What you will have to do is set the ENABLETO timer in NCP to a long enough value to allow the dial to complete and allow for at least TWO initial training events. I seem to remember the maximum value is 57 seconds...which is just about right. The bad news is that ENABLETO is a GLOBAL parameter for the entire NCP....and you cannot bring down NCP if there are any unexpired timers running. IMHO the NCP dwarfs overstate this...as I have yet to see 57 seconds make a bit of difference in recycling NCP or VTAM. You will also have to set the RETRY's parameters to make sure that the modem always has AT LEAST 16 seconds to perform retrains on noisy connections. This is just a combination of time-outs and retry counts which would allow the entire link to take a break for this period. Again, use a V.32bis modem....the V.32's take up to 48 seconds or more to retrain. (You may guess that the 3725 has yet to be brought up to date with MODERN smart modems like V.32's. You would be right. In implementing these suckers at Amdahl, I learned considerably more about NCP parameters and V.32 modems than I ever cared to know....) Tuning NCP for V.32's is not trivial.... I dunno if you know what the ENABLETO parameter does, so ignore if you do... When you raise DTR, the ENABLETO is how long NCP will wait for DSR before it notifys VTAM which takes the line INOP. You will either need a VTAM CLIST (barf....chews machine cycles also) or manual intervention to vary the line back up. On a switched line with switched RTS/CTS (HIGHLY recommended) as soon as DSR comes up, NCP will raise RTS and expect CTS. NCP uses the ENABLETO timer for the COMBINATION of DSR on and CTS in combination with RTS to detect the line is available. NOTE that this sequence is ONLY used by NCP for the initial raising of CTS after DSR comes on....after that the RETRIES parameters determine how long NCP will wait for a modem in-data retrain. The V.32 modem will dial the number, then as soon as it notices that the other modem is a V.32 with a compatible feature set (takes dial time + about 8 seconds) it will raise DSR. It is STILL not ready to communicate. It takes a few more seconds to equalize the line and correct for any echoes. After it has done all this and is ready to communicate, it will raise Carrier Detect...and allow CTS to respond to RTS. If you have a soldering iron, you can actuall help NCP out a little by taking the modem's Carrier Detect lead and wiring it over to the DSR lead. This will keep the NCP from seeing DSR (now CxDet) until the modem is ready to give CTS. > If I haven't turned you off on using V.32 modems, keep my e-mail address handy for when you actually try to implement this. For a small pile of unmarked bills, I should be able to save you a lot of experimentation time. >:-) Lon Stowell Staff Consultant Pyramid Technology lstowell@pyrnova.pyramid.com