SCHDAVZ@YaleVM.YCC.Yale.Edu (Dave Schweisguth) (06/19/91)
I'd like to find clones of VMS' DCL and EDT (and/or TPU) for a Personal Iris.
The companies a/Soft, Accelr8, and Boston Business Computing all reportedly
provide one or both. Has anyone within netshot used any of these products? Do
they really behave like their forebears? Identical look-n'feel is a BIG
priority, since we have here a large group of Vax users who (quite rightly)
want to spend as little time as possible learning how to use another #$%@&
computer ...
Please mail, and I'll happily post if anything good turns up. Please don't
mention Emacs' EDT mode; I'm aware of it and it won't do. Thanks for your time!
_____________________________________________________________________________
/ \
| Dave Schweisguth 5386 Yale Station 203-436-2694 |
| schdavz@yalevm.ycc.yale.edu New Haven, CT 06502-5386 |
| |
| "Everybody is ignorant, only on different subjects." -- Will Rogers |
\_____________________________________________________________________________/de5@ornl.gov (Dave Sill) (06/19/91)
In article <91169.171310SCHDAVZ@YaleVM.YCC.Yale.Edu>, SCHDAVZ@YaleVM.YCC.Yale.Edu (Dave Schweisguth) writes: >I'd like to find clones of VMS' DCL and EDT (and/or TPU) for a Personal Iris. >... >Identical look-n'feel is a BIG >priority, since we have here a large group of Vax users who (quite rightly) >want to spend as little time as possible learning how to use another #$%@& >computer ... This is the wrong approach. Attempting to hide UNIX from your users with a mask of VMS will only lead to frustration in the long run. There will be lots of picky little incompatibilities, forcing everything through a VMS model is inefficient, and you won't be able to take advantage of the features of UNIX that make it worthwhile. I suggest you all bite the bullet and learn your new systems, rather than trying to make them look like your old systems. Vive la difference. -- Dave Sill (de5@ornl.gov) Tug on anything in nature and you will find Martin Marietta Energy Systems it connected to everything else. Workstation Support --John Muir
jweiss@casbah.acns.nwu.edu (Jerry Weiss) (06/20/91)
In article <1991Jun19.122116.8961@cs.utk.edu> Dave Sill <de5@ornl.gov> writes: >In article <91169.171310SCHDAVZ@YaleVM.YCC.Yale.Edu>, SCHDAVZ@YaleVM.YCC.Yale.Edu (Dave Schweisguth) writes: >>I'd like to find clones of VMS' DCL and EDT (and/or TPU) for a Personal Iris. >>... >>Identical look-n'feel is a BIG >>priority, since we have here a large group of Vax users who (quite rightly) >>want to spend as little time as possible learning how to use another #$%@& >>computer ... > >This is the wrong approach. Attempting to hide UNIX from your users >with a mask of VMS will only lead to frustration in the long run. >There will be lots of picky little incompatibilities, forcing >everything through a VMS model is inefficient, and you won't be able >to take advantage of the features of UNIX that make it worthwhile. > >I suggest you all bite the bullet and learn your new systems, rather >than trying to make them look like your old systems. Vive la >difference. > There is nothing wrong with this approach. It certainly has its advantages and disadvantages and these should be weighed closely and in consideration with the user population's level of expertise. If the users aren't programmers and dont normally deal with the fine details of either DCL or UNIX, then it is probably an acceptable alternative. If on the other hand they are going to be writing DCL procedures or programming, then they should "bite the bullet" and learn a UNIX shell. You can make life easier for most of them however with a few alias commands for things like delete, copy and rename etc. Don't get hung up about rights and wrongs. Evaluate the situation and tradeoffs and make an informed decision. Jerry S. Weiss Northwestern Univ. Medical School
jgardner@convex.com (John B. Gardner) (06/20/91)
In article <1991Jun19.122116.8961@cs.utk.edu> Dave Sill <de5@ornl.gov> writes: >In article <91169.171310SCHDAVZ@YaleVM.YCC.Yale.Edu>, SCHDAVZ@YaleVM.YCC.Yale.Edu (Dave Schweisguth) writes: >>I'd like to find clones of VMS' DCL and EDT (and/or TPU) for a Personal Iris. >>... >>Identical look-n'feel is a BIG >>priority, since we have here a large group of Vax users who (quite rightly) >>want to spend as little time as possible learning how to use another #$%@& >>computer ... > >This is the wrong approach. Attempting to hide UNIX from your users >with a mask of VMS will only lead to frustration in the long run. >There will be lots of picky little incompatibilities, forcing >everything through a VMS model is inefficient, and you won't be able >to take advantage of the features of UNIX that make it worthwhile. Ahhh, I totally disagree. Now granted I'm referring to COVUEshell, which is available only on Convex machines, so won't help Mr. Schweisguth, but I beleive VCL (BBC) et al have similer implementations. "There will be lots of picky little incompatibilities" No, there isn't. There _is_ greater flexibility, in that the user can selectively and globally affect the operation of version numbers, file name extension permutations, case translation, etc. But the defaults can be set to operate _exactly_ as DCL handles them. "forcing everything through a VMS model is inefficient", No, it isn't. The "emulation" is a C-compiled implementation of DCL, just like DCL is a MACRO implementation of DCL. In the case of COVUEshell, the emulation runs as a normal "UNIX shell" and is no less efficient than tcsh, csh, or any other "normal" shell. It runs just as fast as on a native VMS machine, faster in fact, if you take into account the available CPU power. "and you won't be able to take advantage of the features of UNIX that make it worthwhile", Not true. All available UNIX features are accessible from within the emulation. And in "learn" mode every DCL command generates the corresponding UNIX command that would do the same thing, a very effiecient means of learning to use UNIX. Keep in mind that VMS/DCL is a _very_ widespread and effective system. Although _I_ happen to prefer UNIX as an everyday tool, it would be inappropriate for me to demand the entire world follow suit. Each has its place, and using one of the emulation packages can allow both to work in harmony. Obviously UNIX, VMS & DCL, VCL, and COVUEshell are trademarks of ATT, DEC, BBC, and Convex respectively. These comments are personal and do not reflect the views of any company in any way. -- /\ /_ _ jgardner@convex.com \//_//_/ / / "Poor is the man whose pleasures depend / \/ on the permission of another" -Madonna
pack@acd.uucp (Daniel Packman) (06/20/91)
[Various ideas about adviseability of using VMS like tools to hide unix from
users deleted]
I must strongly agree with all parties. The most basic user can probably
be safely sheltered from the operating system. The advanced device driver
writer probably out to know a few things about the system :-)
One thing that is time consuming to learn and needn't conflict with any
operating system is the editor. By all means try to locate editors
that operate similarly to what users have been used to. Emacs is an
interesting starting point since it
1. Runs on many platforms
2. Has a powerful editing language (like TPU)
3. Many different editing styles have already been written in it.
Even the most advanced programmer can live with a somewhat non-standard
editor.
Dan Packman NCAR INTERNET: pack@ncar.UCAR.EDU
(303) 497-1427 P.O. Box 3000 CSNET: pack@ncar.CSNET
Boulder, CO 80307-3000 DECNET SPAN: 9583::PACKejbst4@unix.cis.pitt.edu (Ethan J Benatan) (06/20/91)
There is one emulator that I have used which works pretty well, and does both DCL and EDT; it is good enough that in half a day I managed to learn it and port some serious .com files to it, which required only minor modifications. Here's the rub: it was on a Convex, and is proprietary Convex software, so I don't know if it would be available or workable on anything else. But the Convex folks might be able to help you. The calm voice of reason regarding this: yes, the differences can get annoying; yes, you won't have the unix advantages if you don't learn a shell; but each user will have to decide how much time to invest in learning. I needed one job, *now*, so I did it the quick way. If you are going to be doing this for the next decade, you might want to learn a new shell... Ethan
egb@ednor.bbc.com (Elaine Bedard) (06/20/91)
Boston Business Computing, Ltd offers clones of VMS' DCL and EDT with editing interfaces for EVE, EMACS, vi, and WPS users. Our Products run on DOS and over 40 UNIX platforms. If you need any information concerning VMS emulation software , contact me at 508-470-0444. Boston Business Computing, Ltd. Three Dundee Park Andover, MA 01810 Elaine G. Bedard egb@ednor.bbc.com 508-470-0444 ext 313. FAX 508-474-9244
de5@ornl.gov (Dave Sill) (06/21/91)
In article <1991Jun19.170723.5663@casbah.acns.nwu.edu>, jweiss@casbah.acns.nwu.edu (Jerry Weiss) writes: > >There is nothing wrong with this approach. It certainly has its >advantages and disadvantages and these should be weighed closely and >in consideration with the user population's level of expertise. Sage advice. Of course, I was trying to answer the general question of whether to learn a new environment or make it look like the old one. I still think the latter is foolish in most cases. >If the users aren't programmers and dont normally deal with the fine >details of either DCL or UNIX, then it is probably an acceptable >alternative. In that case, the users are probably spending most of their time in applications. The only choice, then, is to port the applications or buy a version of the same commercial application for the new OS. I.e., if they're not heavy OS users, then go ahead and teach them the 2 dozen new commands they'll need. You'll only be wasting time and money in the long run by making the new OS look like the old OS. >If on the other hand they are going to be writing DCL procedures or >programming, then they should "bite the bullet" and learn >a UNIX shell. My point exactly. >You can make life easier for most of them however with a few alias >commands for things like delete, copy and rename etc. I disagree. The differences between VMS's "delete" and UNIX's "rm" are too great to whitewash with an alias. You'll only confuse your users by providing partial compatability. >Don't get hung up about rights and wrongs. Evaluate the situation and >tradeoffs and make an informed decision. Er, decisions are all about rights and wrongs, aren't they? I believe that in nearly all cases an informed decision on this matter will be to make a clean break with the old environment. -- Dave Sill (de5@ornl.gov) Tug on anything in nature and you will find Martin Marietta Energy Systems it connected to everything else. Workstation Support --John Muir
de5@ornl.gov (Dave Sill) (06/21/91)
In article <1991Jun19.205450.26120@convex.com>, jgardner@convex.com (John B. Gardner) writes: > >Ahhh, I totally disagree. Now granted I'm referring to COVUEshell, which >is available only on Convex machines, so won't help Mr. Schweisguth, but >I beleive VCL (BBC) et al have similer implementations. Well, I don't have a Martin Marietta product to push (wanna buy a Titan/Patriot/a-bomb?), so I guess I'll have to remain general and objective. :-) >"There will be lots of picky little incompatibilities" No, there isn't. >There _is_ greater flexibility... The existance of specific counterexamples doesn't invalid the general point. >"forcing everything through a VMS model is inefficient", No, it isn't. >The "emulation" is a C-compiled implementation of DCL, just like DCL is >a MACRO implementation of DCL. In the case of COVUEshell, the emulation >runs as a normal "UNIX shell" and is no less efficient than tcsh, csh, >or any other "normal" shell. It runs just as fast as on a native VMS >machine, faster in fact, if you take into account the available CPU power. Given two UNIX shells, one that is native UNIX and one that provides VMS compatability, I argue that the former is more efficient because it doesn't have to jump through the hoops of making UNIX look like VMS. It doesn't have to handle funky filename and directory specifications, version numbers, command aliases, VMS /qualifier to UNIX -option conversion, etc. >"and you won't be able to take advantage of the features of UNIX that make >it worthwhile", Not true. All available UNIX features are accessible >from within the emulation. Fine. Does *every* virtual VMS for UNIX do that? Do you do it without violating your VMS compatability? >And in "learn" mode every DCL command generates the corresponding UNIX >command that would do the same thing, a very effiecient means of learning >to use UNIX. That's a potentially useful feature during *transition* to to UNIX from VMS. That's not a reason to provide DCL forever. It also implies that a DCL -> shell convertor could be provided for porting shell scripts, which would also make it easier to make a clean break from VMS. >Keep in mind that VMS/DCL is a _very_ widespread and effective system. So what? So is UNIX/shell, which has the advantage in this case of being the system provided, and the general advantage of being vendor independent and *standard*. >Although _I_ happen to prefer UNIX as an everyday tool, it would be >inappropriate for me to demand the entire world follow suit. When in UNIX, do as the UNIXans do. There's nothing innapropriate in expecting the users of a system to learn it. >Each has its place, and using one of the emulation packages can allow >both to work in harmony. If you need both, buy and run both. UNIX and VMS (or DOS, or whatever) are like oil and water, and will never "work in harmony" on the same box. Hell, UNIX doesn't even work in harmony with *itself*, how you expect it to coexist with another OS? -- Dave Sill (de5@ornl.gov) Tug on anything in nature and you will find Martin Marietta Energy Systems it connected to everything else. Workstation Support --John Muir
jgardner@convex.com (John B. Gardner) (06/21/91)
The following is not meant to be a flame, it's posted in the spirit of maintaining accuracy. :-) In article <1991Jun20.182101.3145@cs.utk.edu> Dave Sill <de5@ornl.gov> writes: >In article <1991Jun19.205450.26120@convex.com>, jgardner@convex.com (John B. Gardner) writes: > >Well, I don't have a Martin Marietta product to push (wanna buy a >Titan/Patriot/a-bomb?), so I guess I'll have to remain general and >objective. :-) I am not trying to sell anything. My post "objectively" listed observable characteristics of VMS emulation packages. And no, I'm not in the market for any weapons, thanks anyway. :-) > >>"There will be lots of picky little incompatibilities" No, there isn't. >>There _is_ greater flexibility... > >The existance of specific counterexamples doesn't invalid the general >point. Interesting logic. Usually the existence of counterexamples _do_ invalidate a premise. I'm not going to take the energy to fully analyze _every_ DCL emulation product, the ones I've used exhibit the characteristics I've listed, that's sufficient for me. >Given two UNIX shells, one that is native UNIX and one that provides >VMS compatability, I argue that the former is more efficient because >it doesn't have to jump through the hoops of making UNIX look like >VMS. It doesn't have to handle funky filename and directory >specifications, version numbers, command aliases, VMS /qualifier to >UNIX -option conversion, etc. First, we're not comparing the efficiency of UNIX vs. VMS, we're comparing VMS against a VMS emulation. Second, even if we _do_ place the emulation against a "UNIX" shell (e.g. tcsh), your comments fail. Tcsh still has file globing to do, command and filename completion, alias and environment variable translation, etc, etc. No _interpreted_ language is going to be blindingly fast, but a case by case comparison of the emulation vs. a UNIX shell doing approximately the same mix of operations comes out essentially a wash. The emulation doesn't "convert" the DCL to UNIX and then run it through another shell. It operates directly over the OS, just like DCL does. There is no conversion from qualifiers to options, the commands interpret the qualifiers directly, just as in DCL. For example, if you enter "DIR" the emulation does NOT run "ls", it runs DIRECTORY.EXE, which is approximately as fast but totally different from the "ls" program. The emulation can be just as fast as any other full-featured shell. >>"and you won't be able to take advantage of the features of UNIX that make >>it worthwhile", Not true. All available UNIX features are accessible >>from within the emulation. > >Fine. Does *every* virtual VMS for UNIX do that? Do you do it >without violating your VMS compatability? I don't have to prove _all_ do, I'm just showing at least _some_ do. As for compatiblity, yes it's obviously not DCL, but the additions are orthogonal to the DCL syntax, causing no compatibility problems. Just like you can extend DCL using "SET COMMAND" to add you own commands to the base interpreter. >>And in "learn" mode every DCL command generates the corresponding UNIX >>command that would do the same thing, a very effiecient means of learning >>to use UNIX. > >That's a potentially useful feature during *transition* to to UNIX >from VMS. That's not a reason to provide DCL forever. It also >implies that a DCL -> shell convertor could be provided for porting >shell scripts, which would also make it easier to make a clean break >from VMS. You're missing the point. The idea is not to force the user to the politically correct language. What you should be doing is providing the mechanisms which allow the user to be most productive. Either as a transitional tool, one which simply allows the VMS/DCL user to be immediately productive on a UNIX platform, or as a very fast batch engine to run VMS applications remotely, the emulations have their place. If you're doing systems level, device driver, or i/o application development you most certainly wouldn't do it through an emulator. But if you're running applications which have already been ported, viewing data on a UNIX system, or doing remote batch submission, why waste the time to learn a totally alien environment? I know of some sites where the users sit at there VMS workstation, submit jobs to a remote queue, get their data back, and don't even realize that it was a UNIX box running an emulation that did the work! >>Keep in mind that VMS/DCL is a _very_ widespread and effective system. > >So what? So is UNIX/shell, which has the advantage in this case of >being the system provided, and the general advantage of being vendor >independent and *standard*. Which UNIX standard are you referring to? BSD 4.2?, System V?, sh?, ksh?, tcsh?, csh? Or which binary standard? ConvexOS? Unicos? Ultrix? SunOS? Give me a break! Just because it says "Unix" does not mean you can just hop on the machine and get work done, unless the machine happens to support a flavor of UNIX you happen to understand. >When in UNIX, do as the UNIXans do. There's nothing innapropriate in >expecting the users of a system to learn it. Tell this to the stockholders when you have to explain a 6 month project slip due to the re-education of all your users to an unfamiler environment. Not to mention that some die-hard VMS hackers simply _refuse_ to learn UNIX, shall we just fire them? >If you need both, buy and run both. Right, I just paid $32 million for a YMP-16, now I have to go back to the board of directors and ask for another $3 million for a VAX 9000. I guess I better subscribe to misc.jobs.offered. >UNIX and VMS (or DOS, or >whatever) are like oil and water, and will never "work in harmony" on >the same box. Hell, UNIX doesn't even work in harmony with *itself*, >how you expect it to coexist with another OS? You are doing the readers of this group a disservice with this diatribe. It is simply wrong. If you've never used a good emulation package then you probably shouldn't comment on their usefulness. I've _experienced_ examples of complex VMS/DCL applications operated by VMS-only hackers running marrily away on UNIX boxes. It's real, it works, believe it. As usual, many tradmarks have been referrenced, these are my personal comments only and do not reflect the view of any company. -- /\ /_ _ jgardner@convex.com \//_//_/ / / "Poor is the man whose pleasures depend / \/ on the permission of another" -Madonna
asg@sage.cc.purdue.edu (The Grand Master) (06/21/91)
In article <1991Jun20.212124.22288@convex.com> jgardner@convex.com (John B. Gardner) writes: }The following is not meant to be a flame, it's posted in the spirit of }maintaining accuracy. :-) }In article <1991Jun20.182101.3145@cs.utk.edu> Dave Sill <de5@ornl.gov> writes: }>In article <1991Jun19.205450.26120@convex.com>, jgardner@convex.com (John B. Gardner) writes: }> }>>"There will be lots of picky little incompatibilities" No, there isn't. }>>There _is_ greater flexibility... }> }>The existance of specific counterexamples doesn't invalid the general }>point. } }Interesting logic. Usually the existence of counterexamples _do_ invalidate }a premise. I'm not going to take the energy to fully analyze _every_ DCL }emulation product, the ones I've used exhibit the characteristics I've }listed, that's sufficient for me. } I think you are missing the difference between a logical premise (what you are discussing) and a general point (what he is talking about). All dogs are black. My dog is white!!! (that is a counterexample invalidating a premise) Killing is wrong. It is alright to kill someone if it is the only way to stop them from killing a 4-year-old boy. (that is a counterexample that does NOT invalidate a general point). i.e. a general point is understood to have some extreme exceptions. } }>Given two UNIX shells, one that is native UNIX and one that provides }>VMS compatability, I argue that the former is more efficient because }>it doesn't have to jump through the hoops of making UNIX look like }>VMS. It doesn't have to handle funky filename and directory }>specifications, version numbers, command aliases, VMS /qualifier to }>UNIX -option conversion, etc. } }First, we're not comparing the efficiency of UNIX vs. VMS, we're comparing }VMS against a VMS emulation. Second, even if we _do_ place the emulation }against a "UNIX" shell (e.g. tcsh), your comments fail. Tcsh still has file }globing to do, command and filename completion, alias and environment variable }translation, etc, etc. No _interpreted_ language is going to be blindingly }fast, but a case by case comparison of the emulation vs. a UNIX shell doing }approximately the same mix of operations comes out essentially a wash. That is not correct at all. Most of the normal operations of vms are done by other shells true. Things like alias expansion, globbing etc. BUT, the DCL-shell will have to do things IN ADDITION to this. Namely - it will have to translate / to -, it will have to translate /tmp/file to DISK5:[tmp]file and more. The overhead caused by these things (and this is going to have to be done on EVERY command), and the loss of time associated with VMS lack of a PATH variable will make a DCL-like shell much slower. In addition, VMS handles environment differently than does UNIX, so this will have to be handled for com files etc. } }The emulation doesn't "convert" the DCL to UNIX and then run it through }another shell. It operates directly over the OS, just like DCL does. There }is no conversion from qualifiers to options, the commands interpret the }qualifiers directly, just as in DCL. For example, if you enter "DIR" the }emulation does NOT run "ls", it runs DIRECTORY.EXE, which is approximately }as fast but totally different from the "ls" program. THE SHELL DOES NOT DO THE INTERPRETATION OF /. Even if you put this translation into DIRECTORY.EXE, it STILL has to be done, because the syscalls interpret /t to mean the file or directory t in the root directory. Therefore, DIRECTORY.EXE will have to translate USER17:[tmp]data.dat to /tmp/data.dat. THIS IS SOMETHING THAT THE ASSOCIATED UNIX COMMANDS DO NOT HAVE TO DO. } }The emulation can be just as fast as any other full-featured shell. See above. No it cannot } } }>>"and you won't be able to take advantage of the features of UNIX that make }>>it worthwhile", Not true. All available UNIX features are accessible }>>from within the emulation. }> }>Fine. Does *every* virtual VMS for UNIX do that? Do you do it }>without violating your VMS compatability? } }I don't have to prove _all_ do, I'm just showing at least _some_ do. }As for compatiblity, yes it's obviously not DCL, but the additions are }orthogonal to the DCL syntax, causing no compatibility problems. Just like }you can extend DCL using "SET COMMAND" to add you own commands to the base }interpreter. The convex-propriety DCL emulator does the original poster no good if he does not have a convex. Praytell - how do you use pipes in your DCL-shell? } } }>>And in "learn" mode every DCL command generates the corresponding UNIX }>>command that would do the same thing, a very effiecient means of learning }>>to use UNIX. }> }>That's a potentially useful feature during *transition* to to UNIX }>from VMS. That's not a reason to provide DCL forever. It also }>implies that a DCL -> shell convertor could be provided for porting }>shell scripts, which would also make it easier to make a clean break }>from VMS. } }You're missing the point. The idea is not to force the user to the }politically correct language. What you should be doing is providing }the mechanisms which allow the user to be most productive. Either as }a transitional tool, one which simply allows the VMS/DCL user to be }immediately productive on a UNIX platform, or as a very fast batch engine }to run VMS applications remotely, the emulations have their place. Would you teach someone accustomed to driving an atomatic to leave a standard shift in second all the time so that they do not have to learn how to drive something new? It is not a matter of forcing someone to use the "pollitically correct language" as you so stupidly put it. DCL was costum made to work well on VMS - NOT UNIX!! There are too many incompatibilities with UNIX, and to many little things that would break - and it would become an administrators nightmare. If someone was switching from a MAC to a PC, I would not simply set it up to start in windows and then tell them to use it that way - I would make sure they learn DOS (Even if windows DID work exactly like the MAC). If you want DCL, buy a VMS machine. Don't cripple a UNIX machine with a DCL-like shell (similarly I would advise against trying to port ksh to VMS). } }If you're doing systems level, device driver, or i/o application development }you most certainly wouldn't do it through an emulator. But if you're running }applications which have already been ported, viewing data on a UNIX system, }or doing remote batch submission, why waste the time to learn a totally alien }environment? Because in the long run they will be better off knowing UNIX. What happens when a new sysadmin is hired to Administrate the UNIX machines who has not used VMS and does not know DCL?? } }I know of some sites where the users sit at there VMS workstation, submit }jobs to a remote queue, get their data back, and don't even realize that it }was a UNIX box running an emulation that did the work! And they write their batch jobs in DCL? } }>>Keep in mind that VMS/DCL is a _very_ widespread and effective system. }> }>So what? So is UNIX/shell, which has the advantage in this case of }>being the system provided, and the general advantage of being vendor }>independent and *standard*. } }Which UNIX standard are you referring to? BSD 4.2?, System V?, sh?, ksh?, }tcsh?, csh? Or which binary standard? ConvexOS? Unicos? Ultrix? SunOS? }Give me a break! Just because it says "Unix" does not mean you can just }hop on the machine and get work done, unless the machine happens to support }a flavor of UNIX you happen to understand. } The shells are (for the most part) standard. Yes there are a few inconsistencies, but if you sit me down in front of ANY UNIX box, I think I will be able to complete whatever normal task you wish me to. } }>When in UNIX, do as the UNIXans do. There's nothing innapropriate in }>expecting the users of a system to learn it. } }Tell this to the stockholders when you have to explain a 6 month project }slip due to the re-education of all your users to an unfamiler environment. }Not to mention that some die-hard VMS hackers simply _refuse_ to learn UNIX, }shall we just fire them? } If they refuse when told to by their boss? Yes - you should most definitely fire them. Why not explain it to the stockholders in 18 months, when production is HIGHER than it would have been because users are using a shell that has been optimized to work with UNIX. } }>If you need both, buy and run both. } }Right, I just paid $32 million for a YMP-16, now I have to go back to the }board of directors and ask for another $3 million for a VAX 9000. I guess }I better subscribe to misc.jobs.offered. } Now I am even more flabergasted. You want users to run DCL on UNICOS????!!!??!?!?!?! That is a shame when Cray did such a nice job on UNICOS. Especially when you are running on such a high performance machine, you should use what has been written to specifically work well with the underlying OS. } }>UNIX and VMS (or DOS, or }>whatever) are like oil and water, and will never "work in harmony" on }>the same box. Hell, UNIX doesn't even work in harmony with *itself*, }>how you expect it to coexist with another OS? } }You are doing the readers of this group a disservice with this diatribe. }It is simply wrong. If you've never used a good emulation package then }you probably shouldn't comment on their usefulness. I've _experienced_ }examples of complex VMS/DCL applications operated by VMS-only hackers }running marrily away on UNIX boxes. It's real, it works, believe it. } No, it is not wrong. There are certain things that work ok in emulators and certain things that don't. Let me ask you a question. Will you have people who know only DOS use a DOS emulator when running on your YMP? Of course not, and the reason why is that things will have to be translated from DOS to UNIX format when entering a command. DIR.EXE will have to translate \'s to /'s. And one thing that has been mentioned. Who is going to develop this emulator (since I doubt that you will find a DCL emulator for UNICOS)?? How long will it take? How much will it cost? And how will you explain to the stockholders that no work was done for 4 weeks because a DCL-emulator had to be written because some of you diehard-VMS users would not learn UNIX? } }As usual, many tradmarks have been referrenced, these are my personal }comments only and do not reflect the view of any company. Yeah trademarks and all that. (Though I consider UNIX to be in the same ballpark as Klenex in that respect). } /\ /_ _ jgardner@convex.com Your friendly neighborhood Bruce --------- ### ## Courtesy of Bruce Varney ### # aka -> The Grand Master # asg@sage.cc.purdue.edu ### ##### # PUCC ### # ;-) # # ;'> # ##
rbn@ralph.uucp (Bob Boyd) (06/21/91)
It's interesting to me how this discussion started off on the topic of
EDITORS -- somehow the participants so far have digressed to a discussion
of the issues around learning different user interfaces to computer systems.
My personal opinion ( humble or not ) about editors is that some of us can
transition to a new type of editor relatively easily -- others not.
I find vi to be a nuisance, especially after having used EDT and EVE+.
I started to learn EMACS some time ago, but had no real need for it at
the time -- so I stuck with EVE+. Now I have a need to do editing on
systems that only have vi, perhaps we will put up a version of emacs
since it seems to be a lot more powerful. Anyway, I am learning to
get comfortable with vi. I still find it frustrating the way some things
are dealt with in vi -- they seem counter-intuitive to me.
My point that I am getting to is that an editor isn't the command interpreter
for most people. And the command interpreter isn't the operating system.
I suggest that if you can port an editor onto a different operating system
you may save a lot of hassle with people having to learn everything from
scratch -- command language and editors when they transition. I have seen
people be very proficient in all types of different editors. Some are
easier to learn. Some are easier to use(fewer keystrokes for same effect).
Some are more powerful(whiz-bang programming/macro language).
How to decide? If Joe/Jane User really likes editor <xyz> and it can be
had for the system they are being required/asked to use, why not provide it?
There's nothing to be gained by beating them on the head and saying "You
shouldn't prefer that editor! You should learn this other one because it
comes with the system." Why should you or I be concerned about defending
any editor...or proselytizing converts to it?
I suggest that if there's a choice available, let the users have their
choice. After all, why not? Except for cost of providing the alternative
what is lost?
Any person performing a trade will tend to develop a favorite set of tools
that they use in doing the job -- and occasionally they may learn that there
is a tool that will help them do the job more easily/faster/etc.... Then
they may choose to make a change.
What other views are there on this besides the ones that have been aired in
this thread already "You can do it that way, but it just wouldn't be the
UNIX way!" or "This way or that way, it's all about the same."?
--
| Disclaimer: (is it bedda dan dat claimer?)
Bob | My opinions are mine, mine, mine! Horrors that
rbn@epavax.rtpnc.epa.gov | anyone would confuse them with those of Unisys
Unisys/EPA | or the Environmental Protection Agency! No Way!de5@ornl.gov (Dave Sill) (06/22/91)
In article <1991Jun20.212124.22288@convex.com>, jgardner@convex.com (John B. Gardner) writes: >Summary: I stand by my post : -) And I by mine. I guess we'll just have to agree to disagree on this topic since neither of us is convincing the other. The Grand Master did a respectable job of answering most of these points, but there're one or two comments I'd like to make. >>Given two UNIX shells, one that is native UNIX and one that provides >>VMS compatability, I argue that the former is more efficient because >>it doesn't have to jump through the hoops of making UNIX look like >>VMS. It doesn't have to handle funky filename and directory >>specifications, version numbers, command aliases, VMS /qualifier to >>UNIX -option conversion, etc. > >First, we're not comparing the efficiency of UNIX vs. VMS, we're comparing >VMS against a VMS emulation. I thought we were comparing UNIX vs. a VMS emulation. The original poster said they were switching their VMS shop to UNIX boxes and wanted to make them lokk like VMS boxes. My response was in this context. >You're missing the point. The idea is not to force the user to the >politically correct language. What you should be doing is providing >the mechanisms which allow the user to be most productive. Either as >a transitional tool, one which simply allows the VMS/DCL user to be >immediately productive on a UNIX platform, or as a very fast batch engine >to run VMS applications remotely, the emulations have their place. I see it differently. In the given scenario, the decision to replace the VMS boxes with UNIX boxes has already been made. Since the search for VMS compatability software was done after the fact, such software must not have been a critical factor when the decision to switch to UNIX was made, or they'd have been to locate the software before making the switch. Hence, management must have accepted the implications of the move to UNIX, e.g., retooling the VMS users. My position is that to attempt to overlay VMS at this point is wrong because it will delay the transition to UNIX and add unexpected costs. >>When in UNIX, do as the UNIXans do. There's nothing innapropriate in >>expecting the users of a system to learn it. > >Tell this to the stockholders when you have to explain a 6 month project >slip due to the re-education of all your users to an unfamiler environment. Uh uh, it's the job of the people that decided to buy UNIX boxes in the first place. No doubt, though, they've planned for this and won't swap the system out from under a project. >Not to mention that some die-hard VMS hackers simply _refuse_ to learn UNIX, >shall we just fire them? In a heartbeat. If management decides to go to UNIX, then programmers/users have the choice of following along or not. The company's not obligated to run VMS forever, or to pay employees that don't produce. >Right, I just paid $32 million for a YMP-16, now I have to go back to the >board of directors and ask for another $3 million for a VAX 9000. I guess >I better subscribe to misc.jobs.offered. I guess, because if you convinced the board that VMS users wouldn't notice a switch to UNICOS you really screwed up bad. But really, this is a different scenario than the original poster's. I have nothing against mixed shops providing emulations, *provided* they're aware of the extra costs at decision making time. -- Dave Sill (de5@ornl.gov) Tug on anything in nature and you will find Martin Marietta Energy Systems it connected to everything else. Workstation Support --John Muir
cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) (06/22/91)
rbn@ralph.uucp (Bob Boyd) writes: | I suggest that if there's a choice available, let the users have their | choice. After all, why not? Except for cost of providing the alternative | what is lost? If people assume that providing something also means that you'll support it, providing things can have hidden costs that make it undesirable. If this is the case, you probably don't want to provide all sorts of editors to your users unless you want to learn each one's idiosyncracies (or can dig up some interested user who's willing to support it and can in fact devote time to doing this). -- ported program: a program which takes constant or increasing effort to port to each new machine. portable program: a program which takes less effort to port to each new machine. cks@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks
udo@aragon.stgt.sub.org (Udo Blatzheim) (06/24/91)
Hello,
I don't have the last messages to read, but I hope i can help
a little bit to see the differences between VMS/DCL and UNIX.
You can have a very usefull book from digital:
UNIX for VMS Users
Philip E. Bourne
Digital Press
12 Crosby Drive
Bedford, Massachusetts 01730
Order Number EY-C177E-DP
DP ISBN 1-55558-034-3
PH ISBN 0-13-947433-1
This book is for VAX users who are making the transition from the
VMS to the UNIX operating system. It follows a logical sequence
from diskussion of fundamental concepts and basic command procedures
through the use of high-level languages, programming the operating
system, text processing, and networked communications. Appendixes
provide command and file summeries and crossreference tables.
Emphasis is on Berkeley UNIX and the C shell, althought most of
the features discussed are pertinent to any version of UNIC-ULTRIX,
AT&T System V, System III, Xenix, and others.
"The text emphasizes the practical aspects of UNIX throughout.
It is loaded with everyday examples of performing tasks, each of
which is compared to its closest VMS counterpart ... [unless]
no counterpart exists. If you have some familiarity with the
VMS example presented, and compare it to the UNIX example and
read the explanation, you should become a competent UNIX user
in a short time."
From the Author's Preface
regards,
Udo