tedcrane@batcomputer.UUCP (04/15/87)
We recently installed a DECserver 200/MC (a terminal server with full modem control) for use with several VMS systems. After configuring a port on the server for a DF224 modem and configuring the port on the VMS systems, we have been able to use it somewhat. We have also encountered a number of problems which are detailed below. Suggestions of workarounds would be appreciated. Mail them to me and I will post a summary of them here. 1) Alternate speed fallback isn't working. In the DECserver, you can specify DEFINE PORT SPEED 2400 ALTERNATE SPEED 1200. The server is supposed to watch the output of a pin on the modem (pin 12, SMI, speed mode indicator) and change speeds when the signal changes. The modem is supposed to send the correct signal on that pin. When configured this way, the modem can only be used at 1200 baud. At 2400 baud, you get garbage. It is obvious that the DECserver is transmitting at 1200 baud. We SPR'ed this to DEC and they have confirmed that there is a problem (believe it or not) in the DF224. Questions: Has anyone else encountered this phenomenon, and has anyone found the fix for the DF224 (from DEC or otherwise)? 2) You can't do a call-back. It would be convenient to have the computer call the remote user rather than the other way around. Two reasons, at least: (1) If sessions are initiated by the computer using a supposedly secure list of telephone numbers, you can eliminate random dialers and (2) if you like to work at home and your local phone company likes to charge by the minute, your office can often make the call cheaper (to you, and maybe even cheaper to them!). Unfortunately, the software setup (both in the server and VMS) defeats any attempt to do this. We've tried initiating the session at the computer. Easy enough, you just have a batch job connect to the modem, dial out, and the remote user is hooked up. This is done via an "applications port" set up by LATCP on VMS. Now, just as the user is ready to hit <CR> and get a username prompt, the carrier drops and the line is dead. This happens because you CANNOT (obviously) log in to an applications port. You have to log in to an interactive port. So the batch job has to deassign its channel to the port and deallocate the port. The server, at the same time has to make the dynamic switch between a remote and a local connection. Unfortunately, the server hangs up the line while doing so. Yes, we know about the /NOHANGUP qualifier in VMS. It works fine *IF* you are terminating one interactive session and want the line held up so you can start another. It does not work in this case. [Incidentally, this same arrangement worked JUST FINE ;-) when implemented via a DZ11 interface which has been sold, sigh :-( ] Questions: has anyone else tried this with any success? It could probably be done by wiring various pins to fake the modem into keeping the line alive...but that would be out of the spirit of the matter. 3) We have usually made outgoing calls through the modem directly from the server (i.e., Local> connect modem). We find that after a successful connection, the next "connect" works but the modem does not respond. If you issue a "disconnect" followed by another "connect", you've got a live session! Questions: has anyone else seem this behavior? Got any suggestions? Thanks in advance, folks. -- - ted crane, alias (tc) tedcrane@tcgould.tn.cornell.edu BITNET: tedcrane@CRNLTHRY tedcrane@squid.tn.cornell.edu DECnet: GOPHER::THC