TOMIII@MTUS5.BITNET (Thomas Dwyer III) (11/06/90)
>Sure. I am talking more about it from the MS/DOS application point of view. >It needs to be more like the printer attached to a PC-LAN. Right now, most >of my users have to go an extra step to print via PCNFS (hot key, or enter >net print to insure that PCNFSD "heard" that there was stuff to print). A >few use the "program exit" and timeout features, but more would rather is >just acted like a printer attached to their PC. Well, on the other hand, we rather prefer Sun's idea of the NET PRINT * command. If I want something to come out of the printer, *I'll* tell it to come out. Beame has to guess when you are ready for the queue to be printed, where as Sun lets *you* decide. I also like Sun's idea of having T: U: and V: as "windows" to the print queue; you can watch your file(s) get printed by using the "dir" command. Beame does not have anything similar to this. Thomas Dwyer III Email: tomiii@mtu.edu Network Programmer tomiii@mtus5.BITNET Computing Technology Services Voice: (906) 487-2110 Michigan Technological University Fax: (906) 487-2787
TOMIII@MTUS5.BITNET (Thomas Dwyer III) (11/06/90)
>>>Most of our large customers buy right-to-copy (RTC) kits, in which >>>we sell them a set of diskettes and a serialization kit. They are >>>free to use this to manufacture multiple full kits, or (more >>>commonly) to create a serialized PCNFS.SYS for each system. The >>>downside: documentation must be purchased separately. >>>some of what we're thinking about long-term, with no dates, > >That doesn't help most of us. > >You see, here's the classic problem: >1) You load PC/NFS on a machine, and give it a serial number. >2) The system crashes it's hard disk, losing the serialized copy. > >Now, you have to have (1) the original diskettes, or (2) knowledge of which >copy was on that machine, or (3) you burn another copy (with the RTC kit). > >If you don't do this, you end up with two that have the same serial number, >and they stop one another when they detect the "license violation". In our situation, we have some 300+ copies of PC-NFS, which we made with the "serialization kit". The problem here is that our machines are in student labs, where they boot off floppys. The boot disks seem to mysteriously "wander off" every once in a while. How in the world are we supposed to determine what serial number to use for the new disk? If Sun insists on making PC-NFS serialized, why can't the server handle this, based on the PC IP address or machine name or anything? The software on the PC should NEVER have anything to do with serialization. It should be handled by the server. Every PC on our campus boots with the same serial number. We then obtain the correct serial number from a yp map. Why can't Sun integrate this idea with the distributed PC-NFS? Since we cannot use the toolkit until *after* the NET START RDR command, all our machines complain for the first few minutes of the boot process. This is a major influence on our abandonment of Sun. Our evaluation of Beame's BW-NFS so far has been quite satisfying. First of all, Beame has NO ANNOYING serial numbers. It boots faster, has a very nice telnet (with multiple sessions AND user-defined keyboard maps), and supports packet drivers out of the box. As far as customer support goes, I must admit that Beame leaves Sun in the dust. I have spent many an hour on the phone with Sun, only to hear the phrase, "...in the next release, due out sometime in the 90's..." or "Ok, I'll file a bug report." On the other hand, I had a few questions about BW-NFS and left a message at Beame. Within an hour, Carl Beame himself called back, was able to answer all my questions, and was quite receptive to new ideas and modifications. By the way, my previous posting regarding Beame's failure to allow the user to determine when a file is spooled was incorrect. After re-reading the chapter on printing, it appears that Beame DOES have a hotkey which causes the file to be printed. The question is this: So many people are hacking PC-NFS to make it useable. Why isn't Sun? Thomas Dwyer III Email: tomiii@mtu.edu Network Programmer tomiii@mtus5.BITNET Computing Technology Services Voice: (906) 487-2110 Michigan Technological University Fax: (906) 487-2787
karl@naitc.naitc.com (Karl Denninger) (11/08/90)
In article <90309.170944TOMIII@MTUS5.BITNET> TOMIII@MTUS5.BITNET (Thomas Dwyer III) writes: >>Sure. I am talking more about it from the MS/DOS application point of view. >>It needs to be more like the printer attached to a PC-LAN. Right now, most >>of my users have to go an extra step to print via PCNFS (hot key, or enter >>net print to insure that PCNFSD "heard" that there was stuff to print). A >>few use the "program exit" and timeout features, but more would rather is >>just acted like a printer attached to their PC. > >Well, on the other hand, we rather prefer Sun's idea of the NET PRINT * >command. If I want something to come out of the printer, *I'll* tell it >to come out. Beame has to guess when you are ready for the queue to be >printed, where as Sun lets *you* decide. Not true. You didn't read the docs! There are three ways to get printer output from B&W NFS: 1) <CTRL> <PRT SC>. Queues what you have in the spooler immediately. 2) If the application uses DOS interrupt services, it times out in 30 seconds. 3) If the application opens a DOS handle (ie: open("LPT1", .....)) the output is queued immediately when the handle is closed. >I also like Sun's idea of having >T: U: and V: as "windows" to the print queue; you can watch your file(s) >get printed by using the "dir" command. Beame does not have anything >similar to this. I find that a major hassle rather than a blessing. It removes three drives from use, and does so in a manner that is completely counter-intuitive. Try explaining this to an end user! -- Karl Denninger AC Nielsen kdenning@ksun.naitc.com (708) 317-3285 Disclaimer: Contents represent opinions of the author; I do not speak for AC Nielsen on Usenet.