hogue@hsi.UUCP (Jim Hogue) (03/22/89)
Reply-to: hogue@hsi.UUCP (Jim Hogue)
We have a potential client that has a VAX running VMS. Our software runs
under Ultrix. They want to use Decnet to connect the two systems. The
idea is to use all the peripherals (primarily terminals and printers)
that are currently on the VMS system, with the Ultrix system. So my questions
are. Note that I am knowledgeable on Ultrix (read BSD) and have no knowledge
(or none that I would admit to) of VMS.
1. Does Decnet provide an rlogin type facility from VMS to Ultrix.
Is there any problem with terminal handling (say curses or something
similar)? Does VMS catch some characters, sequences or signals
that could cause problems?
2. If the printers are located on the VMS machine can the Ultrix spooler
be told this? Without the end user knowing where the printer is
physically connected?
Any info on this would be greatly appreciated.
Jim Hogue
Health Systems International New Haven, CT (203) 562-2101
hogue@hsi.com or {noao, uunet, yale}!hsi!hoguetreese@crltrx.crl.dec.com (Win Treese) (03/25/89)
In article <88339@felix.UUCP> hogue@hsi.UUCP (Jim Hogue) writes: >Reply-to: hogue@hsi.UUCP (Jim Hogue) > >1. Does Decnet provide an rlogin type facility from VMS to Ultrix. > Is there any problem with terminal handling (say curses or something > similar)? Does VMS catch some characters, sequences or signals > that could cause problems? Yes, it provides the facility; execute SET HOST <node-name> on VMS. Terminal handling generally works, although there are occasionally glitches. As I recall, VMS to Ultrix works somewhat better than the other way around. On Ultrix, the 'dlogin' command from the DECnet/Ultrix kit lets you login to the VMS machine. >2. If the printers are located on the VMS machine can the Ultrix spooler > be told this? Without the end user knowing where the printer is > physically connected? If the printers are really physically connected to the VMS machine, it's a little tricky. If they're on a LAT (Local Area Terminal) server, then it's easy, since the VMS and Ultrix machines can share access to the printers. If they're physically connected, one can write a "print filter" that takes the files, copies them to VMS using 'dcp' and then copies a DCL command file that prints the file. Ugly, but it works. (Note: there's a small security opening associated with this, if you're worried about such things). Win Treese Cambridge Research Lab treese@crl.dec.com Digital Equipment Corp.
curci@stat.uucp (Ray Curci (scri)) (03/26/89)
>In article <115@crltrx.crl.dec.com> treese@crl.dec.com.UUCP (Win Treese) writes: >>In article <88339@felix.UUCP> hogue@hsi.UUCP (Jim Hogue) writes: >>>Reply-to: hogue@hsi.UUCP (Jim Hogue) >>> >>Yes, it provides the facility; execute SET HOST <node-name> on VMS. >> >>If the printers are really physically connected to the VMS machine, it's >>a little tricky. >> >>Win Treese Cambridge Research Lab >>treese@crl.dec.com Digital Equipment Corp. > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==- The above solution will work with interactive terminal logins, but only with DEC equipment. Also, the suggestion of using DCP to copy files to be printed and a DCL command file to send the data to the printer is very kludgy at best. I have implemented a daemon that runs on our VMS machines to look in a special world writable directory every few minutes queueing files to the printers if any are found. A much cleaner solution is to buy SRI MULTINET (contact: postmaster@tgv.com) for your VMS systems. With MULTINET, you can use RLOGIN and TELNET from any machine to reach any other machine (Ultrix comes with rlogin and telnet). The BSD-style remote printer software that comes with ultrix will talk to MULTINET's lpd-server to access any of the VMS printers. This solution also has the advantage that UNIX machines from other vendors (SUN, HP, Apollo, NeXT, IRIS, ...) can be integrated very smoothly in the future into the network. Another advantage is that you can also connect inexpensive IBM PC/XT/AT/PS2s and MACs with ethernet boards to provide low-end workstations using the public domain software from NCSA and/or MIT which gives you the ability to do terminal logins onto any machines and very fast file transfer capability. ray curci
aad@stpstn.UUCP (Anthony A. Datri) (03/29/89)
>>1. Does Decnet provide an rlogin type facility from VMS to Ultrix. >On Ultrix, the 'dlogin' command from the DECnet/Ultrix kit lets you login >to the VMS machine. DECnet for both VMS and Ultrix costs extra. VMS also continues to believe that all terminal are made by DEC. >>2. If the printers are located on the VMS machine can the Ultrix spooler >> be told this? Without the end user knowing where the printer is >> physically connected? >If the printers are really physically connected to the VMS machine, it's >a little tricky. If they're on a LAT (Local Area Terminal) server, then it's >easy, since the VMS and Ultrix machines can share access to the printers. But nothing else can, since DEC doesn't seem to think much of this upstart TCP/IP stuff that nobody uses. LAT stuff is only for DECnet, and as I remember, it also costs extra. I favor the use of TCP/IP under VMS as an alternative. It integrates the VMS machine into a multi-vendor, multi-os environment a whole lot better, and the CMU flavor is also cheap and does BSD lpr/lpd for remote printing. Other vendors also supply TCP/IP for VMS. Granted, the DECnet/Internet gateway stuff for DECnet/Ultrix helps, but it's still a royal pain. -- @disclaimer(Any concepts or opinions above are entirely mine, not those of my employer, my GIGI, my VT05, or my 11/34) beak is@>beak is not Anthony A. Datri @SysAdmin(Stepstone Corporation) aad@stepstone.com stpstn!aad
sdowdy@charon.unm.edu (Stephen Dowdy) (03/30/89)
In article <3096@stpstn.UUCP> aad@stepstone.com writes: >DECnet for both VMS and Ultrix costs extra. VMS also continues to believe >that all terminal are made by DEC. In fact, VMS believed that most terminals were ANSI standard. The VT series terminals adhere to a non-DEC standard! (at least pretty closely) Your statement is fallacious. Just because no one else seems to adhere to the ANSI standard is not reason to blast DEC. Anyone could make their terminals ANSI standard, and a lot of manufacturers do go by ANSI standards. (maybe not for terminals) >But nothing else can, since DEC doesn't seem to think much of this upstart >TCP/IP stuff that nobody uses. LAT stuff is only for DECnet, and as I >remember, it also costs extra. I favor the use of TCP/IP under VMS as an >alternative. It integrates the VMS machine into a multi-vendor, multi-os >environment a whole lot better, and the CMU flavor is also cheap and does BSD >lpr/lpd for remote printing. Other vendors also supply TCP/IP for VMS. > >Granted, the DECnet/Internet gateway stuff for DECnet/Ultrix helps, but it's >still a royal pain. DEC has finally pulled their heads out. With the advent of the DECStation 3100, the added un*x interest, DECWindows, etc. (the vms/ultrix connection, though it is not terribly useful at the moment) there is an indication of the new-found support at Digital regarding integration. We finally see a DEC that is no longer ignoring the outside world's desires. This is going to be a big pain, partially due to the fact that rigorous standards are not in existence or not adhered to in a lot of the unix world. I think the next 5 years will show a marked change in how things come from DEC. --stephen dowdy (note that i do not work for digital, i am just making a personal observation) -- $!####################################################################### $! stephen dowdy (UNM CIRT) Albuquerque, New Mexico, 87131 (505) 277-8044 $! Usenet: {convex,ucbvax,gatech,csu-cs,anl-mcs}!unmvax!charon!sdowdy $! BITNET: sdowdy@unmb $! Internet: sdowdy@charon.UNM.EDU $! Team SPAM in '87! SPAAAAAAAAAAAAAAAAAAAAMMMMMMM! $!#######################################################################
sullivan@phyllis.math.binghamton.edu (fred sullivan) (03/31/89)
In article <4744@charon.unm.edu> sdowdy@charon.unm.edu (Stephen Dowdy) writes: >In fact, VMS believed that most terminals were ANSI standard. >The VT series terminals adhere to a non-DEC standard! (at least pretty >closely) Your statement is fallacious. Just because no one else >seems to adhere to the ANSI standard is not reason to blast DEC. Anyone >could make their terminals ANSI standard, and a lot of manufacturers >do go by ANSI standards. (maybe not for terminals) And is ANSI going to pay for everyone to replace the thousands of terminals still in use which existed before the standard? Come on. Even IBM mainframes can handle ADM3a terminals just fine (even if they did buy the software from Yale), and if you are behind IBM in this area, you should hang your head in shame! Fred Sullivan SUNY at Binghamton Dept. Math. Sciences Binghamton, NY 13903 sullivan@marge.math.binghamton.edu First you make a roux!
burzio@mmlai.UUCP (Tony Burzio) (04/02/89)
In article <4744@charon.unm.edu>, sdowdy@charon.unm.edu (Stephen Dowdy) writes: > In fact, VMS believed that most terminals were ANSI standard. > The VT series terminals adhere to a non-DEC standard! (at least pretty > closely) Your statement is fallacious. Just because no one else > seems to adhere to the ANSI standard is not reason to blast DEC. Anyone > could make their terminals ANSI standard, and a lot of manufacturers > do go by ANSI standards. (maybe not for terminals) There should be a way to add new terminal support to VMS. > >environment a whole lot better, and the CMU flavor is also cheap and does BSD > >lpr/lpd for remote printing. Other vendors also supply TCP/IP for VMS. The CMU package does not work well to my Hewlett Packard. For some reason it hangs up remote logins if they become inactive for a time. The Wolongong and Excellan products work better, but will not pass the ^C through to stop output from tying up the screen (use lots of | less :-) > >Granted, the DECnet/Internet gateway stuff for DECnet/Ultrix helps, but it's > >still a royal pain. If you add NFS support to VMS along with RMS, do you need to have one of your symetrical procesors just running the I/O subsection? > DEC has finally pulled their heads out. With the advent of the > DECStation 3100, the added un*x interest, DECWindows, etc. (the > vms/ultrix connection, though it is not terribly useful at the moment) > there is an indication of the new-found support at Digital regarding > integration. We finally see a DEC that is no longer ignoring the > outside world's desires. This is going to be a big pain, partially due > to the fact that rigorous standards are not in existence or not adhered > to in a lot of the unix world. The interconnect standards seem to be very strict; it is the program and library functions of the various UNIX flavors that are different. DEC is talking UNIX because the government has stopped blindly buying any old computer and specifying UNIX. To get DEC's attention, pull the purse string :-) By the by, it's X Windows, not DECwindows... > I think the next 5 years will show a marked change in how things come from > DEC. DEC is much like GM: great sales of widgets they do not themselves produce... ********************************************************************* Tony Burzio * Everybody is moving to the SouthWest. Martin Marietta Labs * Just what are these people to do for water? mmlai!burzio@uunet.uu.net * *********************************************************************
aad@stpstn.UUCP (Anthony A. Datri) (04/03/89)
In article <4744@charon.unm.edu> sdowdy@charon.unm.edu (Stephen Dowdy) writes: >In article <3096@stpstn.UUCP> aad@stepstone.com writes: >>VMS also continues to believe that all terminal are made by DEC. >In fact, VMS believed that most terminals were ANSI standard. >The VT series terminals adhere to a non-DEC standard! (at least pretty >closely) Your statement is fallacious. Just because no one else >seems to adhere to the ANSI standard is not reason to blast DEC. I wasn't talking about ANSI-conformance, I was talking about terminal independence. As far as I know, there is no simple way to make VMS deal properly with "non-DECish" terminals, ie., a Sun. Sure, the Sun's sort-of ANSI, but with different dimensions, etc. A previous employer had a user who insisted on using a Concept terminal on a VMS machine, and she had all sorts of strange behavior. I'm also told that many of the "standard" VMS programs (like the variety of editors) have ANSI codes >imbedded< in them, so they won't even work on a vt52. My DEC GIGI (stop laughing!), for example, doesn't support things like "delete-line", but then, that's a VK, not a VT. >DECStation 3100, the added un*x interest, DECWindows, etc. (the >vms/ultrix connection, though it is not terribly useful at the moment) But the VMS/Ultrix connection still costs extra, and as you say, isn't terribly useful. As I understand it, VMS DECwindows only works with DECnet connections. I'm quite suprised at DEC's move in using the MIPS processor, not in that I disapprove of the MIPS chips (I certainly don't), but in that one of DEC's selling points has been binary compatibility up and down their primary line. -- @disclaimer(Any concepts or opinions above are entirely mine, not those of my employer, my GIGI, my VT05, or my 11/34) beak is@>beak is not Anthony A. Datri @SysAdmin(Stepstone Corporation) aad@stepstone.com stpstn!aad
fkittred@bbn.com (Fletcher Kittredge) (04/03/89)
In article <521@mmlai.UUCP> burzio@mmlai.UUCP (Tony Burzio) writes: > >The CMU package does not work well to my Hewlett Packard. For some reason it >hangs up remote logins if they become inactive for a time. The Wolongong >and Excellan products work better, but will not pass the ^C through to stop >output from tying up the screen (use lots of | less :-) > Hum, could it be that you don't have the C shell enviromental variable "autologout" set to zero? We had a similar problem here with Ultrix to HP systems until we found this feature. >By the by, it's X Windows, not DECwindows... There is no such thing as "X Windows", there is X, X11, the "X Window System", but no "X Windows". The one thing that the X Consortium asks is that you do not call their contribution "X Windows"... regards, fletcher Fletcher E. Kittredge fkittred@bbn.com
rob@violet.berkeley.edu (Rob Robertson) (04/04/89)
In article <521@mmlai.UUCP> burzio@mmlai.UUCP (Tony Burzio) writes: >There should be a way to add new terminal support to VMS. there is. you have to specify your terminals though in assembler, don't expect to have something as 'easy' as termcap, you still have to watch out for applications that have imbeded control sequences... how to specify different terminals this is most probably in the vast VMS documentation set. >> >environment a whole lot better, and the CMU flavor is also cheap and does BSD >> >lpr/lpd for remote printing. Other vendors also supply TCP/IP for VMS. > >The CMU package does not work well to my Hewlett Packard. For some reason it >hangs up remote logins if they become inactive for a time. The Wolongong >and Excellan products work better, but will not pass the ^C through to stop >output from tying up the screen (use lots of | less :-) The CMU/TEK package is at best lukewarm. From what I've seen it's pretty slow on a 750. With the Excelan product, they have alot of the upper level protocols on the board so it tends to go somewhat faster.... rob
aad@stpstn.UUCP (Anthony A. Datri) (04/04/89)
In article <521@mmlai.UUCP> burzio@mmlai.UUCP (Tony Burzio) writes: >> >environment a whole lot better, and the CMU flavor is also cheap and does BSD >> >lpr/lpd for remote printing. Other vendors also supply TCP/IP for VMS. >The CMU package does not work well to my Hewlett Packard. For some reason it >hangs up remote logins if they become inactive for a time. HP-UX seems to have an auto-loggerout. I think your problems there might go away if you "unset autologout" in your shells, although I also admit there might be a problem with the CMU tcp/ip itself. >If you add NFS support to VMS along with RMS, do you need to have one of >your symetrical procesors just running the I/O subsection? There are those who don't want RMS anyway, but let's not start that again. -- @disclaimer(Any concepts or opinions above are entirely mine, not those of my employer, my GIGI, my VT05, or my 11/34) beak is@>beak is not Anthony A. Datri @SysAdmin(Stepstone Corporation) aad@stepstone.com stpstn!aad
burzio@mmlai.UUCP (Tony Burzio) (04/05/89)
In article <38133@bbn.COM>, fkittred@bbn.com (Fletcher Kittredge) writes: > >The CMU package does not work well to my Hewlett Packard. For some reason it > >hangs up remote logins if they become inactive for a time. The Wolongong > > > Hum, could it be that you don't have the C shell enviromental variable > "autologout" set to zero? We had a similar problem here with Ultrix > to HP systems until we found this feature. We run the korn shell, and I have left the terminal logged in all day without being logged out. A long time ago a message was posted that the HP does not respond to the CMU "are you still alive" query, making it log out. There was a patch to disable this query, but it didn't work. > >By the by, it's X Windows, not DECwindows... > > There is no such thing as "X Windows", there is X, X11, the "X Window System", > but no "X Windows". The one thing that the X Consortium asks is > that you do not call their contribution "X Windows"... Ahhh... We shall split hairs, but there is a wider gulf to DECwindows... ********************************************************************* Tony Burzio * UNIX -> ULTRIX -> MEGAULTRIX -> Martin Marietta Labs * SUPERDUPERMEGAULTRIX? mmlai!burzio@uunet.uu.net * *********************************************************************
burzio@mmlai.UUCP (Tony Burzio) (04/05/89)
In article <22545@agate.BERKELEY.EDU>, rob@violet.berkeley.edu (Rob Robertson) writes: > >There should be a way to add new terminal support to VMS. > there is. you have to specify your terminals though in assembler, Yuch! > The CMU/TEK package is at best lukewarm. From what I've seen it's > pretty slow on a 750. With the Excelan product, they have alot of the > upper level protocols on the board so it tends to go somewhat faster.... Until you get to high baud rates. At 38.6K baud, the Excelan board slows to an effective 300 baud. No fix from Excelan available. ********************************************************************* Tony Burzio * Would DEC give up DECnet and follow the Martin Marietta Labs * TCP/IP standards if we would call it mmlai!burzio@uunet.uu.net * DECip? Probably... *********************************************************************