Local Area Transport (LAT) protocol (which, strictly speaking, is neither DECnet nor part of TCP/IP) ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.sys.dec,comp.protocols.misc,comp.os.vms Followup-To: comp.sys.dec Path: utkcs2!emory!swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au !metro!usage.csd.unsw.oz.au!newt.phys.unsw.OZ.AU!pwb Message-ID: <1225@usage.csd.unsw.oz.au> References: <1109@usage.csd.unsw.oz.au> <1991Feb26.114428@kalvin.enet.dec.com> <1991Mar2.070142.39595@camb.com> Summary: summary Sender: news@usage.csd.unsw.oz.au Lines: 130 Date: 16 Mar 1991 05:06:03 GMT From: pwb@newt.phys.unsw.OZ.AU (Paul W. Brooks) Subject: Re: LAT protocol? Thanks to all who replied to my request a few weeks ago on the LAT protocol. Here is the summary of replies. I hope to have something running shortly! From: lstowell%pyrnova.pyramid.com@munnari.oz (Lon Stowell) } } DEC has finally decided that LAT is proprietary and licenseable } technology. I haven't heard yet whether this means they will } actually publish the specs in a comprehensible format or not. } Hopefully you will get FTP sources for drivers etc. from your } posting. [ I didn't :-) ] From: "Kevin Oberman, LLNL, +1 415-422-6955" } } LAT is both proprietary and patented. Licenses are available, but the pricing } is aimed at commercial implementors. I believe the base price is in the $10K } range. The only way to get documentation is to license the protocol from DEC. } It's a pretty simple protocol and was reverse engineered by several companies } before the patents were granted. Some of these companies have bought licenses, } others are being sued for patent infringment. Some may have dropped the } products in question.(There is nothing illegal about selling a patentable item } before the patent is granted, but you have to stop as soon as it is.) } LAT for PCs is available from many vendors including Datability. I have no } experience with any non-DEC implementation. From: ken@pluto.dss.com (Ken Adler) } } Yes Lat is proprietary to DEC. Reverse engineering it is a somewhat } involved project. There are a few companies that already have reversed } engineered and have it available in a number of forms. Datability is one } company. We use the LAT in our PC based products, our Terminal/Communication } Server HArdware, and our Unix based LAT services product. } Good Luck. If I can of any help, please let me know. [Thanks. I will be in touch shortly] From: "Franz Schoenbauer, Computer Science," } Well, we have done this just in the last few weeks. We were unable to get any } specs and tried to reverse-engineer the protocol by tapping an ethernet line } and watching the packets go back and forth. Not very nice. But we ended up } with something that does at least work. The program makes a vax pretend it } is a terminal server. Embedded in the program is the protocol, mostly uncovered } by educated guesses and a few packet types still completely unclear, but } terminal emulation works. } If you are interested i'm willing to make the source available (FTP). } On the other hand if somebody points you to any reference, please let me know, } we'd be feeling better if we knew what those strange packets are... A [Well, I didn't get any references to papers on LAT (as you can see) BUT I may have a pointer to a reference on packet types somewhere. I'll send the info when I find it] Thanks, Franz [ Thank you ] From: Joerg Stadler } We use the latest version of KERMIT as terminal emulator with the LAT } protocol. On the PC, we have DEC's DECNET for DOS software, which includes } a LAT driver. After starting LAT on the PC, one can use the KERMIT command } 'SET PORT DECNET ' to start a terminal session with an arbitrary on the } net. } Hope this helps. [Thanks for the info. Depending on how memory hungry it is, and whether it can be made memory-resident on a PC, I may use this approach.] From: Roger Ivie > 1) Is the protocol published somewhere, or is it proprietary? } It's proprietary. Several years ago DEC decided to license it since people } were writing things to talk to it anyway; at that time they were charging } something on the order of $10,000 for a license. } Roger Ivie [ Thanks. Isn't it a good think other licenses (car, boat, etc) aren't that much!] From: A deviant having fun ! 04-Mar-1991 1243 >> 1) Is the protocol published somewhere, or is it proprietary? } The protocol is proprietary but has been reversed engineered several } times. >> 2) If proprietary, is there any way I could obtain the specs >>anyway (:-) Its worth a try!) } Yes. It is available under a variety of licenses. These include a } reference implementation in C. Write to Robert Schlelein who is the } licensing manager. He is reachable by email at : } schleelein@delni.enet.dec.com } and by paper at: } Robert Schleelein } Digital Equipment Corp. } 550 King Street (LKG2-1/X2) } Littleton, MA 01460-1289 } Ph: 508-486-7017 } FAX 508-486-7417 >> 3) Does anyone have any comments, suggestions or pointers to a >>previously written implementation so I might not have to roll-my-own? } There are a few implementations which I know of. Most are commercial } ones rather than public domain. A company called Meridian has a product } called SuperLAT which is a portable toolkit for rolling your own. } Contact is Don Hirsh at 314-532-7708. [ This is the definitive reply from the man at DEC!] Thanks also to the following for posting with essentially the above information: gerhardt@kalvin.enet.dec.com bruce@camb.com (Barton F. Bruce) ...... In short, ladies and gentleman, it is proprietary, for $10K (presumably $US !) it can be yours, or it can be done that hardway and you may or may not be sued!. Thanks again for everybodies help. Let the Project begin.!! Paul Brooks |Internet: pwb@newt.phys.unsw.edu.au Uni. of N.S.W. |If you have trouble sleeping, try lying on the end of Kensington NSW 2033| your bed. With a little luck you'll drop off. AUSTRALIA | - Mark Twain. ////////////////////////////////////////////////////////////////////////////// Message-ID: <744o1q$oaj$1@news.usit.net> NNTP-Posting-Host: dialup399.tnkno.usit.net Date: Wed, 2 Dec 1998 19:59:23 -0500 From: Kent Rankin Newsgroups: comp.terminals Subject: Could LAT be reverse engineered? What prevents someone from reverse engineering LAT? I know that they do not publish the standard, but does that mean that someone can't make an implementation of it, and let it run under the GPL? How complex is LAT? As I'd like to get a daemon running that I could use just for myself and some friends, if it couldn't be spread under the GPL. Also, I know that there are a lot of products for using LAT on the PC. Are there any for Linux or Solaris? Thanks in advance, Kent Rankin ////////////////////////////////////////////////////////////////////////////// Message-ID: <3666A07D.7763@smarts.com> Organization: System Management ARTS Date: Thu, 03 Dec 1998 09:30:21 -0500 From: Jerry Leichter To: Kent Rankin Newsgroups: comp.terminals Subject: Re: Could LAT be reverse engineered? | What prevents someone from reverse engineering LAT? I know that they | do not publish the standard, but does that mean that someone can't | make an implementation of it, and let it run under the GPL? LAT is not particularly complex, and in its early days it was reverse- engineered more than once, with varying degrees of correctness. However, certain key elements of the LAT protocol are patented in the US and in just about all the rest of the world. It would be impossible to produce a implementation that actually did anything useful without infringing the patent. [UPDATE: Has the patent situation changed since 1998?] | How complex is LAT? As I'd like to get a daemon running that I could | use just for myself and some friends, if it couldn't be spread under | the GPL. That would be a clear infringement of the patent. (Let's not get into a debate about whether you infringe if you "give it away free" or "just use it yourself". Under US law - and, generally, almost all other patent laws, since most countries have not signed treaties that provide fairly uniform definitions - you do. Period.) DEC sold its terminal business to a company with some wierd name like Unbounded Computing* --someone here will know the name. Obviously, they got at least a license for LAT; they may have gotten all the patent rights. And later, of course, Compaq bought DEC. So who handles LAT licensing now - if anyone still actively does so - I couldn't guess. In practice, if you really used the thing just for yourself and a few friends, it's unlikely the patent holder would ever *know* - though of course you've announced your intentions to the whole world with your message! On the other hand, if you GPL'ed the code and started spreading it around, I'd certainly expect that you'd soon be hearing from *someone's* lawyers. | Also, I know that there are a lot of products for using LAT on the PC. | Are there any for Linux or Solaris? I doubt there are any for Linux. If anyone has done a product for Solaris, it would likely be the companies that did Solaris DECnet implementations. -- Jerry [LAT co-inventor] [No, I don't get any part of the license fees!] [* Archiver's Note: He means "Boundless Technologies" 1-800-231-5445 ...RSS] ////////////////////////////////////////////////////////////////////////////// In 2005, there apparently exists an open-source LAT implementation at least for Mac OS X (OpenDarwin): http://darwinports.opendarwin.org/darwinports/dports/net/latd/Portfile ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.sys.dec,comp.os.vms,vmsnet.networks.tcp-ip.misc Path: cs.utk.edu!gatech!howland.reston.ans.net!noc.near.net!uunet!tis.com!mjr Organization: Trusted Information Systems, Inc. Lines: 42 Distribution: world Message-ID: <22ksnq$935@sol.TIS.COM> References: <1993Jul21.193011.24925@colorado.edu> <22kbqb$qr@sol.TIS.COM> <22kq5sINN4ck@gap.caltech.edu> NNTP-Posting-Host: sol.tis.com Date: 22 Jul 1993 02:06:50 GMT From: mjr@tis.com (Marcus J Ranum) Subject: Re: TCP/IP instead of DECNET? In article <22kq5sINN4ck@gap.caltech.edu> carl@SOL1.GPS.CALTECH.EDU writes: >= >= TCP/IP doesn't multiplex because it doesn't have to. >=Terminal traffic-specific optimizations like keystroke multiplexing >=belong at an application level not a protocol level. > >Speaking from ignorance, are we? LAT multiplexes SESSIONS, not keystrokes. No, I'm not speaking from ignorance. We're just disagreeing on our terminology. If you'd actually read my post to try to see what I was talking about, it'd be obvious that we're describing the same thing. The issue is interactive terminal traffic and bursty terminal traffic to terminal servers is very inefficient if you send each keystroke or small groups of characters in individual packets. So you multiplex the keystrokes or sessions or whatever term you want to use, and gather all traffic between two points up to the expiration of some timer or a packet's filling. None of this is rocket science. DEC did the right thing with LAT, for the technology of the time when it was done. Nowadays it's simply not smart to write a whole new (proprietary, licensed, expensive, non-routing, application specific) protocol JUST to satisfy a small set of applications. I suspect that eventually terminal server makers will get tired of supporting and licensing LAT and it'll go the way of the velociraptor. HP's proposed some terminal traffic specific mods to the telnet protocol (which runs on top of TCP/IP) to multiplex character traffic (sessions) because the BSD design of a single telnetd per session, and a packet per keystroke doesn't scale well to mainframe levels - multiplexing keystrokes cuts traffic about 60% or more. Other terminal server vendors are taking a more forward looking view and are examining a general small-packet multiplexing protocol that would run on top of IP, for terminal servers. For what it's worth, LAT's multiplexing is a big win. I did a benchmark where we used RTEs to emulate monkeys at keyboards and with 100 users telnet/rlogin toppled but the machine handled it with LAT. So we know multiplexing is a good idea, but that doesn't mean LAT is, or that IP isn't. mjr. -- C++ -> C :: cancer -> lung ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.sys.dec,comp.os.vms,vmsnet.networks.tcp-ip.misc Path: cs.utk.edu!gatech!howland.reston.ans.net!noc.near.net!uunet!tis.com!mjr Organization: Trusted Information Systems, Inc. Lines: 71 Message-ID: <22m65q$nkj@sol.TIS.COM> References: <22kq5sINN4ck@gap.caltech.edu> <22ksnq$935@sol.TIS.COM> <1993Jul22.030325.14346@colorado.edu> NNTP-Posting-Host: otter.tis.com Date: 22 Jul 1993 13:54:02 GMT From: mjr@tis.com (Marcus J. Ranum) Subject: Re: TCP/IP instead of DECNET? dwing@uh01.colorado.edu writes: >> >> For what it's worth, LAT's multiplexing is a big win. >>I did a benchmark where we used RTEs to emulate monkeys at >>keyboards and with 100 users telnet/rlogin toppled but the >>machine handled it with LAT. So we know multiplexing is a good >>idea, but that doesn't mean LAT is, or that IP isn't. > >LAT was designed (like you said, years ago) to offload processing from the >host and make the terminal server do 'extra' processing; it would be expected >to have less impact than a TCP connection. Do you recall what the delta in >Ethernet utilization was during your test (I know that 60% is an oft-quoted >number, but it often depends on how many terminals are being driven by one >terminal server and how often your timer expires (or your frame fills up) >before send a frame) -- I'm curious as to what your test showed. We didn't have a packet sniffer monitoring the network. In the benchmark in question, it was on its own segment and there was a single server with 2 RTEs. Each RTE managed 50 virtual sessions. There was a problem the first time we ran it, with the RTE software bogging the RTE machine down so badly (thrash, thrash, thrash) that it wasn't even able to load up the server! There were 2 main effects that I saw, firstly, having 100 telnetd/rlogind processes on the server cheerfully context switching their brains out was a Bad Thing. Using LAT means that the data gets delivered to the virtual terminal stack directly upon receipt in a kernel context. This is the primary reason (more than network load!) that the folks at HP want to multiplex telnet over IP. They use an in-kernel implementation of telnet service, so effectively there IS no telnetd - it works much like LAT does. In-kernel telnetd is a Good Thing for large installations. Arguments are currently continuing in favor of a general terminal-oriented small packet multiplexing service in the kernel - it's my hope that a more forward-thinking solution than just a hack for telnet will result. [rlogin/telnet/X-window are all services that lend themselves to multiplexing between terminal servers and hosts] The second major difference was just a resource use issue - 100 telnetds and associated file descriptors and memory waste a lot more than a single in-kernel LAT demultiplexer routine! This, hopefully, is being fixed. >Regarding LATs expense, licensing, proprietary, etc: several companies >sell LAT products imbedded in hardware and firmware (Meridian, Thursby, >and Ki Research come to mind). I view the major weakness of LAT to be >its general non-routability (although you can get around this by various >means). It's a multiprotocol world, but anyone who has managed a network will tell you that each protocol adds hassle factor in terms of software base platforms, compatibility, and interoperation. This, in fact, is one of the main reasons that IP has become one of the de facto standard networking protocols - you can put an IP stack in anything without having to decode a proprietary protocol and license it from a single source. Lots of people still sell LAT, but I predict it's going to start to wane eventually. As the environment gets more heterogenous it's simply not a win to use LAT anymore. For example, if you have a computing center with a VAX cluster and 2,000 PCs it is MUCH cheaper to put IP on the VAX, and use one of the free versions of IP on the PCs, than to use the "free" version of LAT that comes with the VAX and buy 2,000 copies of some kind of LAT driver. Add a few other types of machines, say, an RS6000 and a few SGIs and a DECstation and you've got to buy LAT on them... Of course what most folks wind up doing is mixing LAT and IP for transport. So nothing is consistent for the user - they can dial a terminal server, LAT to the VAX, and telnet to the Sun - it works but it's ugly. mjr. "call me a protocol fascist" -- C++ -> C :: cancer -> lung ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.sys.dec,comp.os.vms,vmsnet.networks.tcp-ip.misc Path: cs.utk.edu!gatech!howland.reston.ans.net!usc!news.service.uci.edu !gordius!gordius!mike From: mike@gordian.com (Michael A. Thomas) Subject: Re: TCP/IP instead of DECNET? Message-ID: <1993Jul24.001351.2786@gordian.com> Sender: news@gordian.com Organization: Gordian; Costa Mesa, CA References: <7168@npri6.npri.com> <1993Jul21.193011.24925@colorado.edu> <22kbqb$qr@sol.TIS.COM> Date: Sat, 24 Jul 1993 00:13:51 GMT Lines: 61 In article <22kbqb$qr@sol.TIS.COM>, mjr@tis.com (Marcus J. Ranum) writes: > TCP/IP doesn't multiplex because it doesn't have to. This smells suspiciously like a tautology. > Terminal traffic-specific optimizations like keystroke multiplexing > belong at an application level not a protocol level. Marcus, I think you are being obtuse. If you really want to get nit picky, you can easily divide LAT into two layers: 1) The virtual circuit layer (network+transport) 2) The slot layer (application) There is not a reason in the world why you could not develop a LAT which allows multiple virtual circuits to/from the same host and be equivalently inefficient as TCP in the multiplexing scheme. I understand that this would be broken in VMS (and, undoubtably Ultrix, but what isn't broken in Ultrix) but that is just an implementation detail. The LAT I wrote wouldn't have a care in the world if you ran it this way. > Using a non-routing transport > protocol for terminal traffic is stupid. This is about the only valid criticism you have here, and it is significant. Just to add some fuel to this fire, we have a customer who is doing remote printing with our boxes using LAT from the VAX to our box which converts it to TCP for the long haul (across their Cisco's) and then out to another terminal server on the remote net. It's pretty gross, but it keeps LAT off their WAN and sells our boxes :-) > Currently stuff like telnet and rlogin are a drain on network > resources because of their bad habit of sending a packet per > keystroke. But that's a application level braindamage, not protocol > level braindamage. It's DEFINITELY braindamage, and it is being > fixed. A fixed input timeout sovles the problem nicely. It is not very difficult at all. > > LAT has destroyed more perfectly good networks than anything > else I can think of, simply because it doesn't route, and while it's > intended for LOCAL area transport, short-sighted network managers > tend to bridge their whole network into one gigantic mess, just so > they can use LAT. Hopefully they don't do this in hopes of realizing > some kind of performance gain. ;) Probably the worst aspect is the service advertising. But if you're going to go on a rant about multicast traffic, you should include crAppleTalk and Netware too. LAT at least has no pretensions about scaling. -- Michael Thomas (mike@gordian.com) "I don't think Bambi Eyes will get you that flame thrower..." -- Hobbes to Calvin USnail: 20361 Irvine Ave Santa Ana Heights, Ca, 92707-5637 PaBell: (714) 850-0205 (714) 850-0533 (fax) ////////////////////////////////////////////////////////////////////////////// Newsgroups: vmsnet.uucp Path: cs.utk.edu!emory!swrinde!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu !mccall!infopiz!inland!allebrandi Message-ID: <1993Jan27.212636.2617@inland.com> References: <1993Jan20.195937.4780@verifone.com> Organization: Inland Steel Company; East Chicago, IN Date: 27 Jan 1993 21:26:36 CST From: allebrandi@inland.com (Tom Allebrandi) Subject: Re: Ultrix/VMS link needed In article <1993Jan20.195937.4780@verifone.com>, jimmy_t@verifone.com writes: > > If I have a VMS and Ultrix machine on the same Ethernet, > can I configure Decus UUCP to transfer mail back and forth > between the two systems over Ethernet? (There is no TCP/IP > software on the VMS system) Without putting a whole lot of thought into this... Are you running LATMonster on your VMS system? (Optional in 5.4, standard in 5.5) If so, how about creating a LAT forwarding port assigned to a LAT service offered by the Ultrix system? Under LATMonster after you create an LTA device using LATCP's CREATE PORT command, you can assign it to a service by doing SET PORT/APPLICATION/NODE=HOST/SERVICE=SERVE Just a thought. --- Tom Tom Allebrandi | Mail guru - DECUS UUCP Development Team Inland Steel Research Labs | NFS grunt - CMU/Tek-IP East Chicago, IN | Chairperson - VMSnet Working Group, DECUS VAX SIG 219 399 6306 | Internet: allebrandi@inland.com DECUServe: allebrandi | UUCP: ...!uunet!inland!allebrandi ////////////////////////////////////////////////////////////////////////////// Newsgroups: vmsnet.misc Path: cs.utk.edu!emory!nigel.msen.com!yale.edu!newsserver.jvnc.net !atlantis.psu.edu!juncol.juniata.edu!ring Message-ID: <1993Mar25.144828.225@juncol.juniata.edu> References: <1993Mar24.003010.212@juncol.juniata.edu> <1opudj$bm0@umd5.umd.edu> Organization: Juniata College, Huntingdon, PA -- USA Lines: 49 Summary: Solution Distribution: world Date: 25 Mar 93 14:48:28 -0500 From: ring@juncol.juniata.edu (John Charles Ring) Subject: Re: Outgoing modems via DECserver? (Solved) Thanks to the following people for their responses: bill@bill.ab.umd.edu Carpenter@Fwva.Saic.Com ake@dayton.saic.com dwing@uh01.Colorado.EDU Although this was an easy question, I'll summarize & expand a bit. All responses were mostly identical, so here's the one from bill@bill.ab.umd.edu, with a few comments of my own. > 1) Set the terminal server port for DYNAMIC access. ^^^ A few people suggested REMOTE, which of course would mean we can't use them for dialin, which we are doing. Either works for the question as asked, of course. > 2) Use LATCP to create an application port pointing to the modem port: > > $ run sys$system:latcp > LATCP> create port lta100: > LATCP> set port/app/node=servername/port=portname lta100: ^^^ This was unclear (to me) as to if it should be the DECNET node name I've given it, our the name given to it from local> SET SERVER NAME servername Of course, since the DECNET part is optional if you are not using TSM, I should have known it was the later. > 3) Set the appropriate terminal characteristics. Actually, with the SET HOST/DTE/SPEED=2400, it works right off, assuming the DECserver port is set up correctly. (Or at least it did here :-) > You should be able to SET HOST/DTE to the resulting terminal device. > Personally I recommend using KERMIT instead of SET HOST/DTE. Actually, that's what I had in mind :-) Otherwise, simply having it at a Lat service, set host/lat worked fine. P.S. The problem was that I was attempting CREATE PORT/SERVICE=thatmodemservice, but that wasn't turning the trick! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Myself - John C. Ring ~ "And the blind will lead the sighted" ~ ~ E-self = Ring@Juncol.Juniata.Edu ~ --- ~ ~ This is a recording ~ TRIUMPH ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.os.vms Path: utkcs2!emory!swrinde!cs.utexas.edu!uunet!convex!egsner!montagar!davidc Message-ID: <16447.28115435@montagar.lonestar.org> References: <1991Apr19.201714.15698@ucselx.sdsu.edu> <12577@uhccux.uhcc.Hawaii.Edu> Organization: Public Access VAX/VMS BBS, Plano TX Lines: 39 Date: 21 Apr 1991 08:58:29 GMT From: davidc@montagar.lonestar.org (David L. Cathey, SYSOP) Subject: Re: Using auto login feature with variable term. server ports ... In article <1991Apr19.201714.15698@ucselx.sdsu.edu> mccurdy@ucselx.sdsu.edu (mccurdy m) writes: > I am trying to set up a VAX/VMS system to be used as a kind of >transparent communciations server. One of the things that I want to do >with it is enable users to log into it without having to type in a >Username. In using ALF from within SYSMAN, it seems that I cannot define >a wildcard port entry such that users coming in from all terminal servers >would get knocked into a particular account. I am able to execute a >SYSMAN>ALF ADD /PORT "*" username command, but I am assuming that ALF >will be looking for a port called *. True? Does anyone know of another >solution to this problem? It's not feasible to define every server port >name on campus. And, what about users coming in thru PC's or MAC's with >Ethernet cards? How would they be defined? Thanks much in advance ... Since you don't know what LAT port they are going to come in as, you can't do this. If you do, normal accessors (wanting a Username:) will get your program, too. What you need to do is create a set of ports with a dedicated service. $ MCR LATCP LATCP> CREATE PORT LTA1000: /DEDICATED LATCP> SET PORT LTA1000: /DEDICATED /SERVICE= ... LATCP> EXIT Then run your application on each port, probably in a loop: $ loop: $ assign/user lta1000: sys$input $ run $ goto loop When they connect to the service, they are connecting directly to the application without logging in. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - David L. Cathey |INET: davidc@montagar.lonestar.org Don't blame me! I voted for Bill and |UUCP: ...!texsun!montagar!davidc Opus for President! Ack! Thhrrptt! |Fone: (214)-618-2117 ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.sys.dec,comp.os.vms Path: utkcs2!emory!swrinde!mips!spool.mu.edu!news.cs.indiana.edu!noose.ecn.purdue.edu!mentor.cc.purdue.edu!WESTERM@aclcb.purdue.edu Message-ID: <00948BEC.8A7456C0@aclcb.purdue.edu> References: <42405@cup.portal.com> Sender: news@mentor.cc.purdue.edu Reply-To: westerm@aclcb.purdue.edu (Rick Westerman) Organization: Purdue AIDS center Date: 17 May 1991 20:27:40 GMT From: westerm@aclcb.purdue.edu (Rick Westerman) Subject: Re: Putting a modem on a LAT server >Billy D'Augustine (Azog-Thoth@cup.portal.com) writes: > >I would like to attach a modem to our DECserver 200/mc, for the >purposes of dialing out, and have some questions regarding this... > I had constant trouble with this until I upgraded (last week) to VMS 5.4-2 and LAT 5.4-2. The new LAT allows you to specify outgoing (from the VAX) connections to LAT services; e.g., the VAX can act like a terminal server. Once you setup the VAX via LAT to be a terminal server, you can then do a "set host/lat service_name" to get to the service. Pre-LAT 5.4-2 you could, in theory, have an outgoing connection that would go to a specified terminal server and a specified port on the terminal server. Because I was using non-DEC terminal servers, the server's name was not being accepted by the VAX (or not being generated properly by the terminal server, I could never figure out which machine was the culprit) and thus I couldn't connect to the outgoing modems from my VAXen. Try using LATCP to setup outgoing connections and if that doesn't work, upgrade to 5.4-2. -- Rick Rick Westerman System Manager of the AIDS Center Laboratory westerm@aclcb.purdue.edu for Computational Biochemistry (ACLCB), BCHM (317) 494-0505 bldg., Purdue University, W. Lafayette, IN 47907 If you can't fight or flee, then flow. ////////////////////////////////////////////////////////////////////////////// Article 37417 of comp.os.vms: Path: utkcs2!emory!att!linac!convex!egsner!lerami!txsil!danmc From: danmc@txsil.lonestar.org (Dan McDonald) Newsgroups: comp.os.vms Subject: Re: VMS 5.4-3 LAT 5.4-3 Message-ID: <585@txsil.lonestar.org> Date: 28 Oct 91 21:31:58 GMT References: <1991Oct26.201815.192620@rrz.uni-koeln.de> Organization: Summer Institute of Linguistics, Dallas Lines: 39 In article <1991Oct26.201815.192620@rrz.uni-koeln.de> moravec@Ph1.Uni-Koeln.De writes: > > VMS 5.4-3 update > >Is it safe to install LATU3054 (it seems to be built MAY 1991) or has it >still some (system-crashing) bugs as LAT 5.4-1 and 5.4-2 ?? I can't say for certain, since I haven't got my hands on 5.4-3 yet, but I do know that they delayed the release of 5.4-3 because of bugs found in LATmaster. I also happen to know that a new patch for LATMASTER just came out of CSC. The patch number is CSCPAT511-V2.4. If I were you I would get that patch before installing LATmaster 5.4-3. As a quick test, if you were to unpack the LTDRIVER.EXE file out of the installation kit, see if the image version (from ANAL/IMAGE) is greater than 6-286. If it is 286 or greater, then the image is good and won't crash your VAX. > >Shall I wait until VMS 5.5 (this is "the next functional release of the >VMS op sys" ?) when it "will no longer be optional but will be the >default VMS LAT software ? [quoted from Cover Letter for VMS 5.4-3] There are a number of advantages to LATmaster - SET HOST/LAT is the least of them. I appreciate being able to create ports and assign logical names on the fly. There is also a bit of work that has to be done when you convert. I would suggest that you do it now, just so you know that you have one less thing to work on when the next "functional" release comes out. ****************************************************************************** Dan McDonald * UUCP ...utafll!txsil!dalsil!mcdonald Summer Institute of Linguistics * Internet mcdonald@dallas.sil.org Dallas Computer Services * -OR- danmc@txsil.lonestar.org 7500 W Camp Wisdom Rd * SILnet DAN.MCDONALD@A1@DALLAS Dallas, TX 75236 * POTSnet (214)709-3389 USA * FAXnet (214)709-3387 ****************************************************************************** ////////////////////////////////////////////////////////////////////////////// Path: utkcs2!ornl!sunova!linac!uwm.edu!zaphod.mps.ohio-state.edu !uakari.primate.wisc.edu!zazen!psl.wisc.edu!jevex.waisman.wisc.edu!karcher From: karcher@jevex.waisman.wisc.edu Newsgroups: comp.os.vms Subject: RE: LAT port id in Accounting record? Message-ID: <23APR92.16202208@jevex.waisman.wisc.edu> Date: 23 Apr 92 22:20:22 GMT References: <67829271269FC010DE@VXC.UNCWIL.EDU> Sender: news@pslu1.psl.wisc.edu (USENET News System) Organization: Waisman Center, University of Wisconsin-Madison Lines: 13 In a previous article, SYSMIKE@VXC.UNCWIL.EDU (Systems Programming) wrote: > >If this has been answered before, I apologize. Is there any way to get >the port name, or ID, of a LAT server placed in the accounting record, >instead of the usual LTAxxxx? Thanks, Sure, a program appeared in the Feb 91 issue of the VAX Professional. The author is Kevin F. Homan of SAI. It's available from the VAX Pro's ARIS bulletin board service and works fine. Carl Karcher Internet: KARCHER@WAISMAN.WISC.EDU Waisman Center Bitnet: KARCHER@WISCMACC University of Wisconsin-Madison PSTnet: (608) 263-5896 ////////////////////////////////////////////////////////////////////////////// Path: utkcs2!emory!europa.asd.contel.com!uunet!elroy.jpl.nasa.gov!swrinde !zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!hamblin.math.byu.edu !arizona.edu!mvb.saic.com!macro32 From: MILLER@TGV.COM Newsgroups: vmsnet.internals Subject: Re: WTFO... Message-ID: <707787167.299591.MILLER@TGV.COM> Date: 5 Jun 92 23:32:47 GMT Organization: Macro32<==>Vmsnet.Internals Gateway Lines: 18 X-Gateway-Source-Info: Mailing List > Data: LTDRIVER does its work at IPL 8. PADRIVER at 20. An > outage of 2.55 seconds or more would cause this problem. Does this only occure if LAT is running on the system? I'm shooting from the hip here, but I noticed something funny about the was LAT terminals work on SMP machines. Whenever a terminal UCB is deleted, the LT driver scans through the fork queues (IPL 8) on all of the processors to see if the UCB is queued up there. That's fine for the local CPU, but there doesn't seem to be (and no way, short of processor interlocking) to synchronize with the fork queues on the other processors. It's OK to remove something from the queue, but not to scan down it. This seems to me like a protential problem that might pop up when the system is heavily loaded. Any thoughts? -bruce ////////////////////////////////////////////////////////////////////////////// Path: utkcs2!darwin.sura.net!europa.asd.contel.com!uunet!stanford.edu!rutgers !spcvxb.spc.edu!terry From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) Newsgroups: comp.os.vms Subject: Re: Decserver console access from a procedure Message-ID: <1992Jun5.083155.3047@spcvxb.spc.edu> Date: 5 Jun 92 12:31:55 GMT References: <1992Jun3.165147.3545@mits.com.au> Organization: St. Peter's College, US Lines: 34 In article <1992Jun3.165147.3545@mits.com.au>, richard@mits.com.au writes: > Does anyone know how to perform DECserver console port commands from > a command procedure. We do NOT have TSM. > > I would like to write a procedure for my operators that performed an > operation on a DECserver Port automatically. > > I don't seem to have any luck trying to fool NCP. The last time I looked (quite a while ago), there was a hardcoded check in NCP to disallow this if the input wasn't a real terminal. I don't know why they didn't put a big "BUY TSM, FOOL!" comment in there too - it certainly seemed to be the intent... As part of the PDP-11 DECserver load/dump code I did for Digital Canada, I wrote the equivalent of "NCP CONNECT NODE". This code is in pure Basic-Plus (the system implementation language on the system this code was for) with a tiny Macro-11 subroutine. It should be simple enough to port to any platform where you can control the Ethernet adapter. (This leaves out VMS, as it grabs the MOP protocols and won't let you do an end run around it). What are you trying to do? I wrote another piece of code that lets me read the contents of the DECserver EEPROM. I then parse the contents and generate an accurate command file from it. [The command files you get from TSM's GET- CHAR are broken in a number of ways - for example, they don't reset passwords, the can't deal with mixed-case or blank-containing strings, and some versions generate gibberish or hang when they see "new" characteristics like signal check.] After reporting this to Engineering and having nothing happen, I came up with my solution. However, since it involves a modified server load image, I can't give that out. Terry Kennedy Operations Manager, Academic Computing terry@spcvxa.bitnet St. Peter's College, Jersey City, NJ USA terry@spcvxa.spc.edu +1 201 915 9381 ////////////////////////////////////////////////////////////////////////////// Path: utkcs2!darwin.sura.net!wupost!uunet!cis.ohio-state.edu !pacific.mps.ohio-state.edu!linac!att!ucbvax!cdclu1.genrad.com!dongray From: dongray@cdclu1.genrad.com (Derek Dongray) Newsgroups: comp.os.vms Subject: Re: Decserver console access from a procedure Message-ID: <9206091735.AA09066@genrad.com> Date: 9 Jun 92 17:35:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The Internet Lines: 24 In article <1992Jun3.165147.3545@mits.com.au>, richard@mits.com.au writes: > Does anyone know how to perform DECserver console port commands from >a command procedure. We do NOT have TSM. > > I would like to write a procedure for my operators that performed an >operation on a DECserver Port automatically. I use a package call TSCON written at the Anglia Higher Education College, Cambridge, UK and contributed to DECUS, Symposium Collection from the VAX SIG, Fall 1989, Anaheim (VS0106), hence also DECUS CDROM collection 6 (VS0114). It's written in Pascal and Macro and runs on VMS 5.4-x and 5.5 (I don't have any earlier versions to try it on, but comments in the files indicate it was running on a V4-V5.0 system). It runs happily with LAVc, DECnet, UCX and Pathworks (both PC & MAC versions) using the same ethernet adaptor to access DECserver 100's, 200's and 300's. -------------------------------------------------------------------------------- Name : Derek Dongray, Systems Manager, GenRad Ltd. Phone : 061 486 1511 ext 166 PSS : 234261600119::Dongray UKnet : Derek.Dongray@GenRad.co.uk InterNet : Dongray@cdclu1.GenRad.com CompuServe : 70374,2745 Address : Monmouth House, Monmouth Road, Cheadle Hulme, Cheshire, SK8 7AY, UK. ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.sys.dec,comp.unix.ultrix Path: utkcs2!darwin.sura.net!mips!decwrl!deccrl!news.crl.dec.com!news !nntpd.lkg.dec.com!lkg.dec.com!thomas From: thomas@lkg.dec.com (Matt Thomas) Subject: Re: ioctl(TIOC[CS]BRK) woes (was Re: Halting a DECstation via BREAK) Message-ID: <1992Jul17.224252.17475@nntpd.lkg.dec.com> Lines: 30 Sender: thomas@mipsbx.lkg.dec.com (Matt Thomas) Reply-To: thomas@lkg.dec.com Organization: Digital Equipment Corporation References: <1992Jul17.164906.7087@news.iastate.edu> <1992Jul17.194211.16289@news.iastate.edu> Date: Fri, 17 Jul 1992 22:42:52 GMT In article <1992Jul17.194211.16289@news.iastate.edu>, john@iastate.edu (John Hascall) writes: |> |>Why does the ioctl(TIOCSBRK) work (apparently), but the ioctl(TIOCCBRK) |>gets errno 25 (ENOTTY, "Not a typewriter")??? |> |> errno = 0; /* just in case */ |> if (-1 == ioctl(fdtty, TIOCSBRK, (char *)0)) { |> /* ... bitch about errno and exit ... */ |> } |> sleep(3); |> errno = 0; /* just in case */ |> if (-1 == ioctl(fdtty, TIOCCBRK, (char *)0)) { |> /* ... bitch about errno and exit ... */ |> } |> |>If it makes a difference, fdtty is a LAT tty `connected' with lcp -h. It does. LAT only can "send" a break, it can't clear a break. When it gets a TIOCSBRK, it send a DATA_B slot to the terminal with the BREAK bit set. TIOCCBRK has no meaning and the original author didn't check for it. I guess that we could modify LAT to silently eat the TIOCCBRK. Too bad abou the timing though. It's probably too late to get into ULTRIX V4.3 (but I'll try) but it can be incorporated into the next release of DEC OSF/1. -- Matt Thomas Internet: thomas@lkg.dec.com DECnet-ULTRIX Development UUCP: ...!decwrl!thomas Digital Equipment Corporation Disclaimer: This message reflects my own Littleton, MA warped views, etc. ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.os.vms Path: cs.utk.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!usc !elroy.jpl.nasa.gov!ncar!noao!CS.Arizona.EDU!buckie.ucha!buckie.nntp!DWING Message-ID: <1993Dec14.151249.506@buckie.hsc.colorado.edu> Reply-To: dwing@uh01.Colorado.EDU References: <2eeffe$61g@ctsc.hkbc.hk> Organization: Ski Bum Wanna-be, Incorporated Nntp-Posting-Host: buckie.hsc.colorado.edu Date: 14 Dec 1993 15:12:49 MDT From: dwing@uh01.Colorado.EDU (Dan Wing) Subject: Re: How to connect to LAT services from vms In article <2eeffe$61g@ctsc.hkbc.hk>, s11976@ctsc.hkbc.hk (PM Wong) writes: >I understand that from 5.4-1 onwards, set host have the option /lat >so that one can use LAT services (like dial-out modem, non-VMS hosts that >are connected to DECSERVER ports) >But we are still using VMS 5.4. Can someone tell me is there an alternate >way to do so. >Thanks in advance. >Email please as I seldom read this newsgroup This is *not* a feature of VMS V5.4. It is a feature of LAT V5.2, commonly called "LATmaster", which, as of VMS V5.4-?, is optionally installable. The versions of LATmaster included with VMS V5.4-0 through V5.4-2 were quite bad, and V5.4-3 was supposedly relatively good. You do not need to be running VMS V5.4-3 to install LAT V5.2 (although VMS V5.4 or higher may be required, which you have). You can get LATmaster from the VMS V5.4-3 installation kit (there is information on how to install the optional LATmaster software included somewhere). Also, you'll want to install CSC Patch #511, which fixes several bugs with the "old" LAT (LAT V5.1, which is the LAT prior to LATmaster) and to LATmaster. LATmaster (LAT V5.2) is the LAT supplied with VMS V5.5 (and A5.5), and is no longer optional. -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.os.vms Path: cs.utk.edu!gatech!swrinde!network.ucsd.edu!mvb.saic.com!info-vax Message-ID: <18789679@MVB.SAIC.COM> Organization: Info-Vax<==>Comp.Os.Vms Gateway X-Gateway-Source-Info: Mailing List Date: Sat, 25 Dec 1993 09:19:50 EDT From: Jerry Leichter Subject: RE: LAT | Does anyone know where I might be able to find out information on the | LAT protocol? Any little bit will help, including source code | examples in any language. I don't have a specific application for | it, I was just trying to compile as much information on it as I can | right now, just for the sake of knowing... LAT is a DEC-proprietary protocol, parts of which are patented, and little information about it has been published anywhere. (You can, of course, always get copies of the patents, which in theory contain all the information you need to produce an equivalent implementation (according to law!), but in practice the way patents are written makes this a pointless exercise.) DEC will be glad to *sell* you a great deal of information about LAT, but I don't think you'd want to spend the money. Before DEC announced its patents and licensing program, many independent terminal server vendors reverse-engineered the protocol. Given the effort involved, I doubt any of them would want to share the results, and in any case I think they've all now signed on with DEC, so would probably be legally prevented from telling you much anyway. Protocol analyzer manufacturers have also reverse-engineered the protocol, at least to some degree. You can often learn a lot from the displays a good protocol analyzer generates. There are a number of really clever ideas in LAT, and it's too bad DEC didn't make them much more widely available, and earlier: It really is a much better protocol for connecting terminals over a LAN than TELNET, but because of the way DEC chose to treat it, implementations of the host end on non-DEC systems are virtually unknown. If DEC had helped anyone who wanted to build host implementations for nominal cost, they might have sold more terminal servers, or at least made more royalties from other server manufacturer's use of LAT. -- Jerry ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.os.vms Path: cs.utk.edu!emory!europa.eng.gtefsd.com!MathWorks.Com!news.duke.edu !news-feed-1.peachnet.edu!umn.edu!mayonews.mayo.edu!usenet Organization: Mayo Foundation Lines: 40 Distribution: world Message-ID: <2p6gf4$n81@fermat.mayo.edu> References: <2ovat9$6mk@sndsu1.sinet.slb.com> Reply-To: brunkhorst.geoffrey@mayo.edu NNTP-Posting-Host: tarski.mayo.edu Date: 21 Apr 1994 18:25:40 GMT From: brunkhorst@mayo.edu Subject: Re: RE: Dump DECnet for TCP/IP? In article <2ovat9$6mk@sndsu1.sinet.slb.com> brydon@dsnvx2.tulsa.dowell.slb.com (Harvey Brydon (918)250-4312) writes: [...Generally, a good comparison of LAT and Telnet omitted] > LAT works 'out of the can'. Telnet takes a > considerable amount of configuration, bookeeping and ongoing maintenance. > TCP/IP has a hard limit of number of systems on a network, then you have to > back off and reassign all your numbers again in a larger subnet. LAT has > no practical addressing limit. If you chose TCP/IP, be prepared for more > maintenance activity than LAT/DECnet. > You can be prepared, but you may be like us and be pleasantly surprised at how easy it is. Our Xyplex systems provide both IP and LAT, and LAT and TCP give us about equal pain when installing. The hard limit is a local IP management concern, and not a global damnation of how TCP/IP can work. LAT does just plug and play in any environment, except where routers exist, and herein lies the hidden LAT cost. Telnet/IP 'just works' (if installed by trained professionals;-) in a routed environment, arguably a better thing in a broadly distributed enterprise network. One thing of note. LAT is much more unstable on an unstable Ethernet. Telnet and the underlying TCP/IP better withstand the buffeting of a very busy or 'unclean' ethernet environment. The TCP overhead is there for a purpose, and robust retransmission is one of them. If the ack timeout is reached, LAT will roll over and die, bringing all sessions on a virtual circuit down with it (a case where multiplexing a LAT circuit is NOT good). I have two ethernets in my facility where I have had to retrain my users to use the TELNET option on the terminal server to avoid these bumps. --- Geoff ____________________________________________________________________________ Geoffrey Brunkhorst Brunkhorst.Geoffrey@Mayo.edu Research Computing Facility, Guggenheim 10 (507) 284-1805 Mayo Foundation, Rochester MN, 55905, USA fax (507) 284-5231 ////////////////////////////////////////////////////////////////////////////// Newsgroups: vmsnet.networks.desktop.pathworks,vmsnet.networks.misc Path: cs.utk.edu!gatech!swrinde!elroy.jpl.nasa.gov!ames!tgv.com!WING Message-ID: <2pkue6$l7d@news.arc.nasa.gov> References: NNTP-Posting-Host: hq.tgv.com Organization: TGV, Incorporated Date: 27 Apr 1994 05:49:57 GMT From: wing@tgv.com (Dan Wing) Subject: Re: LAT for free??? In article , cjb@hmm.com (Chris Baldwin) writes: > >Now that Pathworks V5 is here and seems to be working well, we are thinking >about migrating all of our Windows 3.1 users to WFG 3.11 to take advantage of >the NETBEUI protocol. This means that we could potentially eliminate DECnet >from all PC's. ( 90% of our users use file and print services only ). >We do have users that need LAT access though. If we remove Pathworks for DOS >client software, we would then nolonger have the LAT.EXE file. > >Is there a LAT.EXE file available that I can get to replace the one that >comes with Pathworks for DOS? I am hearing that there may be licensing >issues and that I can only get it from DIGITAL. Is this correct? Digital licenses LAT. Meridian Technologies does almost all of the LAT implementations, though, including those in the DECserver 700, the PC implementation that you have, almost all 3rd party terminal servers, and a lot of other products. (Digital licenses Meridian to do this). There are two other companies that I'm aware of, "Ki Research" and "Thursby Software", which sell implementations of LAT for PCs, Macs, Unix machines, and other platforms. I believe they license their implementations from Digital and/or Meridian. Although it has been explained to me several times, I've never fully comprehended the association between Digital doing the design work with LAT (and the development and improvement of the protocol itself) and Meridian Technologies. -Dan Wing, wing@tgv.com ////////////////////////////////////////////////////////////////////////////// Newsgroups: vmsnet.networks.desktop.pathworks,vmsnet.networks.misc Path: cs.utk.edu!emory!swrinde!elroy.jpl.nasa.gov!ames!decwrl!pa.dec.com !nntpd2.cxo.dec.com!nntpd.lkg.dec.com!ranger.enet.dec.com!backstrom Organization: Digital Equipment Corporation Message-ID: <2pmi4f$qsh@nntpd.lkg.dec.com> References: NNTP-Posting-Host: tooter.enet.dec.com X-Posted-via: NEWS-NOTES gateway (a hack!) X-NN_Ref: 400005BC ECA3C434 0097D972 Date: 27 APR 1994 16:32:14 From: backstrom@ranger.enet.dec.com (ranger::backstrom) Subject: Re: LAT for free??? > "wing@tgv.com (Dan Wing)" > Re: LAT for free??? > >Digital licenses LAT. Meridian Technologies does almost all of the LAT >implementations, though, including those in the DECserver 700, the PC >implementation that you have, almost all 3rd party terminal servers, and a lot >of other products. (Digital licenses Meridian to do this). There are two Just to correct one nit... Meridian, indeed, licenses (among some other companies) LAT from Digital and maybe even writes/maintains some implementations for some Digital products, but the LAT transport in the PATHWORKS client Meridian has nothing to do with; it has been entirely developed by PATHWORKS engineering, and is also maintained by PATHWORKS engineering (and the maintainer also hangs out on this list ;-). ...petri (petri.backstrom@lkg.mts.dec.com) Personal Computing Integration Engineering Digital Equipment Corporation ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.os.vms Path: cs.utk.edu!emory!swrinde!sdd.hp.com!decwrl!pa.dec.com!src.dec.com !crl.dec.com!nntpd.lkg.dec.com!ryn.mro.dec.com!hannah.enet.dec.com!raspuzzi Message-ID: Sender: news@ryn.mro.dec.com (USENET News System) Organization: Digital Equipment Corporation References: <2p1u9s$n8@search01.news.aol.com> <2p2gir$5hp@news.arc.nasa.gov> Date: Sat, 23 Apr 1994 21:59:14 GMT From: raspuzzi@hannah.enet.dec.com (Michael D. Raspuzzi) Subject: Re: LATACP's WSEXTENT - performance impact? In article <2p2gir$5hp@news.arc.nasa.gov>, wing@tgv.com (Dan Wing) writes... > >In article <2p1u9s$n8@search01.news.aol.com>, finarfin@aol.com (Finarfin) writes: >> >>DECps is telling me that LATACP has a high pagefault rate and could use >>a larger WSEXTENT. This prompts me to ask whether a hight pagefault >>rate for LATACP could have any impact on LAT performance, such as >>causing an unusually high number of LAT retransmits and/or duplicates >>received, or any other significant performance impact. As previsouly pointed out, LATACP is not involved in the actual part of LAT messaging. So, it should not impact retransmits or duplicates received. However, if you feel that you need to adjust some of LATACP's process quota, you can through some logical names. Similar to NETACP, LATACP's run command in LAT$CONFIG looks for the following logical names: LATACP$MAXIMUM_WORKING_SET LATACP$PAGE_FILE LATACP$EXTENT <-- Should change WSEXTENT LATACP$ENQUEUE_LIMIT LATACP$BUFFER_LIMIT If you feel the process needs different parameters then the defaults used in LAT startup, feel free to define those logical names (DEFINE /SYSTEM) before you execute LAT startup (SYLOGICALS.COM may be a good place for this). >Absolutely not. LATACP isn't used for incoming LAT connections -- to prove >it to yourself, kill it. LATACP is the process that collects LAT Well, you can try to kill it ;-). STOP /ID does not work on LATACP because it has the NODELETE bit set in its PCB. Unfortunately, you can suspend LATACP but that should be fixed in OpenVMS VAX & AXP V6.1. Suspending LATACP is not a good idea... Also, while LATACP's main function is to maintain the service and node database for outgoing LAT connections, it does a couple of other things that are related to the protocol but are not performance critical. For example, one of LATACP's function is to validate an incoming LAT connection for the VMS system. It checks to make sure the node offers the specified service, validates group codes in the LAT start slot (start slots are used to start a session) and it is responsible for determining a reject reason if one is necessary. In effect, you cannot run LAT on your system without LATACP (therefore, when it is started, it sets itself NODELETE) otherwise, you wouldn't be able to connect to your VMS system from a remote node (terminal server or SET HOST /LAT from another VMS system). >High numbers (over DEC's 1/1000 rule) of Retransmits or Duplicates Received >are usually indicative of a poor network -- too many bridges, or slow bridges, >or too much traffic on the network (too many collisions) -- which are causing >or otherwise contributing to causing LAT's 1 second wait-for-an-ACK timer to >fire. Yes. > >My guess as to why LATACP might be faulting heavily is you may have: > > o a lot of LAT service advertisements (like from a lot of LAT hosts, or > from terminal servers advertising their services) > o your LAT "advertisement" timer (whatever it is called) set too low, > causing too much information to be sent all over the network > o a lot of users using SET HOST/LAT from your system, causing stuff that > was paged out of LATACP's working set to get paged back in (which would > happen for either of the two situations above) Each point is a possibility as well. Another of LATACP's function is to handle Solicit Information messages that are present when a service requestor is on the network. An example of a service requestor is a VXT 2000 or a DS90L+. These components do not build a LAT service/node database and rely on responses from those nodes that do keep a service and node database (called service responders). If you think LATACP's database is too big, you can set a node limit to try and keep the size of the database down. With OpenVMS VAX & AXP V6.1, if you set a node limit and someone does a SET HOST /LAT to a service that LATACP does not have in its database, it will use the same service requestor mechanism that the VXT 2000 and DS90L+ use. In fact, the VXT 2000's LAT implementation is pretty much the same as OpenVMS and the Infoserver (they all are based on the same code base) but I digress... In OpenVMS AXP V6.1, there is a new command in LATCP - SHOW NODE /STATUS that is similar to the SHOW SERVER STATUS display on the DECserver. You might see something like this: Node Name: LAT_DEVO LAT Protocol Version: 5.2 Node State: On Node Ident: LAT development system Current Highest Maximum ------- ------- ------- Active Circuits: 2 3 1023 Connected Sessions: 17 19 260865 Incoming Queue Entries: 0 0 24 Outgoing Queue Entries: 0 1 32767 Unprocessed Announcements: 1 57 500 Unprocessed Solicits: 0 8 250 Local Services: 2 2 255 Available Services: 505 510 N/A Reachable Nodes: 490 499 1000 Discarded Nodes: 0 The display will (hopefully) aid in getting an idea of how big the LAT service and node database is on your system. This is not available in OpenVMS VAX V6.1 but will be on the VAX platform in the release following V6.1. Mike Raspuzzi (raspuzzi@mrlat.enet.dec.com) Digital Equipment Corporation ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.os.vms Path: cs.utk.edu!emory!swrinde!ihnp4.ucsd.edu!mvb.saic.com!info-vax Message-ID: <9404241239.AA20433@uu3.psi.com> Organization: Info-Vax<==>Comp.Os.Vms Gateway X-Gateway-Source-Info: Mailing List Date: Sun, 24 Apr 94 08:26:44 EDT From: Jerry Leichter Subject: RE: XON/XOFF program thru LAT overruns my device Lines: 100 I'm having a problem with a program that does file transfers using an XON/XOFF protocol. The way the download is supposed to happen is this: - The machine that will receive the file sends an XON to signal that it is ready - The host (VAX talking through DEC terminal server) starts sending the file - When the receiving machine fills up with data, it sends an XOFF. - The host stops sending IMMEDIATELY (within 2-15 characters) - When the receiving machine is ready, it sends an XON and the host picks up where it left off. That's how it's supposed to work. In fact, I've had no problem doing this from the TT port on the back of my station. Unfortunately, when I connect using an LTA, the data from the host overflows the receiving machine by 200+ characters. Can anyone suggest how I can get this done? Colorado swears that this is possible but has been unable to help. The code is pretty long and would be hard to cut down, but I'd be happy to provide it on request. My original theory was to disable flow control on the LAT port and then use SETMODE qios to turn off TT$_TTSYNC and turn on TT$_PASSTHRU. I then wait for the XON. This part works just fine. Once the XON is received, I then turn on TTSYNC with the idea that the LAT will then take over handling of flow control. My support person in Colorado says that the TTSYNC setting should be passed on to the LAT. This doesn't seem to happen. I believe that the terminal driver is handling the flow control instead of the LAT, which leads to the overrun. a) You have little hope of doing your own XON/XOFF handling, with the kind of timing constraints you are talking about, through a LAT link. LAT is designed to save bandwidth with holding off on how often it transmits. When characters arrive from the terminal, they are simply placed in a local buffer; their arrival doesn't trigger an attempt to send down the link. Instead, every 80ms the LAT server will check the buffer and try to send any characters. At the VAX end, the same thing will happen. You you're *average* case round- trip delay is 80ms or so - about 80 character times on a 9600 bps line - even before you count in processing time at the two systems. Your worst case minimum delay is twice as long. The "80ms" time is a parameter - the circuit timer - which at least in some implementations is settable. However, it's not clear to me that you could set it low enough to match your constraints. Of course, that depends on the line speed, which you haven't told us. However, since you are currently seeing what are apparently typical overruns in the 200+ character range, I doubt you could make this work. b) LAT implementations *do* pass the TTSYNC setting through to the server. Many older terminals would not have sufficient buffering to deal with the delay of processing XOFF at the host. It's possible that you've managed to get your system set up in a way that disables this, but I doubt it. c) I suspect the real origin of your problem is that you are *changing* the TTSYNC setting. This takes time: The mode change packet has to be sent to the server (with the usual up-to-80ms delay), then it has to be acted on. It's not clear to me that these actions are necessarily done in-line with data transmission, nor whether the server can necessarily respond to a change mode request on a busy line - it may put it off to a more quiet time to avoid internal synchronization problems. TTSYNC and similar settings are normally viewed by implementors as mainly "set and forget" kinds of things, which are changed on timescales on the order of minutes, not milliseconds. Optimizing their performance is seen (rightly) as a waste of time. I think you're lucky this works with a direct-connected terminal line! I suspect the only way you're going to meet your specs is to leave TTSYNC on all the time. If you use QIO's rather than QIOW's, VMS will automatically resume sending when the receiver is ready, and your program can go on to do other things (like perhaps queue up more output). It can, of course, check to see whether previous I/O's have completed, or be informed by AST when they do. The limitation is that the program would have no way of being informed of the arrival of an XON when it was not trying to send data. You don't describe the protocol in sufficient detail for me to tell if that's an issue for you, but I can't really imagine any other reason why you'd go to the trouble of turning TTSYNC off. There's really no good solution if this is the case. The best I can suggest is to see if there is some kind of no-op you can safely send the receiver - perhaps a NUL character. Then ensure that there is ALWAYS data - even if a no-op - waiting to be sent when the line is XOFF'ed. When the receiver XON's the line, your pending I/O will complete, and you'll know you should proceed. d) Be aware that Ethernet packets do get delayed and lost. The LAT protocol will eventually re-transmit lost packets, but the timeout involved is very long: By default, 1 second. On some implementations, you may be able to lower this, but probably not by very much. Be *sure* that what you are doing can survive the occassional 1-second delay. (You mentioned in one follow-up note that the receivers were numerically controlled machines. If you're trying to control motion - most especially if it's stopping motion for safety reasons - over this link: Forget the idea of using LAT. It's just not suited for this purpose. -- Jerry (Who built systems such as you are working on many years ago, on RSTS, in BASIC PLUS! Fortunately, we could specify the protocol on the wire.) ////////////////////////////////////////////////////////////////////////////// [a posting from the famous keeper of the Eternal Flame] Newsgroups: comp.os.vms Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!nntp-server.caltech.edu !SOL1.GPS.CALTECH.EDU!CARL Distribution: world Message-ID: <3hdhpk$ek9@gap.cco.caltech.edu> References: <1995Feb6.162657.22899@vtf.idx.com> Reply-To: carl@SOL1.GPS.CALTECH.EDU NNTP-Posting-Host: sol1.gps.caltech.edu Organization: HST Wide Field/Planetary Camera Date: 9 Feb 1995 17:01:40 GMT From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) Subject: Re: Help unspooling a device In article <1995Feb6.162657.22899@vtf.idx.com>, mangaldas@idx.com (Rahul K. Mangaldas) writes: = =I'm trying to perform a SET DEVICE/NOSPOOL on a LAT port; =however, I keep getting an error saying that the device has a =channel assigned. I've already stopped all known queues on this =port and removed it from the Pathworks shared queues. What else =can be pointing to this device? How can I find out what process =has an open channel to this device? Well, you can try: $ SHOW DEVICE/FULL LTAx That should show you the process that owns the device. Or you could use SDA, via the command $ ANALYZE/SYSTEM Once within SDA, issue the command: SDA> SHOW DEV LTAx One of the things it will show you is the PID of the process that owns the device. You can then use this in the command: SDA> SHOW PROCESS/INDEX=pid This will, in turn, give you the Extended PID of the process. You can now exit from SDA, and use the extended PID in the DCL command: $ SHOW PROCESS/ID=pid -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. [ARCHIVIST'S NOTE: See Vance Haemmerle's memorial: http://alumni.caltech.edu/~vance/carl_lydick.html ] ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.protocols.tcp-ip Path: stc06.ctd.ornl.gov!news.er.usgs.gov!jobone!newsxfer3.itd.umich.edu !howland.erols .net!news2.digex.net!news6.digex.net!news.switch.com!jcring Message-ID: <5nh0t4$dsc$1@news.switch.com> References: <339B9DAA.1453@mbnet.mb.ca> NNTP-Posting-Host: dhcp210-172-16-2.switch.com X-Newsreader: News Xpress 2.01 Organization: Union Switch & Signal Inc. Date: Mon, 09 Jun 1997 13:36:41 GMT From: "John C. Ring, Jr." Subject: Re: Replacing DEC Lat with Telnet In article <339B9DAA.1453@mbnet.mb.ca>, collier@mbnet.mb.ca wrote: > > Has anyone measured the effect of replacing DEC Lat with Telnet over > a 56kb WAN? Nitpick: LAT is more than simply a protocol for terminal sessions; the question should be "replacing LAT with TCP/IP". > What are the arguments for replacing LAT with Telnet? The original design for LAT was that it's a (L)ocal (A)rea (T)transport, while TCP/IP was designed to be used in WANs. One argument to remove LAT is to reduce the number of protocols being supported by your networking staff, thus reducing the complexity of your router configurations, and other networking devices. The other main reason is that LAT was designed, being targeted for LANs, with a hardcoded limit on "latency". I can't remember the precise limit, "latency" described it fairly well :). If your link begins to exceed the limit, which if my memory serves me correctly is two seconds, you will begin to see dropped LAT sessions. If you're looking at doing it for the later reason, you should also note that the MOP protocol that DEC uses to remote boot it's terminal servers also, I believe, suffers from a built-in latency limit. So, you'll want to address that, either by having a MOP server on each LAN, or configuring your terminal servers to boot via TFTP. ----------------- John C. Ring, Jr. jcring@switch.com Network Specialist ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.os.vms Message-ID: References: Organization: SeaChange Systems, Inc. Date: Wed, 19 May 1999 10:20:43 -0400 From: Michael Raspuzzi Subject: Re: LAT question. Daniel Seagraves wrote in message news:Pine.LNX.4.10.9905181448420.16833-100000@bony.umtec.com... > > I'm trying to make a LAT port, so I can type "SET HOST/DTE LTA420:" on > my VAX and get a LAT connection to our Digital UNIX box. I made a LAT > service for it on the UNIX, and I can say "SET HOST/LAT UBANI" and enter > the service, and I get a login prompt (which is what I want). But when I > enter "SET HOST/DTE LTA420:" I get this: > > %REM-E-PORTRXERR, port recieve error > -SYSTEM-F-HANGUP, data set hang-up > > Any ideas? I did "CREATE PORT LTA420:" and "SET PORT LTA420: /APPLICATION > /NODE=UBANI /SERVICE=UUCP_PORT" to create the port, can anyone spot my > mistake? > SET HOST /DTE to an LTA device is not the preferred way to get to another host system (SET HOST/LAT is.). When you use SET HOST /DTE, the LAT device driver on the OpenVMS system will attempt to make a "host initiated" connection to the destination based on how you mapped the LTA device. This typically works with DECservers and other terminal servers because the DECserver supports host initiated connections (same connect methodology used for printers). However, other host LAT systems (like OpenVMS and Unix) may not support incoming host initiated connections. Most of the host initiated connect logic was implemented on OpenVMS so you might be able to get away with SET HOST /DTE if the LTA device is mapped to another OpenVMS system (well, it is mostly implemented - I had done quite a bit of debug before leaving Digital). Mike Raspuzzi Former OpenVMS LAT developer ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.os.vms NNTP-Posting-Host: 194.78.73.6 NNTP-Posting-Date: Thu, 20 Nov 2003 10:25:52 +0000 (UTC) References: Message-ID: Organization: http://groups.google.com Date: 20 Nov 2003 02:25:52 -0800 From: Bart Zorn Subject: Re: lat for linux problem > "John Forkosh" schreef in bericht > news:bpg37f$md8$1@reader2.panix.com... > > Not sure if this is the right group, but anybody here use Lat for Linux, > > http://linux-decnet.sourceforge.net/lat.html > > I have a small 10base2 lan with some Linux PC's, some genuine > > VMS VAXstations, and a DECserver 90L+. The wires are okay since > > I can ping/telnet/ftp between the VS's and PC's, and can connect > > to the VS's from the 90L+. > > > > I also found out about the MAC address problem with the 90L+, i.e., > > it barfs on packets from non-Digital addresses, and have applied > > the linux fix > > ifconfig hw ether AA:00:04:00:0A:03 > > so the PC looks like a Digital address. And I'm also applying > > the extra lat-for-linux commands > > latcp -j > > latcp -x 100 -s -a psistar > > (where psistar is the name of the PC), though I'm not sure whether > > either is helpful in any way. > > > > And all this kind of works -- I can sometimes c psistar from the > > 90L+ and log on to the PC. Works fine when it works at all. > > > > Problem is it always takes a _long_ time (90L+ prints lots > > of ...'s before I ever get a prompt) before connecting, and the > > 90L+ frequently just gives up with "service unavailable". > > But if I do manage to connect and then later logout/exit, I can > > always establish a new PC connection almost instantly. > > The VS's always connect almost instantly. > > > > What might be wrong, and what can I do to fix it or tune it > > or whatever? Thanks, > > -- > > John Forkosh ( mailto: j@f.com where j=john and f=forkosh ) "H Vlems" wrote in message news:... > John, > > not sure whether it is the cause for your problem but is aa-00-04-00-0a-03 a > valid DECnet address? > IIRC one takes tha last two bytes and reverse them. The leading 6 bits > designate area, the trailing 10 designate the node. > 0a-03 -> 03-0A -> 0000 00 11 0000 10 10 > --------- ========== > That's 0.778 which is invalid, right ? > > BTW I use LAT for linux (RedHat 9) without any problems, like Roland the > server is started with defaults. > > Hans LAT has nothing to do with DECnet (and vice versa). If the Linux box is not running DECnet, there is no need to change it's MAC address. If the Linux box does have a DECnet implementation, then that implementation will take care of the proper MAC address setting. This does not explain your problem, however, and I am afraid that I cannot help you there. -- Bart Zorn ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.os.vms Path: utkcs2!emory!gatech!rutgers!cbmvax!xmws!baxter Message-ID: <39.2722724c@xmws> References: Distribution: comp Organization: Xmws Associates, Phoenixville, PA Lines: 106 Date: 22 Oct 1990 08:15:08 GMT From: baxter@xmws Subject: Re: Dedicated LAT-service doesn't break connection on port close. In article , rcbatg@rw7.urc.tue.nl (Tonnie Geraets) writes: > > Hello, > > I'm writing a dialin-server, which has to run as a dedicated LAT-service on > a VMS-system. > > Everything works ok, without any error values returned. The only thing that > doesn't work: when I close the port, the user isn't disconnected, but the > program just waits for a cariage return and starts over again. > > Examples of working dedicated LAT-services are also welcome (for example the > TIME-service described in the manual). > You need to make sure the LAT port itself is setup to log off the user when you drop the connection... If you set the LAT PORT to modem control and set the modem to drop carrier and reset whe DTR is DROPPED, it will worng correctly... Several other things I noticed: After you open the port you need to issue a LAT connect request QIO: sys$qiow( write_QIO_efn, channel, (IO$_TTY_PORT | IO$M_LT_CONNECT), &iosb, 0, 0, 0, 0, 0, 0, 0, 0 ); if ( even( iosb.condition )) do_lat_open_error( iosb ); I also noticed that you have not enabled a control_y ast handler on the channel so that you will get hangup notification... (if the NETWORK connection is broken for some reason... or the LAT is rebooted: rs = sys$qiow( write_QIO_efn, channel, (IO$_SETMODE | IO$M_CTRLYAST), &iosb, 0, 0, hangup_ast, 0, 0, 0, 0, 0 ); if ( even(rs) || even(iosb.condition) ) do_lat_open_error( iosb ); What follows is a LAT programming example from DEC: (Constants contain within ARE NOT sys$library... at least on vms 5.3-1) #include descrip #include iodef /* #ifndef IO$_TTY_PORT */ /* define the next bunch here, if they don't appear in IODEF */ #define IO$_TTY_PORT 41 #define IO$M_LT_MAP_PORT 512 #define IO$V_LT_MAP_NODNAM 1 /* use IO$V_ not IO$M_ */ #define IO$V_LT_MAP_PORNAM 2 #define IO$V_LT_MAP_SRVNAM 3 #define IO$V_LT_MAP_LNKNAM 4 #define IO$V_LT_MAP_NETADR 5 /* #endif */ /* set up some useful structures */ struct IOSB { short unsigned int status, unused; unsigned int reserved; }; struct ITMLST { short unsigned int buffer_length, item_code; char *buffer_address; unsigned int *return_length_address; }; main(){ unsigned int status, q = 1; short unsigned int lat_io_channel; char *srvr_name = "TRMSVR", *port_name = "PORT_2", *link_name = "LAT$LINK"; /* it MUST be this name */ struct IOSB iosb; struct ITMLST itmlst[] = { { strlen( link_name ), IO$V_LT_MAP_LNKNAM, link_name, 0 }, { strlen( srvr_name ), IO$V_LT_MAP_NODNAM, srvr_name, 0 }, { strlen( port_name ), IO$V_LT_MAP_PORNAM, port_name, 0 }, { 0, 0, 0, 0 } }; static $DESCRIPTOR( lat_device, "_LTA9995:" ); if( !( ( status = sys$assign( &lat_device, &lat_io_channel, 0, 0 ) ) & 1 ) ) lib$stop( status ); if( !( ( status = sys$qiow( 0, lat_io_channel, IO$_TTY_PORT | IO$M_LT_MAP_PORT, &iosb, 0, 0, &itmlst, q, 0, 0, 0, 0 ) ) & 1 ) ) lib$stop( status ); if( !( iosb.status & 1 ) ) lib$stop( status ); sys$dassgn( lat_io_channel ); printf( "Lat port: %s, mapped to Server: %s, Port: %s\n", lat_device.dsc$a_pointer, srvr_name, port_name ); printf( "Server port is %s queued\n", q & 1 ? "" : "not" ); } ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.os.vms Path: utkcs2!emory!wuarchive!decwrl!elroy.jpl.nasa.gov!zardoz.cpd.com!dpdvax !potter Message-ID: <224.2725be78@dpdvax.uucp> References: Lines: 61 Distribution: comp Organization: Data Processing Design, Anaheim CA Date: 27 Oct 1990 07:31:28 GMT From: potter@dpdvax.uucp Subject: Re: Dedicated LAT-service doesn't break connection on port close. In article , rcbatg@rw7.urc.tue.nl (Tonnie Geraets) writes: > Hello, > > I'm writing a dialin-server, which has to run as a dedicated LAT-service on > a VMS-system. > I followed all the steps described in the I/o manual, section 8.4.4.2 > (Terminal Driver, LAT port driver QIO interface, Application Services Creation): > > The network manager defined the LTA-port as a dedicated service. > > In the program (writen in C) I do the following: > > - open the port: > sys$alloc(&port_descrip,0,0,0,0); > sys$assign(&port_descrip, &terminal_chan, 0, 0); > (of course after initializing things such as descriptors etc., and with the > necessary error checking) > > - wait for a connection: > func = IO$_READLBLK | IO$M_TIMED | IO$M_NOECHO | IO$M_PURGE; > sys$qiow(0, terminal_chan, func, &iosb, 0, 0, > readbuf, MAX_LINE_LENGTH, timeout_value, 0, 0, 0); > > - handle all the users whishes. > > - close the connection: > sys$dassgn(terminal_chan); > sys$dalloc(&port_descrip, 0); > > - start again with opening the port. > What you need to do is look one section back -- section 8.4.4.1. That section discusses I/O functions for connecting to and disconnecting from a LAT port. You need to do something like this to connect: sys$qiow(0, terminal_chan, IO$_TTY_PORT | IO$M_LT_CONNECT, ... ) and like this to disconnect when you are all done: sys$qiow(0, terminal_chan, IO$_TTY_PORT | IO$M_LT_DISCON, ... ) This gives you finer control over the LAT device. One thing to beware of is that if the device connected to the LAT port leaves data waiting for it in the terminal server without reading it, a disconnect from the host will cause the port to go into a disconnecting state, but the connection will not actually be dropped until either the data is read out of the terminal server port buffer, or the port is logged out. > Tonnie Geraets, rcbatg@urc.tue.nl > rcgbbatg@heitue51.bitnet > Eindhoven University of Technology, The Netherlands. Hope this helps. David -- David Potter Voice: (714) 970-1515 Data Processing Design UUCP: {lawnet,zardoz,dhw68k}!dpdvax!potter Anaheim, CA Internet: potter@dpdvax.uucp //////////////////////////////////////////////////////////////////////////////