Path: utzoo!attcan!uunet!cbmvax!daveh From: daveh@cbmvax.UUCP (Dave Haynie) Newsgroups: comp.sys.amiga Subject: Re: Multitasking Message-ID: <4906@cbmvax.UUCP> Date: 30 Sep 88 19:37:58 GMT References: <4289@louie.udel.EDU> Organization: Commodore Technology, West Chester, PA Lines: 77 in article <4289@louie.udel.EDU>, rsine@nswc-wo.arpa says: >> I am teaching C on a Vax here at work, and I know *nothing* >> about VMS. I don't know how or *if* it's possible to start up >> another process in VMS. Just for reference, I programmed professionally under VAX/VMS before coming to work at Commodore. > First of all it is possible. Secondly, there's many ways to do it. > The easiest of which is by using the Spawn command. I would strongly > suggest you read the DCL dictionary. If you don't read the whole book > at least look up the Spawn command. There, you've said it yourself. READ THAT MANUAL. VMS certainly offers a nice multitasking environment to a seasoned user, but even UNIX makes it easier. In the Amiga environment, all you need to do is click on the CLI icon again, and you get CLI level multitasking. Under UNIX, you need only to put a "&" at the end of the line in many cases, but when you have to deal with interactive multitasking, forget it. Output can be put in a file. Under VMS, just about everyone I know who's used it extensively has written some kind of DCL script to make it useful. Certainly for me, SPAWN worked, but it wasn't sufficient on it's own. >>... Compile and link on one terminal (about a 3 minute process - yes >> about as slow as compiling C on an Amiga off floppies), and then >> move over to another terminal and log into it, and use the >> editor while the linker does it's work. > That "trick" is probably helping to cause the compiles/links to take > so long. One of the worst thangs you can do to degradate the performance > of a VAX/VMS system is to have a bunch of logins taking place. ... Sure enough. That should IMMEDIATELY point out the problem with VMS multitasking, or UNIX multitasking for that matter. > They are already using one of the most powerful multitasking/multiprocess/ > multiuser operating systems known to mankind. You must be kidding, to > compare the AmigaDos operating system to the robust VMS operating system > is a futile practice of obsurdity. Not necessarily. Certainly comparing VMS on an 8xxx series VAX to a plain old A1000 would be foolish. An A1000 with a good hard disk system will give an 11/750 a run for its money, but anything under VMS is also multiuser, a distinct advantage in the college environment mentioned. VMS is in some ways robust. You get named subprocesses that you can start and stop as you like. But you need to be an experienced user, if not an expert, to really take advantage of all of this. There's also resource tracking, which you don't get on the Amiga. The Amiga's multitasking is superior in some ways. First of all, EXEC uses far less CPU time to manage tasks than either VMS or UNIX. ALL tasks are lightweight tasks, so there's very little penalty for using them. And with the Amiga environment, multitasking is as simple as klicking on an icon. A large portion of the usefulness of any computer can be measured by how easily whatever power available there can be tapped by a user. Accelerated Amigas can also run, for single users, in the speed relm of 780 and 8xxx VAXen. And really, how many VMS programs typically run as many individual tasks? The only one I know of is the Emacs we use, and about all that does is spawn itself and provide commands (again, via a DCL script) to keep itself running in the background and permit the user entry and exit pretty easily. Still, not as easy as A-N/A-M. The main problem with the Amiga's multitasking is lack of memory protection or resource tracking. Which amounts to the fact that an errant task can easily crask the machine, and that tasks can only be stopped under use control if the user has direct control of that task (as in interactive tasks) or if that task chooses to listen to the OS stop signals. Because the OS doesn't track resources, each program must, and that makes stop signals necessarily optional. > Ranb -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"