haque@dg.cs.umn.edu (Samudra E. Haque) (05/14/88)
>From: chris@ACC-SB-UNIX.ARPA (Chris VandenBerg) >Date: 9 May 88 17:45:19 GMT >> I am going to be running Honeywell and Data General systems on a >>LAN soon and have been told by a customer that they have TCP/IP implement- >>ations running on them. Does anyone have any comments, suggestions, war >>stories or anything else that relates to these implementations? I have never I run a MV10000 machine with Data General native unix here at the Computer Science Laboratories, current revision of the OS is 3.11 and revision of the TCP/IP portion is 2.1 I believe. Summary of TCP/IP on DG machines: not bad, but could be better. You might want to be aware of a couple of things "peculiar" or "unique" to Data General Unix software: Disclaimer: Your mileage may vary in proportion to the relation you have with the company and its sales offices. a) There ARE people directly connected with Data General on the net and who have access to this and other newsgroups. Maybe they'd like to publicise their own product some day? [Dg-Rtp people:With the recent Unix announcement by De Castro, don't you think your management would love a few extra customers? :-) ] b) Currently DG has several TCP/IP packages with different O/S's: AOS/VS with MV/UX (Unix) as a sub-process. DG/UX native Unix (SVID compatible System V/BSD 4.2) We used to have AOS/VS at our site but about 9 months ago switched over to DG/UX. While the cutover itself was painless, and while DG/UX makes our machine a far better and useful CPU on the whole, lack of good networking utilities hampered us a bit. Also something that really hurt us was the "inability" for DG/UX to communicate with certain vendor machines including other MV series machines themselves. Some of these problems are currently under going investigation (Data General has a very good customer support service at least), but here are a few details: 1) Most of the code for the TCP/IP version 2.1 coupled with DG/UX 3.11 were written in 1985 or 1986. code currently is predominantly based on 4.2 code with *ALL* of the bugs still present. 2) No nameserver support. 3) Occasionally some of our SUN-2's and SUN-3's will not be able to communicate with the MV and vice-versa. 4) I find it impossible to work from an MV10000 <->MV20000 over the arpanet using DG/UX 3.11 and TCP/IP. Connections will inevitably hang or refuse to start at all. 5) In one nasty case, we found that they had ('as a result of a design decision in previous revisions ') written parts of the O/S code that relied on a particular level of revisions of the boards inside the CPU including the ILC (intelligent lan controller). What would happen if you weren't running that particular level was that occasionally (read: randomly) there was the possibility of a board being *IGNORED* by the CPU. Only a hardware reset would bring that board back up! There was no fix except to *up* the hardware, and if it happens again I'm tearing somebody's desk in half. b) Things ARE going to change: (All for the better I hope) 1) revision numbers are going to be standardised. Thus DG/UX revision 4, due out mid summer is going to have TCP/IP rev 4. 2) nameserver support will be provided. 3) new code fixing trailing headers and other problems The reason for this change in progress is the advent of DG/UX revision 4: (100% system V and 80-90% BSD, according to sales reps). Data General wants to get into the Unix market with a stronger line of products and hence it has just recently increased support of DG/UX internally. Overall I have heard DG/UX revision 4 to be a worthwile operating system. c) Currently DG/UX has neat stuff like NFS/YP (we use NFS, but not YP) pretty good implementations, except for lacking in symbolic links (fixed in rev 4 of course). It has also the standard BSD 'R' functions : rsh/rlogin etc. etc. Programming with TCP/IP isn't that bad from my limited experience with it, ( I ported RRN at least) like any other piece of software that is to exist in a hybrid environment the following apply: 1) If you use system independent packages (i.e. curses and not terminfo) software will tend to port easier. 2) If you really really REALLY want to break a piece of software - you will be able to. 3) Rtfm,rtfm, RTFM! d) Corporate Software support is good now from the customer support center in Atlanta, GA - but it could be a lot better. It used to be until a few weeks ago that the first level reps would not know the remotest Unix type questions even if you told them the page number of the manual to look at. Again, with the turn towards unix, more and more staff are taking Unix classes. (I can just see it now: "you mean if I do a 'ls' it will print out the same information as the DIR command in AOS/VS? ":-) If they (DGC software problem management dept), happen to fix a bug, then often times they will give you binaries of all the programs ($22,000 for source code if you are inclined to buy it) and they won't even provide the *.o modules for convinience. That means of course you *have* to be upto date with the software revisions. Other than that - I don't have much to say. (i've already said enough don't you think?). Again, it's raining now but the outlook for the future is clear and getting warmer. Oh, I think 75 F, and 35% humidity please.. Cheers! Samudra E. Haque Computer Science Laboratories, Computer Science Department University of Minnesota, Minneapolis, MN 55455 (1)-(612)-625-0876 || haque@dg.cs.umn.edu || umn-cs!haque%dg.cs.umn.edu