<<< SHAVE::DECUS:[DECUSERVE]RT_11.NOTE;1 >>> -< RT_11 >- ================================================================================ Note 1.0 Welcome to the RT_11 conference No replies EISNER::DELARISCH "Arnold S. De Larisch" 6 lines 28-JAN-1988 17:46 -------------------------------------------------------------------------------- This conference covers questions and comments about the RT-11 series of operating systems: RT-11, CTS-300, TSX, and related operating systems. Use this conference to report bugs, ask questions, and announce new discoveries.  ================================================================================ Note 2.0 This topic reserved for future internal directory No replies EISNER::DELARISCH "Arnold S. De Larisch" 2 lines 28-JAN-1988 17:46 -------------------------------------------------------------------------------- The most current internal directory for this conference will be posted as responses to this topic.  ================================================================================ Note 3.0 This topic reserved for future use by the moderator No replies EISNER::DELARISCH "Arnold S. De Larisch" 2 lines 28-JAN-1988 17:46 -------------------------------------------------------------------------------- The most current information concerning moderation will be posted as responses to this topic.  ================================================================================ Note 4.0 This topic reserved for future use by the moderator No replies EISNER::DELARISCH "Arnold S. De Larisch" 1 line 28-JAN-1988 17:46 -------------------------------------------------------------------------------- Additional note for moderators  ================================================================================ Note 5.0 Using Ethernet with TSX+ 2 replies EISNER::KOZAM 22 lines 29-JAN-1988 02:44 -------------------------------------------------------------------------------- Is anyone out there using Ethernet with TSX+? Home brew software or prepackaged? How does it work/is it worth the cost? I'm particularly interested in the following: 1. DECnet compatability 2. Ability to have diskless TSX+ systems, possibly getting data from another TSX+ system or (even better) a VMS system. 3. LAT for terminals using TSX+ (reverse-LAT doesn't count!) I know people do #1, but don't know about vendors or performance. I think #2 should be possible, but would require a special bootable ethernet handler (and type-in bootstrap'), plus "server" software for whatever system will be supplying disk blocks. I suspect that #3 is impossible, due to the fact that TSX+ keeps terminal handling code well inside the system. Marc Kozam ================================================================================ Note 5.1 Using Ethernet with TSX+ 1 of 2 EISNER::CAMPBELL 25 lines 22-APR-1989 14:31 -< Some options >- -------------------------------------------------------------------------------- > 1. DECnet compatability As far as I know, there is no DECnet compatible software for TSX+. Even the RT-11 product (which I think has been retired) is/was relatively useless in a modern network environment. > 2. Ability to have diskless TSX+ systems, possibly getting > data from another TSX+ system or (even better) a VMS system. There are several vendors that provide "remote disk" service over Ethernet to RT-11 and TSX+ nodes. The ones I can think of are Etherdisk from Omnex and TPserve from Hammondsoftware (through Serdula International in Ontario). A third one is called Iranet, but I can't remember the name of the company (in Santa Monica, CA) makes it. Process Software has a TCP/IP product for RT-11 and TSX+. > 3. LAT for terminals using TSX+ (reverse-LAT doesn't count!) > > ... I suspect that #3 is > impossible, due to the fact that TSX+ keeps terminal handling code well > inside the system. Actually,the hard part here is probably the LAT protocol (of which I know nothing). While not supported by S&H, pretending to be a TSX+ terminal with foreign equipment is do-able. ================================================================================ Note 5.2 Using Ethernet with TSX+ 2 of 2 EISNER::BILLING 8 lines 24-JUL-1989 14:29 -< Using Ethernet with TSX+ and TCP/IP >- -------------------------------------------------------------------------------- Marc, See RT note 14 where similar questions are being asked specifically about TCP/IP Ethernet software. Something I forgot to mention there about the FTP package is that it is DECnet compatible. You have to see Process Software for information. Also I didn't mention there, but I think EtherNet/EtherDisk products are TSX+ compatible.  ================================================================================ Note 6.0 v5.4 LS: won't work with DLV11-E No replies EISNER::FRISBIE "Alan E. Frisbie" 10 lines 29-JAN-1988 12:09 -------------------------------------------------------------------------------- I am having a problem with the RT-11 v5.4 (no update) LS: handler. I was given a possible fix at the European DECUS symposium in Rome, but have since lost it. Under v5.2, I can use the LS: handler with a DLV11-E serial board and have no problems. Under v5.4, I can't even INStall the handler. Anyone know what the problem is and if it is fixed in an update? Is there a patch for it? Alan  ================================================================================ Note 7.0 Need RT-11 PORTACALC... 1 reply EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" 8 lines 1-FEB-1988 13:21 -------------------------------------------------------------------------------- Anyone know if there is an RT-11 version of Glenn Everhart's PORTACALC ? If there is, where could I find it. I have a copy of all the SIG tapes ever made (I think). Bob ================================================================================ Note 7.1 Need RT-11 PORTACALC... 1 of 1 EISNER::HAHN 2 lines 1-FEB-1988 15:56 -------------------------------------------------------------------------------- As far as I know it only works under RSX for the PDP-11 however send a note to Glenn on DCS. Pierre  ================================================================================ Note 8.0 What about some Controversy! 14 replies EISNER::DELARISCH "Arnold S. De Larisch" 18 lines 4-FEB-1988 19:40 -------------------------------------------------------------------------------- O.k ... I see we have started off this conference to a slow ... but steady pace. I've got a question for all the RT-11 Folk. Since DEC has said VAXELN is the ONLY answer (must have been a very stupid question 8-{) ) to REAL TIME on a VAX ... do you think that this provides a Universal solution for YOUR problems? Will you be migrating all of your RT-11 systems to keep pace with DEC and the 32-Bit world? Will S&H's RT-32 program announcment take care of your 32-Bit needs? Inquiring minds want to know! -Arnold P.S. Did anyone get to go to the RT-32 BOF (Birds of a Feather) talk at the Anaheim Symposium??? ================================================================================ Note 8.1 What about some Controversy! 1 of 14 EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" 5 lines 5-FEB-1988 12:29 -< Real-time on a VAX is like speeding in a VW >- -------------------------------------------------------------------------------- Would someone enlighten me about what/who S&H are and what their RT-32 program is all about? I have missed most of the BOF's about RT-32 since DEC announced that it wasn't persuing it. ================================================================================ Note 8.2 What about some Controversy! 2 of 14 EISNER::DELARISCH "Arnold S. De Larisch" 17 lines 5-FEB-1988 17:33 -< The TSX People! >- -------------------------------------------------------------------------------- >> < Note 8.1 by EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" > >> -< Real-time on a VAX is like speeding in a VW >- >> Would someone enlighten me about what/who S&H are and what their >> RT-32 program is all about? I have missed most of the BOF's about >> RT-32 since DEC announced that it wasn't persuing it. S&H are the company who produces the TSX product. TSX, as I understand it, is a multi user version of RT-11. They got interested in the RT-32 project when DEC said "NO WAY". That's all I know about it ... anyone else have info??? -Arnold ================================================================================ Note 8.3 What about some Controversy! 3 of 14 EISNER::KILLEEN "Jeff Killeen" 4 lines 5-FEB-1988 18:08 -< STANDARD NOTE 101 >- -------------------------------------------------------------------------------- Just in case there is someone on this system who is associated S&H please read the commercialism gudeline that is posted in the DECUServe information conference. Please also be advised that you can comment under that guideline. ================================================================================ Note 8.4 What about some Controversy! 4 of 14 EISNER::FORBES "Bill Forbes - DAARC SIG Counterpart" 19 lines 9-FEB-1988 15:39 -< What about VMS? >- -------------------------------------------------------------------------------- Re: .0 > Since DEC has said VAXELN is the ONLY answer (must have been a very > stupid question 8-{) ) to REAL TIME on a VAX ... For the record, DEC (and many of it's customers) believes that VMS is a viable, indeed excellent, answer to realtime on a VAX, for certain realtime applications. That's what VAXlab is all about. That's what VAX/VMS-based flight simulators and other HPRT applications are all about. VAXELN is a superior realtime operating environment in many respects and forms an important part of DEC's realtime strategy. However, it is not "...the ONLY answer..." Bill Forbes Laboratory Data Products Group DAARC SIG Counterpart ================================================================================ Note 8.5 What about some Controversy! 5 of 14 EISNER::CETRON 18 lines 10-FEB-1988 00:14 -< Why push the vax? >- -------------------------------------------------------------------------------- re: .-1 Okay, if VAXELN is not the "...ONLY..." answer, what are the others? VMS is just plain too big for small quick and dirty applications, and sometimes operating system isn't even considered since 32bits and the cost of the system is well beyond what is needed. Doesn't anyone in digital remember the PDP-11??? You know, the business group within digital the size of coors beer was it? All we here is vax vax vax and I STILL can buy a MINC for 5K which can outperform the vaxlab at 40K in terms of ease of use, size, low overhead and speed up to 6Khz sampling, and with new dma boards could compete right up to 200Khz. -ed ================================================================================ Note 8.6 What about some Controversy! 6 of 14 EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" 1 line 10-FEB-1988 13:21 -< Here, here...I agree... >- -------------------------------------------------------------------------------- ================================================================================ Note 8.7 What about some Controversy! 7 of 14 EISNER::DELARISCH "Arnold S. De Larisch" 0 lines 10-FEB-1988 21:34 -< Me Three!!! >- -------------------------------------------------------------------------------- ================================================================================ Note 8.8 What about some Controversy! 8 of 14 EISNER::MCALLISTER "Brian McAllister" 7 lines 11-FEB-1988 18:58 -< Does ELN roll over and play dead? >- -------------------------------------------------------------------------------- Question for someone who knows VAXeln: Is it as cheerful as RT-11 when you try to throw it away so your program can have the machine to itself? What about stealing vectors and putting them back later? ================================================================================ Note 8.9 What about some Controversy! 9 of 14 EISNER::CAMPBELL 23 lines 22-APR-1989 14:44 -< Not with S&H, but know something >- -------------------------------------------------------------------------------- > Would someone enlighten me about what/who S&H are and what their > RT-32 program is all about? I have missed most of the BOF's about > RT-32 since DEC announced that it wasn't persuing it. As another note says, S&H are the makers of TSX+, which essentially provides multiple RT-11 background job environments on a single PDP-11. TSX+ includes a lot of extra "nice" things not found in basic RT-11. S&H has been working on what they call "TSX-32" for a long time, it is just recently entered field test for the first time. While S&H originally thought that TSX-32 would be VAX based, for various reasons they have implemented it for Intel 80386 based systesm (specifically the high-end IBM PS/2 and one or two others). While S&H has said that TSX-32 might be ported to other 32-bit machines at some point, it seems likely that either they will be successful with the '386 version, and therefore too busy to port, or they will be unsuccessful, and therefore too poor. While TSX-32 is supposed to include the real-time features of TSX+, of which there are some nice ones. Given the target machine, it may not be a good upgrade path, since it involves changing hardware, development tools, controllers and operating system vendors. ================================================================================ Note 8.10 What about some Controversy! 10 of 14 EISNER::KOZAM 10 lines 22-APR-1989 21:54 -< S & H Wisely Goes 80386 >- -------------------------------------------------------------------------------- > S&H originally thought that TSX-32 would be VAX based, for various > reasons they have implemented it for Intel 80386 based systems I think this is a good decision. Dollar for dollar, 80386 based products seem to be far more cost effective than VAX based product, unless you're held hostage by VMS. Now, I'd be really excited to see a Q-bus based 80386 board that ran TSX-32! (I recall some 86000 based products for the Q-bus, so this isn't so outrageous.) ================================================================================ Note 8.11 What about some Controversy! 11 of 14 EISNER::KENNEDY "Terry Kennedy" 15 lines 23-APR-1989 20:57 -< Comments on 386 systems >- -------------------------------------------------------------------------------- |> S&H originally thought that TSX-32 would be VAX based, for various |> reasons they have implemented it for Intel 80386 based systems Well, when you're playing 'bet the company' you have to take a long look at the pros and cons of your alternatives. The 386 does give them the ability to sell a *lot* of power at very low cost. > I think this is a good decision. Dollar for dollar, 80386 > based products seem to be far more cost effective than VAX based product, > unless you're held hostage by VMS. Having just come back from a 2-day trip to a major computer show, I can agree. A 386 motherboard with 1 Mb included, at 16 Mhz, was selling for $675 qty 1. Add a case, power supply for $100 more. Items like EPROM/PAL programmers sell for $70-$200. What more could you ask for? ================================================================================ Note 8.12 What about some Controversy! 12 of 14 EISNER::CROWELL "Shefth of the Fourth Order" 11 lines 24-APR-1989 10:32 -< Don't hold your breath >- -------------------------------------------------------------------------------- > While > S&H has said that TSX-32 might be ported to other 32-bit machines > at some point... I'd be very much surprised if S&H port their TSX-32 to anything once they've got it going on the PS2. They probably aren't as interested as you and I, Milt, in the real-time characteristics. Most of S&H's business is in the business/office-automation world. It would take a strong marketing message with visions of lots of sales to get them to port TSX-32 event to a Q-bus (or better yet, VMS bus) 80386 system. ================================================================================ Note 8.13 What about some Controversy! 13 of 14 EISNER::CAMPBELL 14 lines 29-APR-1989 19:35 -< Continuing to breath >- -------------------------------------------------------------------------------- > I'd be very much surprised if S&H port their TSX-32 to anything once > they've got it going on the PS2. They probably aren't as interested > as you and I, Milt, in the real-time characteristics. Most of S&H's > business is in the business/office-automation world. It would > take a strong marketing message with visions of lots of sales to > get them to port TSX-32 event to a Q-bus (or better yet, VMS bus) > 80386 system. I agree completely. But that is why TSX-32 may not be a potential place for RT-11 users to go. While I think it could be an upgrade path from TSX+, I have not yet figured out how to tell a current TSX+ customer that I want to change *everything* (hardware & software) just so I can upgrade him to TSX-32. Lacks a certain credibility. ================================================================================ Note 8.14 What about some Controversy! 14 of 14 EISNER::KOZAM 4 lines 1-MAY-1989 01:36 -< RT -> VAXELN v. RT -> TSX-32 >- -------------------------------------------------------------------------------- > Lacks a certain credibility. No more so than suggesting upgrading to a Microvax running VAXELN plus a separate VMS development system on the side!  ================================================================================ Note 9.0 Complain, complain... 1 reply EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" 5 lines 11-FEB-1988 13:13 -------------------------------------------------------------------------------- WHy is this conference RT_11 instead of RT-11 ? (Just trying to get activity going here). ================================================================================ Note 9.1 Complain, complain... 1 of 1 EISNER::DELARISCH "Arnold S. De Larisch" 22 lines 11-FEB-1988 14:28 -< Standards ... those damm Standards! >- -------------------------------------------------------------------------------- >> < Note 9.0 by EISNER::PERRY "Bob Perry - Skydiver/Sky-Scum" > >> -< Complain, complain... >- >> >> >> >> WHy is this conference RT_11 instead of RT-11 ? (Just trying >> to get activity going here). Ah ... Now thats a Good Question! The answer is ... STANDARDS! There has been an Unofficial standard which says "Thou shall not create DECUSERVE Converences with "-" ... Thou must use "_"!" I Don't like it either ... when in Rome ...! If it REALLY bothers you, you can add it into your notebook using any name you like! Check the online help on adding a conference to your notebook. -Arnold Moderator of the RT-11 (RT_11) conference  ================================================================================ Note 10.0 NEW FEATURES No replies EISNER::DELARISCH "Arnold S. De Larisch" 8 lines 12-FEB-1988 17:12 -------------------------------------------------------------------------------- I'll take this opportunity to start a discussion stream of what new features you would like to have added to RT-11 and related O/S. It is my hope (no guarantees) that this information will be passed on to DEC RT-11 Development group for consideration. Well folks ... starty typing!!! 8-{) -Arnold  ================================================================================ Note 11.0 BUG REPORT No replies EISNER::DELARISCH "Arnold S. De Larisch" 10 lines 12-FEB-1988 17:27 -------------------------------------------------------------------------------- While I'm at it ... may as well ad a discussion stream for known/suspected bugs. Please use this note stream for problem discussions but be aware that there is a Conference for SPRs. Please include the RT-11 version number and component/module/device-handler in question and any other useful information. -Arnold  ================================================================================ Note 12.0 CoProcessor RT11 7 replies EISNER::TINKELMAN "Bob Tinkelman - CCA" 11 lines 26-MAY-1988 12:31 -------------------------------------------------------------------------------- At Cincinnati, there were people talking about Coprocessor RT products. That is, RT11 running on a KXJ11-C board, plugged into a Q-bus, not as its main host. Did anyone attend sessions, talk to DEC developers, or in any other way learn much about this product? How many KXJ11-Cs are supported on the same Q-bus? Does it run on KXT11-C also? Is it hosted under RT11 (say on an 11/73) as well as under VMS (say on a microVAX II)? Can it coexist with CoProcessor RSX? If so, what are the restrictions? What's its status? At field test? More generally, what are the tradeoffs between using RT and RSX in this environment? ================================================================================ Note 12.1 CoProcessor RT11 1 of 7 EISNER::BRIDGE "Adam Bridge" 20 lines 11-JUN-1988 01:53 -< RT-11 on IOP >- -------------------------------------------------------------------------------- DIGITAL made a program announcement of VAX RT-11 ie RT-11 running on the KXJ-11CA in Anaheim. In Cincinnati they essentially repeated the same information. This product essentially makes a VAX into a big fat peripheral - acting as a server for RT-11 virtual disks (which are part of the VMS file structure), booting RT-11 onto the IOP, shutting down the IOP, and other services. A user on a VAX terminal will be able to use some form of SET HOST command to attach to the console terminal of the IOP. The IOP will be able to access files in the host's native file system. The system will also run with a Q-bus PDP-11 host running RT-11. There are also synchronization and mailbox services available that are managed through the host system. Since the product wasn't announced it isn't in field test. Adam ================================================================================ Note 12.2 CoProcessor RT11 2 of 7 EISNER::CROWELL 12 lines 13-JUN-1988 04:10 -< RT & RSX on IOP >- -------------------------------------------------------------------------------- Adam hit on all the salient features of the Co-processor RT-11. As to its comparison to the RSX product, I speak from second-hand information only inasmuch as I have no first-hand experience with the RSX co-processor product. Apart from the normal advantages RT-11 has over RSX, it is my understanding that the RSX product supports only one co-processor and has no support for the on-board devices (serial ports, parallel port, timers, DMA controller). The RT-11 product supports up to 14 boards (if you have enough power and cooling) and sports device handlers for the on-board stuff. ================================================================================ Note 12.3 CoProcessor RT11 3 of 7 EISNER::CETRON 10 lines 13-JUN-1988 19:18 -< Minor RSX clarification >- -------------------------------------------------------------------------------- 1. I don't know of any RSX limits to the number of boards....maybe I will try to find them :-) 2. If RSX (Native) has a driver for any of the 'other' stuff on the kxj, it should run on the coprocessor - I KNOW the serial ports do just fine. -ed ================================================================================ Note 12.4 CoProcessor RT11 4 of 7 EISNER::MCALLISTER "Brian McAllister" 10 lines 14-JUN-1988 18:28 -< Will we really have RT under RT? >- -------------------------------------------------------------------------------- >> The system will also run with a Q-bus PDP-11 host running RT-11. Does this really mean an RT co-processor running in an RT host? If so, what kind of support is there for getting services from the host (and its peripherals)? Brian ================================================================================ Note 12.5 CoProcessor RT11 5 of 7 EISNER::TINKELMAN "Bob Tinkelman - CCA" 14 lines 14-JUN-1988 21:02 -< CPR - clarifications of clarifications >- -------------------------------------------------------------------------------- RE: < Note 12.3 by EISNER::CETRON > -< Minor RSX clarification >- The following are based on my memory of Brian MacCarthy's remarks at the CPR sessions at a recent Symposia (at least at one of the most recent 4-5): 1. As CPR's strategy for getting at KXJ on board memory is to "map it all", it's not really reasonable to put more than 4 KXJ's running CPR on one Q bus. 4 boards * 512K bytes each = 2 meg = 1/2 of Q-bus space! 2. CPR is distributed without any drivers (without any supported drivers?) for the onboard devices. However, you can certainly write your own. At least that was DEC's plan at the time of the presentations. If they've changed their mind, I haven't seen it in any official source. ================================================================================ Note 12.6 CoProcessor RT11 6 of 7 EISNER::DELARISCH "Arnold S. De Larisch" 7 lines 15-JUN-1988 14:50 -< Bob's .-1 note is correct! >- -------------------------------------------------------------------------------- I believe Bob to be correct ... there is a direct mapping of CPR memory to host processor memory. Further there are NO Digital supplied device drivers ... but you could always 'roll your own'! Please remember this is Coprocessor RSX not an RT coprocessor! -Arnold ================================================================================ Note 12.7 CoProcessor RT11 7 of 7 EISNER::CROWELL 21 lines 16-JUN-1988 03:35 -< RT-11/RT >- -------------------------------------------------------------------------------- >> What kind of support is there for getting services from the host >> (and its peripherals)? I'm not sure I understand the question. The "disks" for the RT-11 system on the co-processor are either files on the host system that look like RT-11 logical disks (but need not be mounted as such) or actual RT-11 disks. (i.e any RT-11 file-structured device may serve as a unit of the "KS" device. The "KP" device which permits access to host directories on the VMS hosts, similarly "mounts" to devices on the RT-11 host. The line printer driver on the co-processor winds up sending its output to the host's spooler(RT) or a print queue (VMS). There're mailbox services so that programs running on different IOP's can send messages to each other or to programs running on the host. (Remember that the RT-11 host can be running up to 8 jobs - one of which is the coprocessor server and one is the print spooler.) (access to the host's magtape is not likely to show up in V1.)  ================================================================================ Note 13.0 File transfer 1 reply EISNER::HAHN 7 lines 8-JUN-1988 17:08 -------------------------------------------------------------------------------- Transfering files between RT11 systems I would like to do away with our "sneaker net". I understand that the possibility of using DRV11 on each system and cross coupling the 16bit I/O there is some DECUS software availabel to effect file transfer. I need guidance, on finding such. We run RT11 V05.01B RT11FB. Pierre ================================================================================ Note 13.1 File transfer 1 of 1 EISNER::DELARISCH "Arnold S. De Larisch" 18 lines 8-JUN-1988 17:58 -< Have you looked into Kermit? >- -------------------------------------------------------------------------------- >> < Note 13.0 by EISNER::HAHN > >> -< File transfer >- >> >> Transfering files between RT11 systems >> >> I would like to do away with our "sneaker net". I understand that >> the possibility of using DRV11 on each system and cross coupling >> the 16bit I/O there is some DECUS software availabel to effect file >> transfer. I need guidance, on finding such. We run RT11 V05.01B >> RT11FB. Pierre Pierre, Have you looked into running KERMIT? I don't remember if it works using the FB monitor or if you need the XM monitor. This would be my first choice! -Arnold  ================================================================================ Note 14.0 TCP/IP on RT-11 2 replies EISNER::PATTEEUW "Jack Patteeuw, Ford Motor Company" 15 lines 28-JUN-1988 10:20 -------------------------------------------------------------------------------- <<< EISNER::DUA0:[NOTES$LIBRARY]DEC_NETWORKING.NOTE;1 >>> -< DEC_NETWORKING >- ================================================================================ Note 111.0 TCP/IP on RT-11 1 reply EISNER::PATTEEUW "Jack Patteeuw, Ford Motor Company" 8 lines 27-JUN-1988 12:05 -------------------------------------------------------------------------------- We are looking for TCP/IP under RT-11 so that we can use FTP to download files from a Prime. Process Software sells such a package. Any opinions ? Any other vendors ? ================================================================================ Note 14.1 TCP/IP on RT-11 1 of 2 EISNER::BILLING 29 lines 24-JUL-1989 14:19 -< TCP/IP on RT-11, etc >- -------------------------------------------------------------------------------- Jack, I've been looking at Process Software's TCP/IP software, too. I'm especially interested because you can talk to other operating systems somewhat transparently. I'm about ready to buy. Process Software's phone number is (800)722-7770. Terrance Mulryan can answer questions for you. If 800 number doesn't get him try (508)879-6994. They have an FTP package that will work on RT, TSX+, RSX and IAS. They tell me that there is a PC package available from someone called STP Software. I haven't found them yet. Another source tells me that a package from Execlan is in use here locally. Back to Process Software, they also have an ethernet terminal emulator called TELNET and a inter-task communications package called TCPIP for RT. Other solutions: Omnex Corp., (415)966-8400, has two packages available called EtherExchange and EtherDisk. These are a file transfer package and a file server package. They are RT and VMS only and I think NOT TCP/IP. There was a session given at the Spring 88 DECUS on Ethernet software by Roland Barnard, (505)844-5115, that covered both of these products. Since I need to do transfers between RT, RSX, VMS, PC-DOS and some H-P machines, it looks like I'm committed to the Process Software products. I have heard that DEC is interested in offering a product through cooperative marketing. I'll be interested to hear what others have to say as well. ================================================================================ Note 14.2 TCP/IP on RT-11 2 of 2 EISNER::MCALLISTER "Brian McAllister" 8 lines 16-OCT-1989 21:43 -< TCP/IP for DOS >- -------------------------------------------------------------------------------- -< TCP/IP on RT-11, etc >- They tell me that there is a PC package available from someone called STP Software. ^^^ This is "FTP Software". They do have TCP/IP for PCs. Phone is (617) 246-0900. They are in Massachusetts.  ================================================================================ Note 15.0 Kermit-RT manual 2 replies EISNER::ALLEN_C 7 lines 6-OCT-1988 13:48 -------------------------------------------------------------------------------- Hi there, I am in need of a copy of Kermit-RT doco. Does anyone have a quick and easy method for obtaining same? Thanks, Charly ================================================================================ Note 15.1 Kermit-RT manual 1 of 2 EISNER::KENNEDY "Terry Kennedy" 7 lines 6-OCT-1988 18:42 -< Get it from the BBS >- -------------------------------------------------------------------------------- > I am in need of a copy of Kermit-RT doco. Does anyone have a quick > and easy method for obtaining same? Is it based on Kermit-11 by Brian Nelson? If so, the complete K11 dis- tribution (including docs) can be found in directory [87,6] on the RSTS SIG BBS, at (201) 915-9361. Feel free to grab what you need - access is open to all. ================================================================================ Note 15.2 Kermit-RT manual 2 of 2 EISNER::CROWELL "Shefth of the Fourth Order" 10 lines 8-OCT-1988 13:24 -< KERMIT/RT Doc >- -------------------------------------------------------------------------------- I can copy the stuff onto a floppy for you. Usual ground rules: Send blank floppy and return postage to: John M. Crowell Multiware, Inc. 2121-B Second St. Suite 107 Davis, CA 95616 You'll also want to check out a two-part article about KERMIT/RT in the June and July, 1988 issues of the DECUS Newsletter.  ================================================================================ Note 16.0 Incremental Backup Ideas 1 reply EISNER::KOZAM 35 lines 4-DEC-1988 15:36 -------------------------------------------------------------------------------- Backing up RT/TSX systems is a real pain, especially if you've got a combo such as RD53/RX50. Unfortunately, BUP is only useful for physical device backups. Since the volume of new data on a daily basis is small, what I need is a method of incremental backup. Several problems are involved: 1. RT-11 doesn't support file modification dates, so it's hard to tell if a file needs to be backed up. 2. Logical disks provide a sort of hierarchical file system, but unless a logical disk is mounted, it's just a file. I don't know of any way to mount a disk from within a program using RT-11 (TSX+ has special EMTs to allow you to do this). Problem 1 can be overcome by calculating checksums for each file and storing them somewhere. When running backup, if the newly calculated checksum is different from the stored one, then it's time to back up the file (and replace the old checksum with the new one). Problem 2 can be handled by having code within an application that can directly interpret RT-11 directories. I've written some code that works its way through RT-11 directories and logical disks (up to 8 levels deep), while calculating checksums and writing them to a log file as it goes. By doing a DIFF on two logs files, I can tell if any files have been added/deleted/ modified, but that's as far as I've gotten. Clearly there much more to do. In particular, how to handle multi-volume backup sets and how to use them to reconstruct the system following a mishap. Has anyone else pondered these issues? Is there something obvious (other than buy a TK50) that I'm missing? Are there any dead ends I'm going to run into? ================================================================================ Note 16.1 Incremental Backup Ideas 1 of 1 EISNER::CROWELL "Shefth of the Fourth Order" 6 lines 5-DEC-1988 10:20 -< BUP (BACKUP) Alternative >- -------------------------------------------------------------------------------- Horizon Data Systems has a backup/restore program I use for incremental backups (and device backups for that matter). I much prefer it to BUP. It'll backup files to other disks, (multiple) floppies, magtape and TK50. Files may be included or excluded by before/after dates. Talk to Jack Peterson (804) 740-9244.  ================================================================================ Note 17.0 Non RT user faces RT - help! 7 replies EISNER::BRUCE "Barton F. Bruce - CCA/MA" 50 lines 9-JAN-1989 01:36 -------------------------------------------------------------------------------- Not having used RT for MANY MANY years, and not having any recent RT manuals may make this question rather dumb, but here goes. A prospective client is having a problem with his RT system running some modified MCBA S/W. The former programmer who did most of the work has married this guy's ex, and so this is NOT a viable route for any info/help. We wanted to copy a lot of files to tape, and assumed we would have to /ze the tape first, and then worry about the pesky file-type switches. We only had a short time that day before they closed, so we could not experiment much or get many files. They had a much newer RT system that any I had ever seen. We discovered we could INIT the tape, and then pip'd using /x/m:1, but the damned tape kept rewinding for each file. When we got home (to RSX land) we thought we would have to trot out FLX, but it was a weird (labels 512 bytes long) but readable ANSII tape! We are simply exploring as yet, and need to look at all of his files back here before we decide whether we even want to get involved. Could we have written ANY file type safely with a *.* spec? and how do we stop the rewind between each file. Is there some better utility to get everything to a tape that will be readable under RSX or VMS. Big block sizes would help, too. Everything on his system is in DIBOL, and he has a tape feed from some other system that monthly sends in new prices. The tape is unlabeled, starts with a file mark, and then has zillions of 352 byte records up to a trailing filemark. This is trivial to read under RSX using MOU /NOL, MAG, and PIP, but is there an easy way under RT? Will the RT system be able to read ANSII tapes RSX writes? Only if BS = RS, or even if BS = 10*RS? Will the 80 byte labels be ok? With all the features he wants to add, and due to our almost total lack of current RT experience, we want to move him to something other than an 11/34 + RT + 2*RK07 + TS11 + DZ11. A used 11/44 for well less than $3k can even use his MS11LD memory (with more, of course), his boot chips from his M9312 (or even the M9312 itself), and all his peripherals, and will let him move to M+ where I am totally comfortable, but what about DIBOL, and what else may bite? Any comments, even nasty ones from RT fans, will be welcome! ================================================================================ Note 17.1 Non RT user faces RT - help! 1 of 7 EISNER::HAHN "DECUServe Vice Chair" 5 lines 9-JAN-1989 06:58 -< Just use the COPY command >- -------------------------------------------------------------------------------- When I had a tape drive under RT (last year) I just used COPY tape:*.* disk:*.* or disk:*.* tape:*.*; where disk and tape are the device name. No switches needed. Depending on the version your user has there may be a help capability for COPY. What version of RT ? ================================================================================ Note 17.2 Non RT user faces RT - help! 2 of 7 EISNER::HASSINGER "Bob Hassinger" 23 lines 9-JAN-1989 11:19 -< Yep, "ANSI", RSX was good, RTEM-11 is good on VAX, look for a sw >- -------------------------------------------------------------------------------- It has been even longer since I used RT and even then not much with mag tape, but... I think in those days you could get two flavors of magtape support, one that supported an "ANSI format". I think you had to pick so you may have to look and see what this system is set up for. As you noted the most interesting characteristic of the "ANSI" support was the odd full block size label records. Given a fairly tolerant ANSI tape support implementation on another system you could get the data off the tape pretty well. Writing tapes to go the other way may be a problem - I don't know what RT does with 80 byte label records. I had my best luck getting RSX-11M to read the tapes. VMS was less tolerant back then. Since then however RTEM-11 on the VAX has gotten pretty good. I understand it you can, in effect, get RT to read the tape back on the VAX then you can use various tools to move it to VMS files if you like. I think you can go the other way as well. Check for an obscure switch to control the rewind-on-every-file problem. Can't remember any more if it was RT or RSX where it was vital to use the right switch to avoid this. ================================================================================ Note 17.3 Non RT user faces RT - help! 3 of 7 EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" 36 lines 9-JAN-1989 20:46 -< RT-11 tapes are a pain in the A**, but readable >- -------------------------------------------------------------------------------- >> We discovered we could INIT the tape, and then pip'd using >> /x/m:1, but the damned tape kept rewinding for each file. Change the /m:1 to /m:-1 and it will copy each file to the tape without rewinding. NOTE! This allows you to cause later problems by having two files on the tape with the SAME name. If you are just copying *.* you should be OK. The equivalent DCL command is COPY/POS:-1. >> but it was a weird (labels 512 bytes long) but readable ANSII >> tape! It is an ANSI level 1 tape, while RSX and VMS use level 3. I used VMS EXCHANGE to read RT-11 tapes under VMS v4.x, but either I have forgotten how to do it or EXCHANGE is broken for v5.0. If you need more information on the various tape formats, let me know. I went through all this several years ago and still have all the documentation (somewhere). >> The tape is unlabeled, starts with a file mark, and then has >> zillions of 352 byte records up to a trailing filemark. This is >> trivial to read under RSX using MOU /NOL, MAG, and PIP, but is >> there an easy way under RT? Not without writing your own program to talk directly to the mag tape handler. >> will let him move to M+ where I am totally comfortable, but >> what about DIBOL, and what else may bite? DIBOL is supported under M+ (but not M). I don't know how compatible they are. Alan ================================================================================ Note 17.4 Non RT user faces RT - help! 4 of 7 EISNER::CROWELL "Shefth of the Fourth Order" 15 lines 11-JAN-1989 04:12 -< caveat >- -------------------------------------------------------------------------------- The tapes produced by RT-11 INIT and COPY, as described in this stream can be read by VMS, either directly or via exchange. (There is an option on the VMS MOUNT command that tells it about RT-11's using only one HDR and one EOF record; I don't recall it at the moment.) If you copy directly, there will be problems with ASCII and OBJ files not being compatible. If you copy via EXHCHANGE, it'll make the conversions for you. There is a problem, however, with file names. With versions 5.4 and earlier, file names with fewer than six characters are padded with spaces, and VMS is not ready to accept that. So a file named FILE.DAT comes out as "FILE .DAT".; (not nice). (This is fixed in V5.5.) ================================================================================ Note 17.5 Non RT user faces RT - help! 5 of 7 EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" 22 lines 11-JAN-1989 17:42 -< RT-11 and VMS still don't want to communicate >- -------------------------------------------------------------------------------- >> The tapes produced by RT-11 INIT and COPY, as described in this >> stream can be read by VMS, either directly or via exchange. (There >> is an option on the VMS MOUNT command that tells it about RT-11's >> using only one HDR and one EOF record; I don't recall it at the >> moment.) You are thinking of the /[no]HDR3 switch. RT-11 tapes don't even have HDR2!! The MOUNT manual says to mount the tape /FOREIGN and use EXCHANGE. >> If you copy directly, there will be problems with ASCII >> and OBJ files not being compatible. If you copy via EXHCHANGE, >> it'll make the conversions for you. About an hour of experimenting with both direct and EXCHANGE copying under VMS v5.0-2 was unsuccessful. Every file read was of ZERO length! I know that this worked under v4.x. Am I doing something wrong? The tape was written by RT-11 v5.4, so has something changed there? Is there (perish the thought!) a bug in VMS? Alan ================================================================================ Note 17.6 Non RT user faces RT - help! 6 of 7 EISNER::HAHN "DECUServe Vice Chair" 20 lines 12-JAN-1989 07:32 -< RT tapes to VMS disk >- -------------------------------------------------------------------------------- This worked with RT V 5.? and VMS 4.6..4.7 have not tried it with VMS 5. $! copy rt11 tape files to current directories. $! Volume Label is P1 $! $ allocate mua0: $ set process/priv=VOLPRO $ mount/over=(owner,expir,access) mua0: 'p1' tape $ exchange init/create/allocate=32000 mt.dsk mount/virtual dt: mt.dsk show copy/log mua0:*.* dt:/allocate=1/transfer=block copy/log dt:*.*/transfer=block [] exit $ dismount mua0: $ set process/priv=NOVOLPRO $ deallocate mua0: ================================================================================ Note 17.7 Non RT user faces RT - help! 7 of 7 EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" 13 lines 12-JAN-1989 14:29 -< Tape copy procedure works, but with a small bug >- -------------------------------------------------------------------------------- >> This worked with RT V 5.? and VMS 4.6..4.7 have not tried it with >> VMS 5. I just tried it under VMS v5.0-2 and it worked OK, but with a small problem. There is an extra CR/LF every 512(?) bytes in the text files I examined. I'll look at it further when I have some more time. I suspect that the /TRANSFER=BLOCK switch is what I was missing before, when I just got zero-length files. At least for now I can just edit out the extra CR/LF. Alan  ================================================================================ Note 18.0 Need a few minutes of help with v5.4-F 1 reply EISNER::FRISBIE "Veni, Vidi, $cmkrnli, rebooti" 4 lines 9-JAN-1989 21:37 -------------------------------------------------------------------------------- Does anybody here have RT-11 v5.4-F (or later) that could spare a few minutes to answer some questions via telephone? Alan ================================================================================ Note 18.1 Need a few minutes of help with v5.4-F 1 of 1 EISNER::CROWELL "Shefth of the Fourth Order" 1 line 11-JAN-1989 04:14 -< Call me some time >- -------------------------------------------------------------------------------- Of course, Allen. Call me at (916) 756-3291.  ================================================================================ Note 19.0 TSX problem? 1 reply EISNER::CAMPBELL 8 lines 29-APR-1989 19:21 -------------------------------------------------------------------------------- One of my customers has a TSX-Plus system (V6.3) with 8 LS: flavored spooled printers. Periodically one or another of the printers will start producing reams of garbage, with the immediate need to turn the thing off. It never recovers. The only fix appears to be rebooting TSX, which is a pain. At first I thought this was a data overrun (i.e. a missed XOFF from the printer) but it does not recover even when the spooler queue eventually empties. Any ideas? ================================================================================ Note 19.1 TSX problem? 1 of 1 EISNER::CAMPBELL 7 lines 18-MAY-1989 10:41 -< More data >- -------------------------------------------------------------------------------- At the TSX-Plus Magic session at the recent symposium, 2 or 3 other people reported similar problems. At least one thinks it was "fixed" by using CL: lines instead of LS:. One of the other sites had the problem with LP:, which tends to rule out data overrun. None of the other sites had as many printers (2 was the max) so the number of printers is probably not the base problem, although it may cause it to appear more often.  ================================================================================ Note 20.0 TSX problem with VTCOM No replies EISNER::CAMPBELL 5 lines 29-APR-1989 19:23 -------------------------------------------------------------------------------- When I upgraded from TSX+ V6.2 to V6.4, VTCOM started letting confused escape sequences through to the terminal. I am pretty sure this is a version compatibility problem, and further that it is discussed in the TSX documentation, but I can't find it. Anybody know where it is?  ================================================================================ Note 21.0 Separate I & D No replies EISNER::CAMPBELL 16 lines 18-MAY-1989 10:46 -------------------------------------------------------------------------------- I have been contemplating how to use separate I/D space in TSX-Plus (and eventually RT-11). I decided to limit my initial investigations to FORTRAN-77/RT. Anyone else given any thought to how to take advantage of it now that TSX-Plus sort of supports it? Ideas: 1. Put the OTS into I-space, which means that you need a large D-space region in "parallel". 2. Try to LINK a program. The general method would be to make a program that preprocesses .OBJ files before feeding them to LINK. This program would separate the PSECTs into I and D groups, so that separate runs of LINK could be used to build individual I and D images. Presumably, a fair amount of "glue" would be necessary to hook them back together.  ================================================================================ Note 22.0 Writing RT-11 tapes on VMS No replies EISNER::CROWELL "Shefth of the Fourth Order" 32 lines 14-JUN-1989 13:29 -------------------------------------------------------------------------------- I've finally found a way to write VMS files to magtape on VMS so that they can be read on RT-11. Maybe some of you already do this, but it was a revelation to me. Encapsulate the files in a logical disk! 1. With EXCHANGE, create a logical disk file with a legitimate RT-11 file name. 2. With EXHCNAGE copy the files you want moved to RT-11 into the logical disk. Let EXHCNAGE take care of converting ASCII and OBJ files to proper formats. 3. Initialize the magtape normally. 4. Mount the magtape with /BLOCKSIZE=512/NOHDR3. 5. Copy the logical disk file to the magtape. 6. Now the logical disk file (a nice image file) can be read by RT-11 and copied to an RT-11 disk and mounted as an LD unit. 7. The files in the LD unit can be used normally. This is as close as I've ever come to making an RT-11 magtape from VMS. Reading RT-11 magtapes with EXCHANGE works too, with a wrinkle. If the magtape was written by RT-11 before Version 5.5, file names are padded with spaces, so that VMS interprets ABC.DEF as "ABC .DEF".; and EXCHANGE doesn't know what to do. Version 5.5 FSM fixes this so that there are no embedded spaces in the file name.  ================================================================================ Note 23.0 Fix to USR Shoe Horn 1 reply EISNER::CROWELL "Shefth of the Fourth Order" 16 lines 27-JUL-1989 12:36 -------------------------------------------------------------------------------- When copying files, or opening files of known length, the RT-11 USR finds an empty space on the disk that is the closest fit to the file, and puts it there. A lot of us would rather that the file be put in the first available empty space that is large enough. The following change in USR.MAC will change the "best fit" to "first fit." Old Code: Change to: BHI 9$ BEQ 131$ BEQ 131$ BR 9$ 132$: MOV R4,(R5)+ 132$: MOV R4,(R5)+ It'll work for all monitors. This problem is discussed a little in the September Newsletter. I should have a reliable binary patch procedure worked out for the October issue. ================================================================================ Note 23.1 Fix to USR Shoe Horn 1 of 1 EISNER::FRISBIE "Alan Frisbie - Flying Disk Systems" 2 lines 27-JUL-1989 12:56 -< I like it. Thank you. >- -------------------------------------------------------------------------------- >> < Note 23.0 by EISNER::CROWELL "Shefth of the Fourth Order" > >> -< Fix to USR Shoe Horn >-  ================================================================================ Note 24.0 Device Handler: Logical Device Name Access No replies EISNER::CAMPBELL "Milton Campbell" 60 lines 16-AUG-1989 10:51 -------------------------------------------------------------------------------- At a session at the spring 1989 Symposium in Atlanta I learned about an interesting "trick" having to do with RT-11 "special directory" device handlers. Special directory devices are those that do not contain an RT-11 file structure, the classic example being mag-tape. For such devices, the RT-11 USR does not process the various file processing requests such as .LOOKUP, .ENTER and .CLOSE. Instead, the requests are passed to the handler for any special processing. The "trick" has to do with the file name that the handler sees on a .ENTER or .LOOKUP request. RT-11 passes the name to the handler as a four word RAD50 block, with the device name in the first word, the file name in the second and third words, and the file type in the fourth word. Normally, a special directory handler does not use the device name word because the handler "knows" who it is. However, it turns out that the device name word contains the original device name requested by the user, not the name of the handler that actually processes the request. This means that if the request uses a logical device name (associated with the real device by the ASSIGN command) the handler sees the logical name in the device word. This is useful because special directory handlers can be used to extend RT-11 in a number of ways. One example is the networking product described in the Symposium session. With the logical name available, special directory handlers have additional information about the request. Because the "buffer address" passed to the handler by the operating system points to the start of the file name, extra code is needed to actually get at the device name. The buffer address must be backed up a word, which in turn may cross a PAR boundary. Below is a code fragment to do the backup. I have extended it for TSX-Plus from a fragment by John Crowell for RT-11 XM. mov XXcqe,r4 ; Point to queue element sub #2,Q$BUFF(r4) ; Back up to device name .if ne mmg$t .if eq tsx$p ; Check for TSX ;code for RT-11 XM cmp Q$BUFF(r4),#2000 ; Cross PAR1 boundary? .iff ;code for TSX-Plus cmp Q$BUFF(r4),#140000 ; Cross PAR6 boundary? .endc bhis 5$ ; If still in PAR region add #20000,Q$BUFF(r4) ; Adjust offset sub #200,Q$PAR(r4) ; and PAR bias 5$: .endc