From: CRDGW2::CRDGW2::MRGATE::"SMTP::CUNYVM.CUNY.EDU::POSTMASTER%YMIR.BITNET" 18-MAY-1989 09:37 To: MRGATE::"ARISIA::EVERHART" Subj: Re: MASTER.COM and LAT lines Resent-From: @CUNYVM.CUNY.EDU:postmaster@YMIR.BITNET Received: from YMIR.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with BSMTP id 4513; Thu, 18 May 89 06:32:48 EDT Date: Thu, 18 May 89 03:08 PDT Errors-To: postmaster@YMIR.BITNET From: Ned Freed Message-Id: Resent-Date: Thu, 18 May 89 03:10 PDT Resent-Message-Id: Resent-To: INFO-PMDF-LIST2@YMIR.BITNET Subject: Re: MASTER.COM and LAT lines To: info-pmdf@YMIR.BITNET X-Vms-To: IPMDF Ian Hill writes: > We currently dialout thru a LAT port which is connected to a Hayes-compatible > modem on out VAX 3600 running VMS 4.7 and PMDF v3.0. I use a little > mickey-mouse program to assign the LAT port to the PMDF batch job (using > the program shown below (I know its tacky but it works!): > ... > Up until now, I've only ever dialled out to one number, so there's been > no problem. > Yesterday I tried to add a bit of fail-safe by giving PMDF two different > target phone numbers to dial into on the ACSnet host machine. I did this > using the procedures described on pp IV-5 to IV-7 of the PMDF manual. > The result was that PMDF could never successfully make a connection. > Scratched my head over this one. Turns out that for some reason, the LAT > port fails the test for ownership/shared-device which is built into the > section of MASTER.COM which deals with alternate target phone numbers. > Once I'd commented out these 3 lines, it worked fine. I presume the lines > are trying to figure out whether someone else has the modem, but it looks like > you can't do this test with LAT. This is not the behavior I see. I use modems on LAT lines all the time and this never happens here. However, I don't see any reason to continue to do the test either. MASTER.COM explicitly turns off SHARE privilege, so there's no chance of allocating the wrong device by mistake. I'm going to remove it in the next release of PMDF. I'm not going to issue it as a patch at this time since I cannot reproduce the problem the removal is supposed to fix. The sample LAT allocator was interesting. PMDF 3.1 does something a lot like this inside MASTER.EXE. PMDF 3.1 makes the further generalization that the logical name can be a search list (or a list of lists, or whatever), and PMDF will try all the devices in the list until it finds one that is free. This is great for dealing with modem pools. We have been using this code in PMDF locally for some time and it works very well with our pool of 8 Trailblazer modems on a DECserver-200. The same code is also present in the MATHLIB DIALOUT utility, which is a smart replacement for both SET HOST/DTE and PHOTO. One of the problems with this new scheme is that you cannot do any line conditioning in ALL_MASTER.COM. Which of the lines gets conditioned? Another problem is that fiddling with a LAT line in ALL_MASTER.COM sometimes forces the connection through, which in turn makes MASTER.EXE unhappy when it tries to use the $QIO interface. Accordingly, I have added the ability to control the HOSTSYNC, TTSYNC, EIGHTBIT, and SPEED characteristics to the PMDF options file. Very few of the other settings make sense on a LAT line (SPEED doesn't make sense either, but it is nice to have for non-LAT lines). Ned