rick@pcrat.UUCP (Rick Richardson) (09/01/88)
In article <1988Aug30.232449.15486@gpu.utcs.toronto.edu> woods@gpu.utcs.Toronto.EDU (Greg Woods) writes: > >If one of the systems mentioned happens to be ISC's 386/ix, I'd be wary >of what appears to me to be a mis-understanding on their part about the >RS-232 interface. We have an internal Hayes 2400 baud modem. It seems >that the COM1/COM2 drivers in 386/ix won't allow uugetty to function >correctly. I haven't tried uugetty under 386/ix (1.0.4), but there is at least one big problem with the asy.o driver. Once you drop DTR by setting the baud rate to B0, the only way to raise DTR again is to first close the device and then reopen it. You cannot restore DTR by simply restoring the baud rate setting. This could be a tricky problem if you've got multiple processes with the device open, as I had. I reported this to ISC about 2 hours after I had 386/ix up, beginning of February. I was porting our communications software. (Which, except for the fact that you cannot do automatic redial or change speeds on some modems, ported otherwise without a hitch; you need to be able to drop DTR to force many modems back into autobaud) First, I went around and around with them trying to convince them that it was a bug. That's because the termio man page only implies this feature by saying that B0 turns off DTR. They don't actually come out and say !B0 turns it on. Every serial driver I've used worked the implied way, except ISC's. So I guess AT&T is 10% negligent in this (even the SVID is loose in this area). Finally, they admitted it is a bug, and would be corrected in "a future release". They didn't say which one, and wouldn't provide a fixed version for us to continue development. This was the beginning of April. We're out of the communications software business at this point. 1.0.5 went by, and they didn't send us a copy, so I assummed the fix wasn't in there. But they did send notification of 1.0.6, and would be shipping us that July 20. Week of August 8th the story is its going out on priority this week. Well, you know the end to this story already. Yep. Still haven't got it. I really think that 386/ix (sans a very few bugs) and VP/ix are the way to go. But the support issue is not for the squeamish. Seems to be a pretty universal problem amongst the UNIX/386 variants. And the one "operation" where support seems to be adequate is pushing the wrong product. VP/ix. Someone said it trashed this -n- that. Must have been a very early release. I've used quite a number of things, quite successfuly. The only DOS programs that failed were ones (I believe) that used the FCB calls to deal with files. They couldn't create files. You had to make empty files first. Games don't work that well that want to tweak the frequency of the timer interrupt. (Incomplete implementation of the Virtual Machine under VP/ix). But no crashes. Alt-SysReq-m always got me back to UNIX from errant DOS programs. My $20,000 question is WILL DOS 4.0 run under VP/ix anytime BEFORE the earths magnetic poles reverse. You can't push DOS under UNIX as an alternative to DOS unless the latest versions are available. -- Rick Richardson, PC Research, Inc. (201) 542-3734 (voice, nights) OR (201) 389-8963 (voice, days) uunet!pcrat!rick (UUCP) rick%pcrat.uucp@uunet.uu.net (INTERNET)