uucp@uclachem.UUCP (Unix-to-Unix copy program) (03/03/88)
Path: uclachem!cepu!trwrb!felix!ccicpg!uunet!littlei!reed!psu-cs!qiclab!neighorn
From: neighorn@qiclab.UUCP (Steve Neighorn)
Newsgroups: comp.sources.wanted,comp.unix.microport
Subject: 'mush' on Microport V/386
Message-ID: <1007@qiclab.UUCP>
Date: 25 Feb 88 03:23:46 GMT
Reply-To: neighorn@qiclab.UUCP (Steve Neighorn)
Organization: Qic Laboratories, Portland, Oregon.
Lines: 11
I would like to hear from anyone who has successfully compiled and
executed the Mail User's Shell (mush) Version 5.7 (Sun Sep 6 1987)
under Microport's V/386 system. I have it running on qiclab (a
4.2 bsd-ish system) but am having an unusual number of problems
getting the code to compile on catlabs (V/386). Thanks in advance
to all you SYS V hackers out there.
--
Steven C. Neighorn !tektronix!{psu-cs,reed,ogcvax}!qiclab!neighorn
Portland Public Schools "Where we train young Star Fighters to defend the
(503) 249-2000 ext 337 frontier against Xur and the Ko-dan Armada"uucp@uclachem.UUCP (Unix-to-Unix copy program) (03/05/88)
Path: uclachem!cepu!trwrb!scgvaxd!wlbr!voder!pyramid!oliveb!ames!mailrus!umix!uunet!mnetor!spectrix!clewis From: clewis@spectrix.UUCP (Chris R. Lewis) Newsgroups: comp.unix.microport,comp.sys.ibm.pc Subject: Re: Uport tape driver ev.o disables line printer Keywords: device interrupts, memory windows Message-ID: <471@spectrix.UUCP> Date: 1 Mar 88 02:51:05 GMT References: <1206@qetzal.UUCP> <446@spectrix.UUCP> <243@oracle.UUCP> <661@anasaz.UUCP> Reply-To: clewis@spectrix.UUCP (Chris R. Lewis) Distribution: comp.unix.microport,comp.sys.ibm.pc Organization: Spectrix Microsystems Inc., Toronto, Ontario, Canada Lines: 70 In article <661@anasaz.UUCP> les@anasaz.UUCP (L. Leslie Biffle) writes: |In article <243@oracle.UUCP> rbradbur@oracle.UUCP (Robert Bradbury) writes: |> |> |>...The point was made that the IBM Micro Channel was designed with a much |>different bus interface to get around this problem and allow exactly |>what Chris Lewis suggests (namely to be able to chain device interrupts |>at the same priority). |> |>I agree that there aren't very many interrupt lines on the PC, the |>question is can you daisy chain them or do you need to get a PS/2? |> | |Yes, the int request lines can be daisy-chained, though it takes |thought on the part of the card designer. Active-high vs. active-low |is not the issue here as much as the physical execution of the |hardware. If the interrupt request line driver on an active-low bus |is not an "open collector" device, the same conflict would exist where |one device desires the signal to be high while another wants it to be |low. | |Our intelligent data comm board uses a PNP transistor to drive the |selected interrupt request line high when an interrupt is desired. |When no board is driving the line high a simple resistor pulls the |line low. This resistor is enabled on the last-or-only board (in the |spirit of the terminator on a disk drive). In this way many of our |boards may share the same interrupt vector, and may coexist with other |boards that do the same. Exactly. Quite a few boards will actually work in such a scheme. IBM hardware treats the interrupt lines ALMOST like upside-down open collector gates - except that there aren't any pull-ups (actually downs) on the mother board. The few real IBM boards I've examined, along with the one I designed, don't use transistors. They use tristate buffers (eg: 74125) who's input is hardwired to ground (or high in an inverting buffer) and you enable the buffer to fire the interrupt. Further, you have to put a pulldown somewhere.... Our solution for multiple cards with the same interrupt was to put a resistor with the highest possible reliable value on each board as a pull-down. If you had only one board, the pull-down was enough. If you had three boards and three simultaneous interrupts, the value was 1/3rd but 74125's have far more than enough drive. We did it this way to eliminate another (error-prone) jumper. Potential problems: 1) you have to be interrupting on *level* not edge. (I know 386/ix uses level - as do most other UNIXes if they have a choice, don't know about messydos) 2) You may be sharing the interrupt with some board that doesn't drive the line properly. One of the nastier things that arise out of this STUPID design of IBM's is that since interrupt lines aren't pulled inactive, you can sometimes get continous interrupts on a line that isn't connected. What makes this worse is that 386/ix's config (uPort too I imagine) does not notice interrupt clashes, nor do they do the "right" thing and create a dummy ISR that calls all clashing *real* ISRs. Multibus I has very few interrupts (if you're using the vast majority of boards that can only autovector but not bus vector) and most systems on Multibus will create a dummy ISR (eg: Tower and Spectrix machines). I'm glad that no IBM'ers were around when I found out this stuff the hard way. GRRRRR!!!!! STUPID IDIOTS! Ruined a perfect first-run of the PC board.... -- Chris Lewis, Spectrix Microsystems Inc, UUCP: {uunet!mnetor, utcsri!utzoo, lsuc, yunexus}!spectrix!clewis Phone: (416)-474-1955
uucp@uclachem.UUCP (Unix-to-Unix copy program) (03/08/88)
Path: uclachem!cepu!trwrb!sdcrdcf!burdvax!udel!rochester!ur-tut!sunybcs!boulder!hao!oddjob!gargoyle!ddsw1!karl From: karl@ddsw1.UUCP (Karl Denninger) Newsgroups: comp.unix.microport Subject: Re: Dosmerge on Bell Technologies 80286 "Engine" Summary: That's a Tatung under the hood! Get Phoenix! Keywords: dosmerge on bell tech engine - who has it running? Message-ID: <830@ddsw1.UUCP> Date: 28 Feb 88 01:43:30 GMT References: <4032@megaron.arizona.edu> Reply-To: karl@ddsw1.UUCP (Karl Denninger) Distribution: usa Organization: Macro Computer Solutions, Inc., Mundelein, IL Lines: 21 In article <4032@megaron.arizona.edu> rupley@arizona.edu (John Rupley) writes: > >I was not able to bring up dos-merge on an 80286 Bell Technologies >"engine". Uport inidicated that this machine was not on the "ok" >list for dos-merge. Has anyone solved this problem, or shown it >not to be a problem? If it's the machine I think it is, you have a Tatung TCS-7000 in someone else's (Bell Tech's) packaging. If this is truly the case (the Motherboard & disk controller will tell all, take a look) then you're in good shape. Call your friendly clone maker and get a set of Phoenix BIOS proms. We've used the Tatung with Phoenix proms and DOS/Merge 286, and it works. Without the Phoenix proms, it blows up during installation. ----- Karl Denninger | Data: +1 312 566-8912 Macro Computer Solutions, Inc. | Voice: +1 312 566-8910 ...ihnp4!ddsw1!karl | "Quality solutions for work or play"
uucp@uclachem.UUCP (Unix-to-Unix copy program) (03/08/88)
Path: uclachem!cepu!trwrb!sdcrdcf!burdvax!bpa!cbmvax!rutgers!husc6!mailrus!umix!uunet!rosevax!ems!pwcs!elric!hawkmoon!det From: det@hawkmoon.UUCP (Derek E. Terveer) Newsgroups: comp.unix.microport Subject: uugetty on '386 systems? Message-ID: <120@hawkmoon.UUCP> Date: 21 Feb 88 00:49:52 GMT Organization: Richfield, Mn, USA Lines: 3 Has anyone managed to get uugetty to work on a uport '386 system? If so, i would be interested in hearing the gorey details... derek
uucp@uclachem.UUCP (Unix-to-Unix copy program) (03/08/88)
Path: uclachem!cepu!trwrb!sdcrdcf!burdvax!bpa!cbmvax!rutgers!rochester!udel!gatech!hao!oddjob!gargoyle!ddsw1!spl1!raj
From: raj@spl1.UUCP (Robert Alan Johnson)
Newsgroups: comp.unix.xenix,comp.unix.microport
Subject: Now That's Service!
Message-ID: <934@spl1.UUCP>
Date: 25 Feb 88 17:54:05 GMT
Reply-To: raj@spl1.UUCP (Robert Alan Johnson)
Organization: The Software Public Library, Inc. Chicago, IL
Lines: 15
With all the vendor flaming going around I thought I'd mention
a good work for SCO again.
I ordered Xenix 386 development system and VP/IX last Friday. They
told me there would be a 3-5 day internal processing delay and then
it would go out ups blue.
On the next Thursday (today) ups arrived with the software, and,
an hour later, I actually got a call from the sales person at SCO
telling me it had shipped on Tuesday.... I thanked him for the call
and let him know it had arrived 1 hour before... NOW THAT'S SERVICE!
Robert A. Johnson, SYSOP UUCP: {ihnp4,ddsw1,ll1!ll1a,laidbak}!spl1!raj
The Software Public Library VOICE: 1 312 248 5777uucp@uclachem.UUCP (Unix-to-Unix copy program) (03/09/88)
Path: uclachem!cepu!trwrb!scgvaxd!wlbr!jplgodo!mahendo!elroy!ames!mailrus!umix!uunet!w3vh!rolfe From: rolfe@w3vh.UUCP (Rolfe Tessem) Newsgroups: comp.unix.microport Subject: Re: MicroPort Unix V/AT Summary: DOSMerge Installation Keywords: Help with 286 DosMerge Message-ID: <308@w3vh.UUCP> Date: 2 Mar 88 13:56:51 GMT References: <2495@ihuxv.ATT.COM> Organization: W3VH Packet Radio Gateway, Great Barrington, MA Lines: 20 In article <2495@ihuxv.ATT.COM>, bareta@ihuxv.ATT.COM (Benyukhis) writes: > > I desperately need help with installing the System V/AT > DosMerge on my PC's Limited 286 machine. It seems to blow up > at the later stages in the installation. After the Dos Image is or > may be is being created it cannot boot of of the hard drive. I followed > the installation manual to the letter twice and could not get the > install to complete. Is it a disk, drive controller? If anyone has > a clue or the answer please respond. I had the same problem with my clone. It turns out that while Unix doesn't really use the BIOS, DOSMerge (as you might expect) is *very* BIOS sensitive. I switched to a Phoenix BIOS and all was well. Contact your friendly clone parts dealer -- should cost about $35.00. -- UUCP: {uunet}!w3vh!rolfe | Rolfe Tessem ARPA: w3vh!rolfe@uunet.UU.NET | P.O. Box 793 PACKET RADIO: W3VH@WA2PVV | Great Barrington, MA 01230
nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) (03/26/88)
Path: sri-spam!ames!pasteur!agate!violet.berkeley.edu!ewv
From: ewv@violet.berkeley.edu (Eric Varsanyi )
Newsgroups: comp.unix.microport
Subject: Intelliport multi-port board comments
Keywords: serial port Computone Intelliport hosed review
Message-ID: <8047@agate.BERKELEY.EDU>
Date: 26 Mar 88 06:33:08 GMT
Sender: usenet@agate.BERKELEY.EDU
Reply-To: ewv@violet.berkeley.edu (Eric Varsanyi )
Organization: Cray Research, Inc.
Lines: 119
I recently had the "pleasure" of installing an 8 port Intelliport
board on my uport 386 system, here are a few hints and tips in case anyone
out there is evaluating this product for their system:
General info
------------
The Computone Intelliport is a 4, 8 or 16 port intelligent serial
board. Up to 4 boards can be installed in a system, giving a theoretical
maximum of 64 ports. The board has an 80186 and some RAM, therefore it
handles all the per character interrupts and only has to interrupt the
386 for full lines of input (At least I hope that's what they did in their
driver, anything else would be a waste. Their manual is devoid of any useful
technical information).
They have a feature that allows you to use terminals with 2 pages of
memory like the console (you can switch between the two pages and have
different sessions on each one). I've been using this feature and its real
handy, there are two entries in /dev for the two virtual screens so its
reasonably transparent to the system. It is possible to confuse the terminal
and end up with the output getting sent to the wrong screens. This feature
is completely programmable, so you can set up any terminal with two pages
of memory (that will switch on some command received from the serial port) to
work with this feature.
They also have a feature that lets you use the printer port on a
terminal via another entry in /dev that is more or less transparent to the
terminal user.
The overall quality of the hardware is good, the board and cables
are sturdy. The jumpers are located so that you have to take the board out
of the system to get to them (they are down near the edge connector).
Problems installing on uport V386
---------------------------------
1) DosMerge does not work
The sales people at Computone claim that you can run applications
such as Wordstar and Paradox. The tech support people claim (correctly) that
the board does not work with DosMerge applications.
2) There is no modem arbitration
There is no arbitration between ttyixx and ttymxx lines (like there
are between tty00 and ttym00 under the standard uport serial driver), therefore
you have to resort to various bogus methods to have a port usable for dialin
and also be able to use it for tip or kermit. (Edit inittab each time, use
(blech!) uugetty, etc...)
3) No working terminfo entries are supplied
Computone tech support recommends that you use their product with
a Wyse 60 terminal, they supply termcap entries (!) to use their board
with a Wyse 60 (the regular one does not work). Since System V does not
support termcap, this does not work too well. Tech support informs me that
no terminfo entries are currently available, and that I use the terminal
in TVI925 mode (Good thing I got this nice AT compatible keyboard for
my Wyse terminal). There are other problems with Wyse 60 mode as well. (later)
I tried to use captoinfo to convert the termcap entry to a terminfo entry with
marginal success, the resulting terminfo entry works ok until you hit ESC
twice in a row, then you end up getting hex representations of what you
type echoed back at you (from god knows where). There's no way out of this,
you have to kill the vi or whatever you were running.
4) The driver hangs intermittently
If a port is opened and there is no board present (the install script
creates /dev/ entries for all possible 64 ports, even if you only have 8),
the process opening will hang (at some wait channel in the driver) until
system reboot. This also happens if you access a port and there is no
terminal plugged into it.
5) Terminals that produce scancodes do not work
Scancode producing terminals (Wyse 60's for instance) will not work
with this product. Turning on scancode recognition has no effect. (Note: You
can still use a Wyse 60 or Kimtron but you have to put it in ASCII mode)
6) Can only be installed on IRQ15
If you have something that uses IRQ15 (like DosMerge) you are out
of luck (This is NOT documented, their tech support told me).
7) Poor Documentation
The documentation was written for SCO Xenix, one page was added
with uport and VP/ix installation instructions. Their install scripts
build your kernel from system.std (if you are using something else you
are out of luck and have to manually install).
8) Tech Support not available for users
Their tech support is not available to end users, you are
directed to call your dealer. The dealer cannot get tech support
either, he is directed to call his distributor. The distributor can
call Computone with technical questions. Most distributors have a nice
warehouse and order taking department. Need I say more?
Conclusions
-----------
The concept and hardware are excellent. The software implementation
for uport (and for vp/ix systems I suspect) is poor. The system will not
install out of the box without a good deal of tinkering. They claim that
all the above problems will be solved with their next revision of the driver
that should be out in about a month. Considering the quality of the software
and the skill of the tech support department with uport systems, I would
judge this to be an immature product for uport systems, not to be bought
unless you are willing to tinker around quite a bit and lose some of the
functionality of your hardware. The tech support person stated that their main
market place was Xenix and maybe they had jumped into the uport and vp/ix
markets too early, I agree.
----------------------------------------------------------------------------
Eric Varsanyi ewv@violet.berkeley.edu
!ucbvax!violet!ewv
Any opinions expressed are mine and are not necessarily those of Cray
----------------------------------------------------------------------------nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) (03/26/88)
Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody
From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user)
Newsgroups: comp.unix.microport
Subject: Submission for comp-unix-microport
Message-ID: <8803260658.AA00132@spam.istc.sri.com>
Date: 26 Mar 88 06:58:43 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 131
Path: sri-spam!ames!pasteur!agate!violet.berkeley.edu!ewv
From: ewv@violet.berkeley.edu (Eric Varsanyi )
Newsgroups: comp.unix.microport
Subject: Intelliport multi-port board comments
Keywords: serial port Computone Intelliport hosed review
Message-ID: <8047@agate.BERKELEY.EDU>
Date: 26 Mar 88 06:33:08 GMT
Sender: usenet@agate.BERKELEY.EDU
Reply-To: ewv@violet.berkeley.edu (Eric Varsanyi )
Organization: Cray Research, Inc.
Lines: 119
I recently had the "pleasure" of installing an 8 port Intelliport
board on my uport 386 system, here are a few hints and tips in case anyone
out there is evaluating this product for their system:
General info
------------
The Computone Intelliport is a 4, 8 or 16 port intelligent serial
board. Up to 4 boards can be installed in a system, giving a theoretical
maximum of 64 ports. The board has an 80186 and some RAM, therefore it
handles all the per character interrupts and only has to interrupt the
386 for full lines of input (At least I hope that's what they did in their
driver, anything else would be a waste. Their manual is devoid of any useful
technical information).
They have a feature that allows you to use terminals with 2 pages of
memory like the console (you can switch between the two pages and have
different sessions on each one). I've been using this feature and its real
handy, there are two entries in /dev for the two virtual screens so its
reasonably transparent to the system. It is possible to confuse the terminal
and end up with the output getting sent to the wrong screens. This feature
is completely programmable, so you can set up any terminal with two pages
of memory (that will switch on some command received from the serial port) to
work with this feature.
They also have a feature that lets you use the printer port on a
terminal via another entry in /dev that is more or less transparent to the
terminal user.
The overall quality of the hardware is good, the board and cables
are sturdy. The jumpers are located so that you have to take the board out
of the system to get to them (they are down near the edge connector).
Problems installing on uport V386
---------------------------------
1) DosMerge does not work
The sales people at Computone claim that you can run applications
such as Wordstar and Paradox. The tech support people claim (correctly) that
the board does not work with DosMerge applications.
2) There is no modem arbitration
There is no arbitration between ttyixx and ttymxx lines (like there
are between tty00 and ttym00 under the standard uport serial driver), therefore
you have to resort to various bogus methods to have a port usable for dialin
and also be able to use it for tip or kermit. (Edit inittab each time, use
(blech!) uugetty, etc...)
3) No working terminfo entries are supplied
Computone tech support recommends that you use their product with
a Wyse 60 terminal, they supply termcap entries (!) to use their board
with a Wyse 60 (the regular one does not work). Since System V does not
support termcap, this does not work too well. Tech support informs me that
no terminfo entries are currently available, and that I use the terminal
in TVI925 mode (Good thing I got this nice AT compatible keyboard for
my Wyse terminal). There are other problems with Wyse 60 mode as well. (later)
I tried to use captoinfo to convert the termcap entry to a terminfo entry with
marginal success, the resulting terminfo entry works ok until you hit ESC
twice in a row, then you end up getting hex representations of what you
type echoed back at you (from god knows where). There's no way out of this,
you have to kill the vi or whatever you were running.
4) The driver hangs intermittently
If a port is opened and there is no board present (the install script
creates /dev/ entries for all possible 64 ports, even if you only have 8),
the process opening will hang (at some wait channel in the driver) until
system reboot. This also happens if you access a port and there is no
terminal plugged into it.
5) Terminals that produce scancodes do not work
Scancode producing terminals (Wyse 60's for instance) will not work
with this product. Turning on scancode recognition has no effect. (Note: You
can still use a Wyse 60 or Kimtron but you have to put it in ASCII mode)
6) Can only be installed on IRQ15
If you have something that uses IRQ15 (like DosMerge) you are out
of luck (This is NOT documented, their tech support told me).
7) Poor Documentation
The documentation was written for SCO Xenix, one page was added
with uport and VP/ix installation instructions. Their install scripts
build your kernel from system.std (if you are using something else you
are out of luck and have to manually install).
8) Tech Support not available for users
Their tech support is not available to end users, you are
directed to call your dealer. The dealer cannot get tech support
either, he is directed to call his distributor. The distributor can
call Computone with technical questions. Most distributors have a nice
warehouse and order taking department. Need I say more?
Conclusions
-----------
The concept and hardware are excellent. The software implementation
for uport (and for vp/ix systems I suspect) is poor. The system will not
install out of the box without a good deal of tinkering. They claim that
all the above problems will be solved with their next revision of the driver
that should be out in about a month. Considering the quality of the software
and the skill of the tech support department with uport systems, I would
judge this to be an immature product for uport systems, not to be bought
unless you are willing to tinker around quite a bit and lose some of the
functionality of your hardware. The tech support person stated that their main
market place was Xenix and maybe they had jumped into the uport and vp/ix
markets too early, I agree.
----------------------------------------------------------------------------
Eric Varsanyi ewv@violet.berkeley.edu
!ucbvax!violet!ewv
Any opinions expressed are mine and are not necessarily those of Cray
----------------------------------------------------------------------------nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) (03/26/88)
Path: sri-spam!ames!pacbell!att-ih!att-cb!clyde!wtr@moss.ATT.COM From: wtr@moss.ATT.COM Newsgroups: comp.unix.microport Subject: GnuEmacs on SV/AT Keywords: %$#^% segmented arch Message-ID: <23842@clyde.ATT.COM> Date: 25 Mar 88 19:28:41 GMT Sender: jlc@clyde.ATT.COM Lines: 40 This is the next in the continuing requests on porting information for SV/AT (2.3-L) A friend of mine has GnuEmacs on his ATT-3B1. He has offered to download it to my machine. Before I spent 5 hours of phone time, could someone tell me if it's at all possible to get this code running under microport? --------- Regarding GCC on SV/AT: All responses have have been negative, because of 16 bit limitation and segments :-(. Most common advice seems to be inquire into Greenhill about their C compiler. Is it out of Beta-testing yet? What do you do to be a Beta-site (I do a fair amount of large system compiling, graphics routines, etc... and would be grateful to do extra testing on a decent compiler :-). Please e-mail any info you have on Greenhill availability. --------- Last question: (gawd do i have a lot of them ! ;-) Has anyone out there with a Sperry-IT gotten the ROM upgrade, and did it make any difference in the performance of SV/AT? (ie: fewer core dumps, etc...)? Thanx for all the help! ===================================================================== Bill Rankin Bell Labs, Whippany NJ (201) 386-4154 (cornet 232) email address: ...![ ihnp4 ulysses cbosgd allegra ]!moss!wtr ...![ ihnp4 cbosgd akgua watmath ]!clyde!wtr =====================================================================
nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) (03/26/88)
Path: sri-spam!sri-unix!husc6!ncar!ames!pacbell!att-ih!att-cb!clyde!wtr@moss.ATT.COM From: wtr@moss.ATT.COM Newsgroups: comp.unix.microport Subject: GnuEmacs on SV/AT Keywords: %$#^% segmented arch Message-ID: <23842@clyde.ATT.COM> Date: 25 Mar 88 19:28:41 GMT Sender: jlc@clyde.ATT.COM Lines: 40 This is the next in the continuing requests on porting information for SV/AT (2.3-L) A friend of mine has GnuEmacs on his ATT-3B1. He has offered to download it to my machine. Before I spent 5 hours of phone time, could someone tell me if it's at all possible to get this code running under microport? --------- Regarding GCC on SV/AT: All responses have have been negative, because of 16 bit limitation and segments :-(. Most common advice seems to be inquire into Greenhill about their C compiler. Is it out of Beta-testing yet? What do you do to be a Beta-site (I do a fair amount of large system compiling, graphics routines, etc... and would be grateful to do extra testing on a decent compiler :-). Please e-mail any info you have on Greenhill availability. --------- Last question: (gawd do i have a lot of them ! ;-) Has anyone out there with a Sperry-IT gotten the ROM upgrade, and did it make any difference in the performance of SV/AT? (ie: fewer core dumps, etc...)? Thanx for all the help! ===================================================================== Bill Rankin Bell Labs, Whippany NJ (201) 386-4154 (cornet 232) email address: ...![ ihnp4 ulysses cbosgd allegra ]!moss!wtr ...![ ihnp4 cbosgd akgua watmath ]!clyde!wtr =====================================================================
nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) (03/26/88)
Path: sri-spam!sri-unix!husc6!uwvax!oddjob!ncar!ames!pasteur!agate!violet.berkeley.edu!ewv
From: ewv@violet.berkeley.edu (Eric Varsanyi )
Newsgroups: comp.unix.microport
Subject: Intelliport multi-port board comments
Keywords: serial port Computone Intelliport hosed review
Message-ID: <8047@agate.BERKELEY.EDU>
Date: 26 Mar 88 06:33:08 GMT
Sender: usenet@agate.BERKELEY.EDU
Reply-To: ewv@violet.berkeley.edu (Eric Varsanyi )
Organization: Cray Research, Inc.
Lines: 119
I recently had the "pleasure" of installing an 8 port Intelliport
board on my uport 386 system, here are a few hints and tips in case anyone
out there is evaluating this product for their system:
General info
------------
The Computone Intelliport is a 4, 8 or 16 port intelligent serial
board. Up to 4 boards can be installed in a system, giving a theoretical
maximum of 64 ports. The board has an 80186 and some RAM, therefore it
handles all the per character interrupts and only has to interrupt the
386 for full lines of input (At least I hope that's what they did in their
driver, anything else would be a waste. Their manual is devoid of any useful
technical information).
They have a feature that allows you to use terminals with 2 pages of
memory like the console (you can switch between the two pages and have
different sessions on each one). I've been using this feature and its real
handy, there are two entries in /dev for the two virtual screens so its
reasonably transparent to the system. It is possible to confuse the terminal
and end up with the output getting sent to the wrong screens. This feature
is completely programmable, so you can set up any terminal with two pages
of memory (that will switch on some command received from the serial port) to
work with this feature.
They also have a feature that lets you use the printer port on a
terminal via another entry in /dev that is more or less transparent to the
terminal user.
The overall quality of the hardware is good, the board and cables
are sturdy. The jumpers are located so that you have to take the board out
of the system to get to them (they are down near the edge connector).
Problems installing on uport V386
---------------------------------
1) DosMerge does not work
The sales people at Computone claim that you can run applications
such as Wordstar and Paradox. The tech support people claim (correctly) that
the board does not work with DosMerge applications.
2) There is no modem arbitration
There is no arbitration between ttyixx and ttymxx lines (like there
are between tty00 and ttym00 under the standard uport serial driver), therefore
you have to resort to various bogus methods to have a port usable for dialin
and also be able to use it for tip or kermit. (Edit inittab each time, use
(blech!) uugetty, etc...)
3) No working terminfo entries are supplied
Computone tech support recommends that you use their product with
a Wyse 60 terminal, they supply termcap entries (!) to use their board
with a Wyse 60 (the regular one does not work). Since System V does not
support termcap, this does not work too well. Tech support informs me that
no terminfo entries are currently available, and that I use the terminal
in TVI925 mode (Good thing I got this nice AT compatible keyboard for
my Wyse terminal). There are other problems with Wyse 60 mode as well. (later)
I tried to use captoinfo to convert the termcap entry to a terminfo entry with
marginal success, the resulting terminfo entry works ok until you hit ESC
twice in a row, then you end up getting hex representations of what you
type echoed back at you (from god knows where). There's no way out of this,
you have to kill the vi or whatever you were running.
4) The driver hangs intermittently
If a port is opened and there is no board present (the install script
creates /dev/ entries for all possible 64 ports, even if you only have 8),
the process opening will hang (at some wait channel in the driver) until
system reboot. This also happens if you access a port and there is no
terminal plugged into it.
5) Terminals that produce scancodes do not work
Scancode producing terminals (Wyse 60's for instance) will not work
with this product. Turning on scancode recognition has no effect. (Note: You
can still use a Wyse 60 or Kimtron but you have to put it in ASCII mode)
6) Can only be installed on IRQ15
If you have something that uses IRQ15 (like DosMerge) you are out
of luck (This is NOT documented, their tech support told me).
7) Poor Documentation
The documentation was written for SCO Xenix, one page was added
with uport and VP/ix installation instructions. Their install scripts
build your kernel from system.std (if you are using something else you
are out of luck and have to manually install).
8) Tech Support not available for users
Their tech support is not available to end users, you are
directed to call your dealer. The dealer cannot get tech support
either, he is directed to call his distributor. The distributor can
call Computone with technical questions. Most distributors have a nice
warehouse and order taking department. Need I say more?
Conclusions
-----------
The concept and hardware are excellent. The software implementation
for uport (and for vp/ix systems I suspect) is poor. The system will not
install out of the box without a good deal of tinkering. They claim that
all the above problems will be solved with their next revision of the driver
that should be out in about a month. Considering the quality of the software
and the skill of the tech support department with uport systems, I would
judge this to be an immature product for uport systems, not to be bought
unless you are willing to tinker around quite a bit and lose some of the
functionality of your hardware. The tech support person stated that their main
market place was Xenix and maybe they had jumped into the uport and vp/ix
markets too early, I agree.
----------------------------------------------------------------------------
Eric Varsanyi ewv@violet.berkeley.edu
!ucbvax!violet!ewv
Any opinions expressed are mine and are not necessarily those of Cray
----------------------------------------------------------------------------nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) (03/26/88)
Path: sri-spam!sri-unix!husc6!uwvax!oddjob!ncar!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody
From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user)
Newsgroups: comp.unix.microport
Subject: Submission for comp-unix-microport
Message-ID: <8803260658.AA00132@spam.istc.sri.com>
Date: 26 Mar 88 06:58:43 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 131
Path: sri-spam!ames!pasteur!agate!violet.berkeley.edu!ewv
From: ewv@violet.berkeley.edu (Eric Varsanyi )
Newsgroups: comp.unix.microport
Subject: Intelliport multi-port board comments
Keywords: serial port Computone Intelliport hosed review
Message-ID: <8047@agate.BERKELEY.EDU>
Date: 26 Mar 88 06:33:08 GMT
Sender: usenet@agate.BERKELEY.EDU
Reply-To: ewv@violet.berkeley.edu (Eric Varsanyi )
Organization: Cray Research, Inc.
Lines: 119
I recently had the "pleasure" of installing an 8 port Intelliport
board on my uport 386 system, here are a few hints and tips in case anyone
out there is evaluating this product for their system:
General info
------------
The Computone Intelliport is a 4, 8 or 16 port intelligent serial
board. Up to 4 boards can be installed in a system, giving a theoretical
maximum of 64 ports. The board has an 80186 and some RAM, therefore it
handles all the per character interrupts and only has to interrupt the
386 for full lines of input (At least I hope that's what they did in their
driver, anything else would be a waste. Their manual is devoid of any useful
technical information).
They have a feature that allows you to use terminals with 2 pages of
memory like the console (you can switch between the two pages and have
different sessions on each one). I've been using this feature and its real
handy, there are two entries in /dev for the two virtual screens so its
reasonably transparent to the system. It is possible to confuse the terminal
and end up with the output getting sent to the wrong screens. This feature
is completely programmable, so you can set up any terminal with two pages
of memory (that will switch on some command received from the serial port) to
work with this feature.
They also have a feature that lets you use the printer port on a
terminal via another entry in /dev that is more or less transparent to the
terminal user.
The overall quality of the hardware is good, the board and cables
are sturdy. The jumpers are located so that you have to take the board out
of the system to get to them (they are down near the edge connector).
Problems installing on uport V386
---------------------------------
1) DosMerge does not work
The sales people at Computone claim that you can run applications
such as Wordstar and Paradox. The tech support people claim (correctly) that
the board does not work with DosMerge applications.
2) There is no modem arbitration
There is no arbitration between ttyixx and ttymxx lines (like there
are between tty00 and ttym00 under the standard uport serial driver), therefore
you have to resort to various bogus methods to have a port usable for dialin
and also be able to use it for tip or kermit. (Edit inittab each time, use
(blech!) uugetty, etc...)
3) No working terminfo entries are supplied
Computone tech support recommends that you use their product with
a Wyse 60 terminal, they supply termcap entries (!) to use their board
with a Wyse 60 (the regular one does not work). Since System V does not
support termcap, this does not work too well. Tech support informs me that
no terminfo entries are currently available, and that I use the terminal
in TVI925 mode (Good thing I got this nice AT compatible keyboard for
my Wyse terminal). There are other problems with Wyse 60 mode as well. (later)
I tried to use captoinfo to convert the termcap entry to a terminfo entry with
marginal success, the resulting terminfo entry works ok until you hit ESC
twice in a row, then you end up getting hex representations of what you
type echoed back at you (from god knows where). There's no way out of this,
you have to kill the vi or whatever you were running.
4) The driver hangs intermittently
If a port is opened and there is no board present (the install script
creates /dev/ entries for all possible 64 ports, even if you only have 8),
the process opening will hang (at some wait channel in the driver) until
system reboot. This also happens if you access a port and there is no
terminal plugged into it.
5) Terminals that produce scancodes do not work
Scancode producing terminals (Wyse 60's for instance) will not work
with this product. Turning on scancode recognition has no effect. (Note: You
can still use a Wyse 60 or Kimtron but you have to put it in ASCII mode)
6) Can only be installed on IRQ15
If you have something that uses IRQ15 (like DosMerge) you are out
of luck (This is NOT documented, their tech support told me).
7) Poor Documentation
The documentation was written for SCO Xenix, one page was added
with uport and VP/ix installation instructions. Their install scripts
build your kernel from system.std (if you are using something else you
are out of luck and have to manually install).
8) Tech Support not available for users
Their tech support is not available to end users, you are
directed to call your dealer. The dealer cannot get tech support
either, he is directed to call his distributor. The distributor can
call Computone with technical questions. Most distributors have a nice
warehouse and order taking department. Need I say more?
Conclusions
-----------
The concept and hardware are excellent. The software implementation
for uport (and for vp/ix systems I suspect) is poor. The system will not
install out of the box without a good deal of tinkering. They claim that
all the above problems will be solved with their next revision of the driver
that should be out in about a month. Considering the quality of the software
and the skill of the tech support department with uport systems, I would
judge this to be an immature product for uport systems, not to be bought
unless you are willing to tinker around quite a bit and lose some of the
functionality of your hardware. The tech support person stated that their main
market place was Xenix and maybe they had jumped into the uport and vp/ix
markets too early, I agree.
----------------------------------------------------------------------------
Eric Varsanyi ewv@violet.berkeley.edu
!ucbvax!violet!ewv
Any opinions expressed are mine and are not necessarily those of Cray
----------------------------------------------------------------------------nobody@spam.istc.sri.COM (Unpriviledged user) (03/27/88)
Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody
From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user)
Newsgroups: comp.unix.microport
Subject: Submission for comp-unix-microport
Message-ID: <8803260715.AA00303@spam.istc.sri.com>
Date: 26 Mar 88 07:15:53 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Lines: 140
Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody
From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user)
Newsgroups: comp.unix.microport
Subject: Submission for comp-unix-microport
Message-ID: <8803260658.AA00132@spam.istc.sri.com>
Date: 26 Mar 88 06:58:43 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 131
Path: sri-spam!ames!pasteur!agate!violet.berkeley.edu!ewv
From: ewv@violet.berkeley.edu (Eric Varsanyi )
Newsgroups: comp.unix.microport
Subject: Intelliport multi-port board comments
Keywords: serial port Computone Intelliport hosed review
Message-ID: <8047@agate.BERKELEY.EDU>
Date: 26 Mar 88 06:33:08 GMT
Sender: usenet@agate.BERKELEY.EDU
Reply-To: ewv@violet.berkeley.edu (Eric Varsanyi )
Organization: Cray Research, Inc.
Lines: 119
I recently had the "pleasure" of installing an 8 port Intelliport
board on my uport 386 system, here are a few hints and tips in case anyone
out there is evaluating this product for their system:
General info
------------
The Computone Intelliport is a 4, 8 or 16 port intelligent serial
board. Up to 4 boards can be installed in a system, giving a theoretical
maximum of 64 ports. The board has an 80186 and some RAM, therefore it
handles all the per character interrupts and only has to interrupt the
386 for full lines of input (At least I hope that's what they did in their
driver, anything else would be a waste. Their manual is devoid of any useful
technical information).
They have a feature that allows you to use terminals with 2 pages of
memory like the console (you can switch between the two pages and have
different sessions on each one). I've been using this feature and its real
handy, there are two entries in /dev for the two virtual screens so its
reasonably transparent to the system. It is possible to confuse the terminal
and end up with the output getting sent to the wrong screens. This feature
is completely programmable, so you can set up any terminal with two pages
of memory (that will switch on some command received from the serial port) to
work with this feature.
They also have a feature that lets you use the printer port on a
terminal via another entry in /dev that is more or less transparent to the
terminal user.
The overall quality of the hardware is good, the board and cables
are sturdy. The jumpers are located so that you have to take the board out
of the system to get to them (they are down near the edge connector).
Problems installing on uport V386
---------------------------------
1) DosMerge does not work
The sales people at Computone claim that you can run applications
such as Wordstar and Paradox. The tech support people claim (correctly) that
the board does not work with DosMerge applications.
2) There is no modem arbitration
There is no arbitration between ttyixx and ttymxx lines (like there
are between tty00 and ttym00 under the standard uport serial driver), therefore
you have to resort to various bogus methods to have a port usable for dialin
and also be able to use it for tip or kermit. (Edit inittab each time, use
(blech!) uugetty, etc...)
3) No working terminfo entries are supplied
Computone tech support recommends that you use their product with
a Wyse 60 terminal, they supply termcap entries (!) to use their board
with a Wyse 60 (the regular one does not work). Since System V does not
support termcap, this does not work too well. Tech support informs me that
no terminfo entries are currently available, and that I use the terminal
in TVI925 mode (Good thing I got this nice AT compatible keyboard for
my Wyse terminal). There are other problems with Wyse 60 mode as well. (later)
I tried to use captoinfo to convert the termcap entry to a terminfo entry with
marginal success, the resulting terminfo entry works ok until you hit ESC
twice in a row, then you end up getting hex representations of what you
type echoed back at you (from god knows where). There's no way out of this,
you have to kill the vi or whatever you were running.
4) The driver hangs intermittently
If a port is opened and there is no board present (the install script
creates /dev/ entries for all possible 64 ports, even if you only have 8),
the process opening will hang (at some wait channel in the driver) until
system reboot. This also happens if you access a port and there is no
terminal plugged into it.
5) Terminals that produce scancodes do not work
Scancode producing terminals (Wyse 60's for instance) will not work
with this product. Turning on scancode recognition has no effect. (Note: You
can still use a Wyse 60 or Kimtron but you have to put it in ASCII mode)
6) Can only be installed on IRQ15
If you have something that uses IRQ15 (like DosMerge) you are out
of luck (This is NOT documented, their tech support told me).
7) Poor Documentation
The documentation was written for SCO Xenix, one page was added
with uport and VP/ix installation instructions. Their install scripts
build your kernel from system.std (if you are using something else you
are out of luck and have to manually install).
8) Tech Support not available for users
Their tech support is not available to end users, you are
directed to call your dealer. The dealer cannot get tech support
either, he is directed to call his distributor. The distributor can
call Computone with technical questions. Most distributors have a nice
warehouse and order taking department. Need I say more?
Conclusions
-----------
The concept and hardware are excellent. The software implementation
for uport (and for vp/ix systems I suspect) is poor. The system will not
install out of the box without a good deal of tinkering. They claim that
all the above problems will be solved with their next revision of the driver
that should be out in about a month. Considering the quality of the software
and the skill of the tech support department with uport systems, I would
judge this to be an immature product for uport systems, not to be bought
unless you are willing to tinker around quite a bit and lose some of the
functionality of your hardware. The tech support person stated that their main
market place was Xenix and maybe they had jumped into the uport and vp/ix
markets too early, I agree.
----------------------------------------------------------------------------
Eric Varsanyi ewv@violet.berkeley.edu
!ucbvax!violet!ewv
Any opinions expressed are mine and are not necessarily those of Cray
----------------------------------------------------------------------------nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) (03/27/88)
Path: sri-spam!ames!pasteur!ucbvax!spam.istc.sri.COM!nobody
From: nobody@spam.istc.sri.COM (Unpriviledged user)
Newsgroups: comp.unix.microport
Subject: Submission for comp-unix-microport
Message-ID: <8803262012.AA03230@spam.istc.sri.com>
Date: 26 Mar 88 20:11:58 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 149
Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody
From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user)
Newsgroups: comp.unix.microport
Subject: Submission for comp-unix-microport
Message-ID: <8803260715.AA00303@spam.istc.sri.com>
Date: 26 Mar 88 07:15:53 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Lines: 140
Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody
From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user)
Newsgroups: comp.unix.microport
Subject: Submission for comp-unix-microport
Message-ID: <8803260658.AA00132@spam.istc.sri.com>
Date: 26 Mar 88 06:58:43 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 131
Path: sri-spam!ames!pasteur!agate!violet.berkeley.edu!ewv
From: ewv@violet.berkeley.edu (Eric Varsanyi )
Newsgroups: comp.unix.microport
Subject: Intelliport multi-port board comments
Keywords: serial port Computone Intelliport hosed review
Message-ID: <8047@agate.BERKELEY.EDU>
Date: 26 Mar 88 06:33:08 GMT
Sender: usenet@agate.BERKELEY.EDU
Reply-To: ewv@violet.berkeley.edu (Eric Varsanyi )
Organization: Cray Research, Inc.
Lines: 119
I recently had the "pleasure" of installing an 8 port Intelliport
board on my uport 386 system, here are a few hints and tips in case anyone
out there is evaluating this product for their system:
General info
------------
The Computone Intelliport is a 4, 8 or 16 port intelligent serial
board. Up to 4 boards can be installed in a system, giving a theoretical
maximum of 64 ports. The board has an 80186 and some RAM, therefore it
handles all the per character interrupts and only has to interrupt the
386 for full lines of input (At least I hope that's what they did in their
driver, anything else would be a waste. Their manual is devoid of any useful
technical information).
They have a feature that allows you to use terminals with 2 pages of
memory like the console (you can switch between the two pages and have
different sessions on each one). I've been using this feature and its real
handy, there are two entries in /dev for the two virtual screens so its
reasonably transparent to the system. It is possible to confuse the terminal
and end up with the output getting sent to the wrong screens. This feature
is completely programmable, so you can set up any terminal with two pages
of memory (that will switch on some command received from the serial port) to
work with this feature.
They also have a feature that lets you use the printer port on a
terminal via another entry in /dev that is more or less transparent to the
terminal user.
The overall quality of the hardware is good, the board and cables
are sturdy. The jumpers are located so that you have to take the board out
of the system to get to them (they are down near the edge connector).
Problems installing on uport V386
---------------------------------
1) DosMerge does not work
The sales people at Computone claim that you can run applications
such as Wordstar and Paradox. The tech support people claim (correctly) that
the board does not work with DosMerge applications.
2) There is no modem arbitration
There is no arbitration between ttyixx and ttymxx lines (like there
are between tty00 and ttym00 under the standard uport serial driver), therefore
you have to resort to various bogus methods to have a port usable for dialin
and also be able to use it for tip or kermit. (Edit inittab each time, use
(blech!) uugetty, etc...)
3) No working terminfo entries are supplied
Computone tech support recommends that you use their product with
a Wyse 60 terminal, they supply termcap entries (!) to use their board
with a Wyse 60 (the regular one does not work). Since System V does not
support termcap, this does not work too well. Tech support informs me that
no terminfo entries are currently available, and that I use the terminal
in TVI925 mode (Good thing I got this nice AT compatible keyboard for
my Wyse terminal). There are other problems with Wyse 60 mode as well. (later)
I tried to use captoinfo to convert the termcap entry to a terminfo entry with
marginal success, the resulting terminfo entry works ok until you hit ESC
twice in a row, then you end up getting hex representations of what you
type echoed back at you (from god knows where). There's no way out of this,
you have to kill the vi or whatever you were running.
4) The driver hangs intermittently
If a port is opened and there is no board present (the install script
creates /dev/ entries for all possible 64 ports, even if you only have 8),
the process opening will hang (at some wait channel in the driver) until
system reboot. This also happens if you access a port and there is no
terminal plugged into it.
5) Terminals that produce scancodes do not work
Scancode producing terminals (Wyse 60's for instance) will not work
with this product. Turning on scancode recognition has no effect. (Note: You
can still use a Wyse 60 or Kimtron but you have to put it in ASCII mode)
6) Can only be installed on IRQ15
If you have something that uses IRQ15 (like DosMerge) you are out
of luck (This is NOT documented, their tech support told me).
7) Poor Documentation
The documentation was written for SCO Xenix, one page was added
with uport and VP/ix installation instructions. Their install scripts
build your kernel from system.std (if you are using something else you
are out of luck and have to manually install).
8) Tech Support not available for users
Their tech support is not available to end users, you are
directed to call your dealer. The dealer cannot get tech support
either, he is directed to call his distributor. The distributor can
call Computone with technical questions. Most distributors have a nice
warehouse and order taking department. Need I say more?
Conclusions
-----------
The concept and hardware are excellent. The software implementation
for uport (and for vp/ix systems I suspect) is poor. The system will not
install out of the box without a good deal of tinkering. They claim that
all the above problems will be solved with their next revision of the driver
that should be out in about a month. Considering the quality of the software
and the skill of the tech support department with uport systems, I would
judge this to be an immature product for uport systems, not to be bought
unless you are willing to tinker around quite a bit and lose some of the
functionality of your hardware. The tech support person stated that their main
market place was Xenix and maybe they had jumped into the uport and vp/ix
markets too early, I agree.
----------------------------------------------------------------------------
Eric Varsanyi ewv@violet.berkeley.edu
!ucbvax!violet!ewv
Any opinions expressed are mine and are not necessarily those of Cray
----------------------------------------------------------------------------nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) (03/27/88)
Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803260952.AA00893@spam.istc.sri.com> Date: 26 Mar 88 09:52:12 GMT Sender: usenet@ucbvax.BERKELEY.EDU Lines: 50 Path: sri-spam!ames!pacbell!att-ih!att-cb!clyde!wtr@moss.ATT.COM From: wtr@moss.ATT.COM Newsgroups: comp.unix.microport Subject: GnuEmacs on SV/AT Keywords: %$#^% segmented arch Message-ID: <23842@clyde.ATT.COM> Date: 25 Mar 88 19:28:41 GMT Sender: jlc@clyde.ATT.COM Lines: 40 This is the next in the continuing requests on porting information for SV/AT (2.3-L) A friend of mine has GnuEmacs on his ATT-3B1. He has offered to download it to my machine. Before I spent 5 hours of phone time, could someone tell me if it's at all possible to get this code running under microport? --------- Regarding GCC on SV/AT: All responses have have been negative, because of 16 bit limitation and segments :-(. Most common advice seems to be inquire into Greenhill about their C compiler. Is it out of Beta-testing yet? What do you do to be a Beta-site (I do a fair amount of large system compiling, graphics routines, etc... and would be grateful to do extra testing on a decent compiler :-). Please e-mail any info you have on Greenhill availability. --------- Last question: (gawd do i have a lot of them ! ;-) Has anyone out there with a Sperry-IT gotten the ROM upgrade, and did it make any difference in the performance of SV/AT? (ie: fewer core dumps, etc...)? Thanx for all the help! ===================================================================== Bill Rankin Bell Labs, Whippany NJ (201) 386-4154 (cornet 232) email address: ...![ ihnp4 ulysses cbosgd allegra ]!moss!wtr ...![ ihnp4 cbosgd akgua watmath ]!clyde!wtr =====================================================================
nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) (03/27/88)
Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270132.AA04179@spam.istc.sri.com> Date: 27 Mar 88 01:32:17 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 59 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803260952.AA00893@spam.istc.sri.com> Date: 26 Mar 88 09:52:12 GMT Sender: usenet@ucbvax.BERKELEY.EDU Lines: 50 Path: sri-spam!ames!pacbell!att-ih!att-cb!clyde!wtr@moss.ATT.COM From: wtr@moss.ATT.COM Newsgroups: comp.unix.microport Subject: GnuEmacs on SV/AT Keywords: %$#^% segmented arch Message-ID: <23842@clyde.ATT.COM> Date: 25 Mar 88 19:28:41 GMT Sender: jlc@clyde.ATT.COM Lines: 40 This is the next in the continuing requests on porting information for SV/AT (2.3-L) A friend of mine has GnuEmacs on his ATT-3B1. He has offered to download it to my machine. Before I spent 5 hours of phone time, could someone tell me if it's at all possible to get this code running under microport? --------- Regarding GCC on SV/AT: All responses have have been negative, because of 16 bit limitation and segments :-(. Most common advice seems to be inquire into Greenhill about their C compiler. Is it out of Beta-testing yet? What do you do to be a Beta-site (I do a fair amount of large system compiling, graphics routines, etc... and would be grateful to do extra testing on a decent compiler :-). Please e-mail any info you have on Greenhill availability. --------- Last question: (gawd do i have a lot of them ! ;-) Has anyone out there with a Sperry-IT gotten the ROM upgrade, and did it make any difference in the performance of SV/AT? (ie: fewer core dumps, etc...)? Thanx for all the help! ===================================================================== Bill Rankin Bell Labs, Whippany NJ (201) 386-4154 (cornet 232) email address: ...![ ihnp4 ulysses cbosgd allegra ]!moss!wtr ...![ ihnp4 cbosgd akgua watmath ]!clyde!wtr =====================================================================
nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) (03/27/88)
Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270153.AA04227@spam.istc.sri.com> Date: 27 Mar 88 01:53:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 68 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270132.AA04179@spam.istc.sri.com> Date: 27 Mar 88 01:32:17 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 59 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803260952.AA00893@spam.istc.sri.com> Date: 26 Mar 88 09:52:12 GMT Sender: usenet@ucbvax.BERKELEY.EDU Lines: 50 Path: sri-spam!ames!pacbell!att-ih!att-cb!clyde!wtr@moss.ATT.COM From: wtr@moss.ATT.COM Newsgroups: comp.unix.microport Subject: GnuEmacs on SV/AT Keywords: %$#^% segmented arch Message-ID: <23842@clyde.ATT.COM> Date: 25 Mar 88 19:28:41 GMT Sender: jlc@clyde.ATT.COM Lines: 40 This is the next in the continuing requests on porting information for SV/AT (2.3-L) A friend of mine has GnuEmacs on his ATT-3B1. He has offered to download it to my machine. Before I spent 5 hours of phone time, could someone tell me if it's at all possible to get this code running under microport? --------- Regarding GCC on SV/AT: All responses have have been negative, because of 16 bit limitation and segments :-(. Most common advice seems to be inquire into Greenhill about their C compiler. Is it out of Beta-testing yet? What do you do to be a Beta-site (I do a fair amount of large system compiling, graphics routines, etc... and would be grateful to do extra testing on a decent compiler :-). Please e-mail any info you have on Greenhill availability. --------- Last question: (gawd do i have a lot of them ! ;-) Has anyone out there with a Sperry-IT gotten the ROM upgrade, and did it make any difference in the performance of SV/AT? (ie: fewer core dumps, etc...)? Thanx for all the help! ===================================================================== Bill Rankin Bell Labs, Whippany NJ (201) 386-4154 (cornet 232) email address: ...![ ihnp4 ulysses cbosgd allegra ]!moss!wtr ...![ ihnp4 cbosgd akgua watmath ]!clyde!wtr =====================================================================
nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) (03/27/88)
Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270212.AA04261@spam.istc.sri.com> Date: 27 Mar 88 02:12:21 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 77 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270153.AA04227@spam.istc.sri.com> Date: 27 Mar 88 01:53:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 68 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270132.AA04179@spam.istc.sri.com> Date: 27 Mar 88 01:32:17 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 59 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803260952.AA00893@spam.istc.sri.com> Date: 26 Mar 88 09:52:12 GMT Sender: usenet@ucbvax.BERKELEY.EDU Lines: 50 Path: sri-spam!ames!pacbell!att-ih!att-cb!clyde!wtr@moss.ATT.COM From: wtr@moss.ATT.COM Newsgroups: comp.unix.microport Subject: GnuEmacs on SV/AT Keywords: %$#^% segmented arch Message-ID: <23842@clyde.ATT.COM> Date: 25 Mar 88 19:28:41 GMT Sender: jlc@clyde.ATT.COM Lines: 40 This is the next in the continuing requests on porting information for SV/AT (2.3-L) A friend of mine has GnuEmacs on his ATT-3B1. He has offered to download it to my machine. Before I spent 5 hours of phone time, could someone tell me if it's at all possible to get this code running under microport? --------- Regarding GCC on SV/AT: All responses have have been negative, because of 16 bit limitation and segments :-(. Most common advice seems to be inquire into Greenhill about their C compiler. Is it out of Beta-testing yet? What do you do to be a Beta-site (I do a fair amount of large system compiling, graphics routines, etc... and would be grateful to do extra testing on a decent compiler :-). Please e-mail any info you have on Greenhill availability. --------- Last question: (gawd do i have a lot of them ! ;-) Has anyone out there with a Sperry-IT gotten the ROM upgrade, and did it make any difference in the performance of SV/AT? (ie: fewer core dumps, etc...)? Thanx for all the help! ===================================================================== Bill Rankin Bell Labs, Whippany NJ (201) 386-4154 (cornet 232) email address: ...![ ihnp4 ulysses cbosgd allegra ]!moss!wtr ...![ ihnp4 cbosgd akgua watmath ]!clyde!wtr =====================================================================
nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) (03/27/88)
Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270230.AA04292@spam.istc.sri.com> Date: 27 Mar 88 02:30:55 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 86 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270212.AA04261@spam.istc.sri.com> Date: 27 Mar 88 02:12:21 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 77 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270153.AA04227@spam.istc.sri.com> Date: 27 Mar 88 01:53:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 68 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270132.AA04179@spam.istc.sri.com> Date: 27 Mar 88 01:32:17 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 59 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803260952.AA00893@spam.istc.sri.com> Date: 26 Mar 88 09:52:12 GMT Sender: usenet@ucbvax.BERKELEY.EDU Lines: 50 Path: sri-spam!ames!pacbell!att-ih!att-cb!clyde!wtr@moss.ATT.COM From: wtr@moss.ATT.COM Newsgroups: comp.unix.microport Subject: GnuEmacs on SV/AT Keywords: %$#^% segmented arch Message-ID: <23842@clyde.ATT.COM> Date: 25 Mar 88 19:28:41 GMT Sender: jlc@clyde.ATT.COM Lines: 40 This is the next in the continuing requests on porting information for SV/AT (2.3-L) A friend of mine has GnuEmacs on his ATT-3B1. He has offered to download it to my machine. Before I spent 5 hours of phone time, could someone tell me if it's at all possible to get this code running under microport? --------- Regarding GCC on SV/AT: All responses have have been negative, because of 16 bit limitation and segments :-(. Most common advice seems to be inquire into Greenhill about their C compiler. Is it out of Beta-testing yet? What do you do to be a Beta-site (I do a fair amount of large system compiling, graphics routines, etc... and would be grateful to do extra testing on a decent compiler :-). Please e-mail any info you have on Greenhill availability. --------- Last question: (gawd do i have a lot of them ! ;-) Has anyone out there with a Sperry-IT gotten the ROM upgrade, and did it make any difference in the performance of SV/AT? (ie: fewer core dumps, etc...)? Thanx for all the help! ===================================================================== Bill Rankin Bell Labs, Whippany NJ (201) 386-4154 (cornet 232) email address: ...![ ihnp4 ulysses cbosgd allegra ]!moss!wtr ...![ ihnp4 cbosgd akgua watmath ]!clyde!wtr =====================================================================
nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) (03/27/88)
Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270252.AA04331@spam.istc.sri.com> Date: 27 Mar 88 02:52:57 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 95 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270230.AA04292@spam.istc.sri.com> Date: 27 Mar 88 02:30:55 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 86 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270212.AA04261@spam.istc.sri.com> Date: 27 Mar 88 02:12:21 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 77 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270153.AA04227@spam.istc.sri.com> Date: 27 Mar 88 01:53:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 68 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270132.AA04179@spam.istc.sri.com> Date: 27 Mar 88 01:32:17 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 59 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803260952.AA00893@spam.istc.sri.com> Date: 26 Mar 88 09:52:12 GMT Sender: usenet@ucbvax.BERKELEY.EDU Lines: 50 Path: sri-spam!ames!pacbell!att-ih!att-cb!clyde!wtr@moss.ATT.COM From: wtr@moss.ATT.COM Newsgroups: comp.unix.microport Subject: GnuEmacs on SV/AT Keywords: %$#^% segmented arch Message-ID: <23842@clyde.ATT.COM> Date: 25 Mar 88 19:28:41 GMT Sender: jlc@clyde.ATT.COM Lines: 40 This is the next in the continuing requests on porting information for SV/AT (2.3-L) A friend of mine has GnuEmacs on his ATT-3B1. He has offered to download it to my machine. Before I spent 5 hours of phone time, could someone tell me if it's at all possible to get this code running under microport? --------- Regarding GCC on SV/AT: All responses have have been negative, because of 16 bit limitation and segments :-(. Most common advice seems to be inquire into Greenhill about their C compiler. Is it out of Beta-testing yet? What do you do to be a Beta-site (I do a fair amount of large system compiling, graphics routines, etc... and would be grateful to do extra testing on a decent compiler :-). Please e-mail any info you have on Greenhill availability. --------- Last question: (gawd do i have a lot of them ! ;-) Has anyone out there with a Sperry-IT gotten the ROM upgrade, and did it make any difference in the performance of SV/AT? (ie: fewer core dumps, etc...)? Thanx for all the help! ===================================================================== Bill Rankin Bell Labs, Whippany NJ (201) 386-4154 (cornet 232) email address: ...![ ihnp4 ulysses cbosgd allegra ]!moss!wtr ...![ ihnp4 cbosgd akgua watmath ]!clyde!wtr =====================================================================
nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) (03/27/88)
Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270313.AA04396@spam.istc.sri.com> Date: 27 Mar 88 03:13:12 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 104 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270252.AA04331@spam.istc.sri.com> Date: 27 Mar 88 02:52:57 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 95 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270230.AA04292@spam.istc.sri.com> Date: 27 Mar 88 02:30:55 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 86 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270212.AA04261@spam.istc.sri.com> Date: 27 Mar 88 02:12:21 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 77 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270153.AA04227@spam.istc.sri.com> Date: 27 Mar 88 01:53:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 68 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270132.AA04179@spam.istc.sri.com> Date: 27 Mar 88 01:32:17 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 59 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803260952.AA00893@spam.istc.sri.com> Date: 26 Mar 88 09:52:12 GMT Sender: usenet@ucbvax.BERKELEY.EDU Lines: 50 Path: sri-spam!ames!pacbell!att-ih!att-cb!clyde!wtr@moss.ATT.COM From: wtr@moss.ATT.COM Newsgroups: comp.unix.microport Subject: GnuEmacs on SV/AT Keywords: %$#^% segmented arch Message-ID: <23842@clyde.ATT.COM> Date: 25 Mar 88 19:28:41 GMT Sender: jlc@clyde.ATT.COM Lines: 40 This is the next in the continuing requests on porting information for SV/AT (2.3-L) A friend of mine has GnuEmacs on his ATT-3B1. He has offered to download it to my machine. Before I spent 5 hours of phone time, could someone tell me if it's at all possible to get this code running under microport? --------- Regarding GCC on SV/AT: All responses have have been negative, because of 16 bit limitation and segments :-(. Most common advice seems to be inquire into Greenhill about their C compiler. Is it out of Beta-testing yet? What do you do to be a Beta-site (I do a fair amount of large system compiling, graphics routines, etc... and would be grateful to do extra testing on a decent compiler :-). Please e-mail any info you have on Greenhill availability. --------- Last question: (gawd do i have a lot of them ! ;-) Has anyone out there with a Sperry-IT gotten the ROM upgrade, and did it make any difference in the performance of SV/AT? (ie: fewer core dumps, etc...)? Thanx for all the help! ===================================================================== Bill Rankin Bell Labs, Whippany NJ (201) 386-4154 (cornet 232) email address: ...![ ihnp4 ulysses cbosgd allegra ]!moss!wtr ...![ ihnp4 cbosgd akgua watmath ]!clyde!wtr =====================================================================
nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) (03/27/88)
Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270351.AA04547@spam.istc.sri.com> Date: 27 Mar 88 03:51:35 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 113 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270313.AA04396@spam.istc.sri.com> Date: 27 Mar 88 03:13:12 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 104 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270252.AA04331@spam.istc.sri.com> Date: 27 Mar 88 02:52:57 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 95 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270230.AA04292@spam.istc.sri.com> Date: 27 Mar 88 02:30:55 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 86 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270212.AA04261@spam.istc.sri.com> Date: 27 Mar 88 02:12:21 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 77 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270153.AA04227@spam.istc.sri.com> Date: 27 Mar 88 01:53:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 68 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270132.AA04179@spam.istc.sri.com> Date: 27 Mar 88 01:32:17 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 59 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803260952.AA00893@spam.istc.sri.com> Date: 26 Mar 88 09:52:12 GMT Sender: usenet@ucbvax.BERKELEY.EDU Lines: 50 Path: sri-spam!ames!pacbell!att-ih!att-cb!clyde!wtr@moss.ATT.COM From: wtr@moss.ATT.COM Newsgroups: comp.unix.microport Subject: GnuEmacs on SV/AT Keywords: %$#^% segmented arch Message-ID: <23842@clyde.ATT.COM> Date: 25 Mar 88 19:28:41 GMT Sender: jlc@clyde.ATT.COM Lines: 40 This is the next in the continuing requests on porting information for SV/AT (2.3-L) A friend of mine has GnuEmacs on his ATT-3B1. He has offered to download it to my machine. Before I spent 5 hours of phone time, could someone tell me if it's at all possible to get this code running under microport? --------- Regarding GCC on SV/AT: All responses have have been negative, because of 16 bit limitation and segments :-(. Most common advice seems to be inquire into Greenhill about their C compiler. Is it out of Beta-testing yet? What do you do to be a Beta-site (I do a fair amount of large system compiling, graphics routines, etc... and would be grateful to do extra testing on a decent compiler :-). Please e-mail any info you have on Greenhill availability. --------- Last question: (gawd do i have a lot of them ! ;-) Has anyone out there with a Sperry-IT gotten the ROM upgrade, and did it make any difference in the performance of SV/AT? (ie: fewer core dumps, etc...)? Thanx for all the help! ===================================================================== Bill Rankin Bell Labs, Whippany NJ (201) 386-4154 (cornet 232) email address: ...![ ihnp4 ulysses cbosgd allegra ]!moss!wtr ...![ ihnp4 cbosgd akgua watmath ]!clyde!wtr =====================================================================
nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) (03/27/88)
Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270414.AA04627@spam.istc.sri.com> Date: 27 Mar 88 04:14:57 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 122 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270351.AA04547@spam.istc.sri.com> Date: 27 Mar 88 03:51:35 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 113 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270313.AA04396@spam.istc.sri.com> Date: 27 Mar 88 03:13:12 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 104 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270252.AA04331@spam.istc.sri.com> Date: 27 Mar 88 02:52:57 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 95 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270230.AA04292@spam.istc.sri.com> Date: 27 Mar 88 02:30:55 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 86 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270212.AA04261@spam.istc.sri.com> Date: 27 Mar 88 02:12:21 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 77 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270153.AA04227@spam.istc.sri.com> Date: 27 Mar 88 01:53:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 68 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270132.AA04179@spam.istc.sri.com> Date: 27 Mar 88 01:32:17 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 59 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803260952.AA00893@spam.istc.sri.com> Date: 26 Mar 88 09:52:12 GMT Sender: usenet@ucbvax.BERKELEY.EDU Lines: 50 Path: sri-spam!ames!pacbell!att-ih!att-cb!clyde!wtr@moss.ATT.COM From: wtr@moss.ATT.COM Newsgroups: comp.unix.microport Subject: GnuEmacs on SV/AT Keywords: %$#^% segmented arch Message-ID: <23842@clyde.ATT.COM> Date: 25 Mar 88 19:28:41 GMT Sender: jlc@clyde.ATT.COM Lines: 40 This is the next in the continuing requests on porting information for SV/AT (2.3-L) A friend of mine has GnuEmacs on his ATT-3B1. He has offered to download it to my machine. Before I spent 5 hours of phone time, could someone tell me if it's at all possible to get this code running under microport? --------- Regarding GCC on SV/AT: All responses have have been negative, because of 16 bit limitation and segments :-(. Most common advice seems to be inquire into Greenhill about their C compiler. Is it out of Beta-testing yet? What do you do to be a Beta-site (I do a fair amount of large system compiling, graphics routines, etc... and would be grateful to do extra testing on a decent compiler :-). Please e-mail any info you have on Greenhill availability. --------- Last question: (gawd do i have a lot of them ! ;-) Has anyone out there with a Sperry-IT gotten the ROM upgrade, and did it make any difference in the performance of SV/AT? (ie: fewer core dumps, etc...)? Thanx for all the help! ===================================================================== Bill Rankin Bell Labs, Whippany NJ (201) 386-4154 (cornet 232) email address: ...![ ihnp4 ulysses cbosgd allegra ]!moss!wtr ...![ ihnp4 cbosgd akgua watmath ]!clyde!wtr =====================================================================
nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) (03/27/88)
Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270430.AA04700@spam.istc.sri.com> Date: 27 Mar 88 04:30:45 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 131 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270414.AA04627@spam.istc.sri.com> Date: 27 Mar 88 04:14:57 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 122 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270351.AA04547@spam.istc.sri.com> Date: 27 Mar 88 03:51:35 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 113 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270313.AA04396@spam.istc.sri.com> Date: 27 Mar 88 03:13:12 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 104 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270252.AA04331@spam.istc.sri.com> Date: 27 Mar 88 02:52:57 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 95 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270230.AA04292@spam.istc.sri.com> Date: 27 Mar 88 02:30:55 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 86 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270212.AA04261@spam.istc.sri.com> Date: 27 Mar 88 02:12:21 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 77 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270153.AA04227@spam.istc.sri.com> Date: 27 Mar 88 01:53:37 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 68 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803270132.AA04179@spam.istc.sri.com> Date: 27 Mar 88 01:32:17 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 59 Path: sri-spam!ames!pasteur!ucbvax!SPAM.ISTC.SRI.COM!nobody From: nobody@SPAM.ISTC.SRI.COM (Unpriviledged user) Newsgroups: comp.unix.microport Subject: Submission for comp-unix-microport Message-ID: <8803260952.AA00893@spam.istc.sri.com> Date: 26 Mar 88 09:52:12 GMT Sender: usenet@ucbvax.BERKELEY.EDU Lines: 50 Path: sri-spam!ames!pacbell!att-ih!att-cb!clyde!wtr@moss.ATT.COM From: wtr@moss.ATT.COM Newsgroups: comp.unix.microport Subject: GnuEmacs on SV/AT Keywords: %$#^% segmented arch Message-ID: <23842@clyde.ATT.COM> Date: 25 Mar 88 19:28:41 GMT Sender: jlc@clyde.ATT.COM Lines: 40 This is the next in the continuing requests on porting information for SV/AT (2.3-L) A friend of mine has GnuEmacs on his ATT-3B1. He has offered to download it to my machine. Before I spent 5 hours of phone time, could someone tell me if it's at all possible to get this code running under microport? --------- Regarding GCC on SV/AT: All responses have have been negative, because of 16 bit limitation and segments :-(. Most common advice seems to be inquire into Greenhill about their C compiler. Is it out of Beta-testing yet? What do you do to be a Beta-site (I do a fair amount of large system compiling, graphics routines, etc... and would be grateful to do extra testing on a decent compiler :-). Please e-mail any info you have on Greenhill availability. --------- Last question: (gawd do i have a lot of them ! ;-) Has anyone out there with a Sperry-IT gotten the ROM upgrade, and did it make any difference in the performance of SV/AT? (ie: fewer core dumps, etc...)? Thanx for all the help! ===================================================================== Bill Rankin Bell Labs, Whippany NJ (201) 386-4154 (cornet 232) email address: ...![ ihnp4 ulysses cbosgd allegra ]!moss!wtr ...![ ihnp4 cbosgd akgua watmath ]!clyde!wtr =====================================================================
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!apple!bbn!mailrus!b-tech!zeeff From: zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) Newsgroups: comp.unix.microport Subject: memory allocation for kernel and buffers Message-ID: <5030@b-tech.ann-arbor.mi.us> Date: 1 Jan 89 17:56:33 GMT Organization: Branch Technology, Ann Arbor, MI Lines: 12 This is a plea for '386 unix vendors to allocate memory for buffers and kernel space starting from the highest addresses. It will really help some of us who have some 16 bit memory. In the mean time, does anyone have a work-around - perhaps a patch for the disk buffer allocation module. -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Support ISO 8859/1 zeeff%b-tech.uucp@umix.cc.umich.edu Ann Arbor, MI umix!b-tech!zeeff
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!apple!bloom-beacon!gatech!hubcap!ncrcae!ncrlnk!uunet!wa3wbu!john From: john@wa3wbu.UUCP (John Gayman) Newsgroups: comp.unix.microport Subject: Re: Setkey problem... Summary: Which version of uport ? Message-ID: <194@wa3wbu.UUCP> Date: 1 Jan 89 14:12:04 GMT References: <1700002@spdyne> Organization: WA3WBU, Marysville,PA Lines: 33 In article <1700002@spdyne>, elwiz@spdyne..UUCP writes: > > Anyway, Try the following: > > 1) Login on the console, type setkey f10 "echo hello^M" > Test this by hitting F10, and it will `echo hello'. > > 2) Login to a normal user account on Cons2. > > 3) Switch to the console and Hit F10.... Surprise! you get > <ESC>X or something....(an X echos)... it is as if you did > a setkey -d on the console!... > I'm unsure which version of Microport your running. V/AT ? V/386 ? I am using V/386 3.0Ue here and I have tried the above experiment and it works okay. I put something like 'ps -ef' on function key F1 and F10. I then switched to another virtual console and logged in. Both of the function keys still performed the 'ps -ef'. Hummmmm....... John -- John Gayman, WA3WBU | UUCP: uunet!wa3wbu!john 1869 Valley Rd. | ARPA: john@wa3wbu.uu.net Marysville, PA 17053 | Packet: WA3WBU @ AK3P
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!apple!rutgers!elbereth.rutgers.edu!ron.rutgers.edu!ron From: ron@ron.rutgers.edu (Ron Natalie) Newsgroups: comp.unix.microport Subject: Re: Microport, Xenix, Interactive: Which one? Message-ID: <Jan.1.14.26.26.1989.4289@ron.rutgers.edu> Date: 1 Jan 89 19:26:27 GMT References: <285@longway.TIC.COM> Distribution: usa Organization: Rutgers Univ., New Brunswick, N.J. Lines: 5 It's a moot point. All the 386 system V ports are essentially the same one done by Interactive Systems. They are fairly decent Sys 5 R 3 ports and you can even get TCP for them. -Ron
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!apple!rutgers!njin!princeton!njsmu!mccc!cosi!bill
From: bill@cosi.UUCP (Bill Michaelson)
Newsgroups: comp.unix.microport
Subject: Re: Problems w/U-port (longish)
Summary: Yeah, me too
Message-ID: <258@cosi.UUCP>
Date: 1 Jan 89 20:17:22 GMT
References: <1700003@spdyne>
Organization: COS, Inc., Lawrenceville, NJ
Lines: 26
In article <1700003@spdyne>, elwiz@spdyne..UUCP writes:
]
]
] If I put the following lines in /etc/dosdev:
]
] com1 v /dev/vcom1 # This is virtual com1 device
] com1 r /dev/tty00 Assign to a line
]
]
] I can then run `dos +acom1' or +acom1=/dev/vcom1 or any of the rest of the
] examples and I get the SAME result... Procomm can Send BUT NOT RECEIVE!
] as far as I can tell, it is NOT getting any interrupts.. This is a real
] pain, I wanted to use virtual access as the direct seemed to be causing
] my system to crash and burn (Hang >> Power down to reset), when I had a
] ...[stuff deleted]
]
I can't get serial communications to work under DOS/Merge either. I reported
the problem to Microport. Their response was that they knew about the problem
and they had no specific plans to fix it. Maybe they don't care?
I had hoped the problem would be fixed with 3.0e and DOS/Merge 1.1, but it
wasn't. <sigh>
--
Bill Michaelson - uh... princeton!mccc!cosi!bill, I think.
also at... Voice 609-771-6705 CompuServe 72416,1026uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!apple!rutgers!ucsd!ames!killer!texbell!splut!jay From: jay@splut.UUCP (Jay "you ignorant splut!" Maynard) Newsgroups: comp.unix.microport Subject: Re: How does Microport System V/AT handle bad blocks? Message-ID: <798@splut.UUCP> Date: 1 Jan 89 22:11:40 GMT References: <460@tarpit.UUCP> <326@focsys.UUCP> <464@tarpit.UUCP> <2689@nuchat.UUCP> <211@trevan.UUCP> Reply-To: jay@splut.UUCP (Jay "you ignorant splut!" Maynard) Organization: Confederate Microsystems, League City, TX Lines: 58 In article <211@trevan.UUCP> trevor@trevan.UUCP (trevor) writes: >Well well I spent a whole week trying to sort my disks out and now it >turns out to be FSCK to be at fault. Microport does admit to there being >a problem but it says only with file systems greater tan 130000 blocks. >All my file systems are less than 100,000 blocks and I still get this >problem. I first encountered this problem on an 84K block filesystem. I spent a week with fsdb and fsck, using fsdb to straighten out the worst problems, and then using fsck to (I thought) straighten out the filesystem. ARGH!! I finally gave up when Steve told me about the bug. >I must thank Steve for a workaround which will help but there is still >the problem of the file system check at boot up. I guess we will have to make >it interactive inorder to stop this self destruction. This means that >unattended reboots after powercuts etc, will not be possible unless >someone can tell us how to prevent fsck from rebuilding the free list >first time round. I guess it might be possible to create some sort of >shell programm to interact with fsck and answer all the questions. I've already done this in response to this problem. To turn off the automatic fscks at boot time, edit /etc/bcheckrc and /etc/mountall and remove the -y switch from the fsck command. I now leave a boot floppy in drive 0 with the door closed, so that in the event of an automatic reboot, it doesn't even attempt to reboot the full system; I then manually fsck things from the boot floppy, doing it twice if the first time claims that the free list needs rebuilding. This makes it even more important to have at least one partition small enough to be checked without the need of a work file; fsck that one first, then mount it on /mnt and use /mnt/foo as the work file for the rest of them. >This must be the worst bug in Microports system and is worse than most >viruses. Why didnt Microport warn us of this problem? If they knew >about it I think it was totally negligent of them not to have told us. They didn't know it was fsck causing the problem until Steve took one of their service techs through crashing a large file system and showed him how fsck would corrupt it. This only happened a couple of months ago. As for telling us about known bugs, they only do that for holders of their misnamed support contracts. I agree that it's negligent for them not to periodically mail out lists of known bugs. Maybe they're afraid it'll make their software look buggy. Actually, it's not that bad of a bug; if you know about the workaround, it's easy (though time-consuming) to deal with. It'd not be a nuisance at all if the system didn't repeatedly crash. >I think that Microport should make the fixing of this bug their top priority. What? Service their customer base? Radical concept, that. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. hoptoad!academ!uhnix1!splut!jay +---------------------------------------- {killer,bellcore}!tness1! | Free Texas from its chains: SECEDE!!
news@tolerant.UUCP (The Daily Fishwrap) (01/06/89)
Path: tolerant!voder!apple!rutgers!mailrus!cornell!batcomputer!wilker From: wilker@batcomputer.tn.cornell.edu (Clarence W. Wilkerson Jr.) Newsgroups: comp.unix.microport,comp.unix.xenix Subject: Re: NEC P2200 driver for Microport UNIX 286 Summary: Try drivers for Epson 1500LQ series for P2200 Keywords: NEC P2200, Microport UNIX 286, availability Message-ID: <7109@batcomputer.tn.cornell.edu> Date: 4 Jan 89 14:29:35 GMT References: <1994@botter.cs.vu.nl> <8641@alice.UUCP> <1995@botter.cs.vu.nl> Organization: Theory Center, Cornell U., Ithaca NY Lines: 4 I believe the command set for the P2200 includes the Epson escape codes. This is based on hacking a DVI driver and glancing at both manuals.
news@tolerant.UUCP (The Daily Fishwrap) (01/06/89)
Path: tolerant!voder!apple!bloom-beacon!bu-cs!purdue!decwrl!decvax!zinn!mem From: mem@zinn.MV.COM (Mark E. Mallett) Newsgroups: comp.unix.microport Subject: Re: Setkey problem... Message-ID: <429@zinn.MV.COM> Date: 4 Jan 89 02:53:46 GMT References: <1700002@spdyne> Reply-To: mem@zinn.MV.COM (Mark E. Mallett) Organization: Zinn Computer Co., Litchfield NH Lines: 28 In article <1700002@spdyne> elwiz@spdyne..UUCP writes: > 1) Login on the console, type setkey f10 "echo hello^M" > 2) Login to a normal user account on Cons2. > 3) Switch to the console and Hit F10.... Surprise! On my System V/AT system (2.4), the function key produces the "echo hello^M" string everywhere. Now, whether this is a good idea or not is something else; one might argue that function keys mappings should correspond to the virtual terminals. Then again, one might not. At any rate, the global setting seems to work fine. >PS: Do you guys ever respond to mail anymore??? I have sent it DIRECTLY into >your system via direct connection and STILL haven't gotten any response! Sounds exactly like some comments that I made a couple of months ago. Microport DID CLAIM that they welcomed direct connections for mail. I polled for a while, sent direct mail several times, and got no responses. Of course, they were busy with various new releases at the time. Perhaps things will be better now. There's always hope. -mm- -- Mark E. Mallett Zinn Computer Co/ PO Box 4188/ Manchester NH/ 03103 Bus. Phone: 603 645 5069 Home: 603 424 8129 BIX: mmallett uucp: mem@zinn.MV.COM ( ...{decvax|elrond|harvard}!zinn!mem ) Northern MA and Southern NH consultants: Ask me about MV.COM
news@tolerant.UUCP (The Daily Fishwrap) (01/06/89)
Path: tolerant!voder!apple!rutgers!bellcore!texbell!ssbn!bill
From: bill@ssbn.WLK.COM (Bill Kennedy)
Newsgroups: comp.unix.microport
Subject: Green Hills 386 compiler
Keywords: gcc shared libraries
Message-ID: <293@ssbn.WLK.COM>
Date: 27 Dec 88 19:30:02 GMT
Distribution: na
Organization: W.L. Kennedy Jr. & Associates, Pipe Creek, TX
Lines: 17
s the subject suggests I'm trying to tiptoe into the new compiler. Thus
far I haven't found anything it does that's smaller than what pcc writes
but there is a mesaurable (time) speed improvement. I have very little
experience with it so bear with my (hopefully not obvious) ignorance.
I took the same source and compiled it with pcc and gcc, with and without
the shared C library (-lc_s). It outran pcc by about 30% with a 50%
increase in binary size without the shared library. The pcc version with
shared library was about 20% larger than without it and it ran. The gcc
binary with shared library promptly dumped core with a memory fault. I
did RTFM but if there was a caveat in there it didn't have a big red flag
flying over it.
Is anyone else having similar results or is it just me again? Thanks,
--
Bill Kennedy usenet {killer,att,cs.utexas.edu,sun!daver}!ssbn!bill
internet bill@ssbn.WLK.COMuucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!apple!rutgers!ukma!uflorida!haven!umbc3!cbw1!brian From: brian@cbw1.UUCP (Brian Cuthie) Newsgroups: comp.unix.microport Subject: Re: System Crash Message-ID: <126@cbw1.UUCP> Date: 4 Jan 89 15:46:11 GMT References: <249@cosi.UUCP> <1700004@spdyne> <195@wa3wbu.UUCP> Reply-To: brian@cbw1.UMD.EDU (Brian Cuthie) Organization: CBW, Columbia, MD 21046 Lines: 48 In article <195@wa3wbu.UUCP> john@wa3wbu.UUCP (John Gayman) writes: >In article <1700004@spdyne>, root@spdyne.UUCP writes: >> >> >> >> >> Also - I recall seeing something about support for more than 4 virtual >> >> consoles in 3.0e. Does anyone know what I have to do to get, say, 10 >> >> consoles? >> >> >> > The first thing I did when I installed 3.0e was to set it up for >> > 10 virtual consoles like my V/AT had. Everything is already configured >> >> Ok, So I executed `mknod cons4 c 5 4' Added a getty into the /etc/inittab >> and guess what? I got a bunch of errors on the console...about not >> being able to open it...... >> >> Do I have to bring the System down or what? >> > > You should not have to bring the system down. The only exception >to what you and I are doing is that I did not use the plain vanilla >kernel that came with the system. I immediately generated a kernel >with the Everex Tape driver, rebooted and then added the extra >consoles. I did not do anything in linkkit to enable them. It is [...] Use patch to look at a kernel variable called 'kd_numttys'. I This is (I think) the maximum number of virtual consoles. It is set in the linkkit to be 32. It may however only be four in the distributed version. -brian -- Brian D. Cuthie uunet!umbc3!cbw1!brian Columbia, MD brian@umbc3.umd.edu
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!apple!rutgers!att!ihlpa!steveb From: steveb@ihlpa.ATT.COM (Bodenstab) Newsgroups: comp.unix.microport,comp.unix.xenix Subject: gnumake patches posted to gnu.utils.bug Keywords: gnumake 3.27 Message-ID: <11108@ihlpa.ATT.COM> Date: 5 Jan 89 01:02:48 GMT Distribution: usa Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 12 I've ported gnumake 3.27 to microport system V/AT (286). There are also some fixes for system V in general. The patches have been posted to gnu.utils.bug for anyone who might be interested. Dave Bodenstab AT&T Bell Labs ...att!iwsl8!imdave -- Steven R. Bodenstab UUCP: ...!att!ihlpa!steveb AT&T Bell Laboratories ...!att!ihlpa.ATT.COM!steveb
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!apple!bbn!mit-eddie!uw-beaver!cornell!batcomputer!sun.soe.clarkson.edu!rpi!itsgw!steinmetz!uunet!edsews!trilby!mike From: mike@trilby.UUCP (Michael K. Hammond) Newsgroups: comp.unix.microport Subject: Line Conditioners/Stabilizers Message-ID: <32@trilby.UUCP> Date: 4 Jan 89 18:48:01 GMT Reply-To: mike@trilby.UUCP (Michael K. Hammond) Distribution: usa Organization: General Motors Research, Troy, MI Lines: 15 I'm interested in getting a Line Condiyioner/Stabilizer for a 386 Unix box that is running 24-hours a day. I would appreciate any feedback from the net on systems people have in use. If there is sufficent interest I will post a summary to the net. As always, THANKS for the input! Mike -- +-----------------------------------------------------------------------------+ | Michael K. Hammond UUCP {killer!,uunet!edsews!}trilby!mike | | Disclaimer: I speak solely for myself. ( That's hard enough! ) | +---------- "What! I can't be overdrawn! I still have checks left!" ----------+
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!apple!rutgers!mailrus!ames!killer!chasm From: chasm@killer.DALLAS.TX.US (Charles Marslett) Newsgroups: comp.unix.microport Subject: Re: missing 384K on V/386 Summary: Way up in the sky go the RAM ... Message-ID: <6631@killer.DALLAS.TX.US> Date: 2 Jan 89 17:21:45 GMT References: <1263@altger.UUCP> Sender: 0000-Admin(0000) Organization: The Unix(R) Connection, Dallas, Texas Lines: 24 In article <1263@altger.UUCP>, dirk@altger.UUCP (dirk) writes: > I've been reading this newsgroup for a while now but I never saw the > following question: > > Where did the 384K go ? > > If you install 2MB on a Compaq 386 you'll get 640K conventional memory > and 1024K extended memory == 1664K. When booting 386/ix it reports > 1703936 Bytes of real memory. So, where are they ? The 384K of RAM that disappeared seems to be lurking at 0xE00000 (if I remem- ber correctly) as normal RAM. It can also be enabled with some granularity (16K or perhaps 64K) in the 0x00A000-0x00FFFF range. If you do not find it at 0xE00000-0xE5FFFF, let me know and I will fish out the utility I wrote to scan protected memory for such lumps of RAM. > cu, > dirk :-) =========================================================================== Charles Marslett STB Systems, Inc. <== Apply all standard disclaimers Wordmark Systems <== No disclaimers required -- that's just me chasm@killer.dallas.tx.us
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!apple!bloom-beacon!mit-eddie!killer!texbell!egsner!spdyne!root From: root@spdyne.UUCP Newsgroups: comp.unix.microport Subject: Re: Setkey problem... Message-ID: <1700006@spdyne> Date: 2 Jan 89 17:38:00 GMT References: <1700002@spdyne> Lines: 36 Nf-ID: #R:spdyne:1700002:spdyne:1700006:004:1486 Nf-From: spdyne.UUCP!root Jan 2 11:38:00 1989 > > > > Anyway, Try the following: > > > > 1) Login on the console, type setkey f10 "echo hello^M" > > Test this by hitting F10, and it will `echo hello'. > > > > 2) Login to a normal user account on Cons2. > > > > 3) Switch to the console and Hit F10.... Surprise! you get > > <ESC>X or something....(an X echos)... it is as if you did > > a setkey -d on the console!... > > > > > I'm unsure which version of Microport your running. V/AT ? V/386 ? > > I am using V/386 3.0Ue here and I have tried the above > experiment and it works okay. I put something like 'ps -ef' on > function key F1 and F10. I then switched to another virtual > console and logged in. Both of the function keys still performed > the 'ps -ef'. Hummmmm....... I guess that I forgot to include that I'm running the DOS-Merge Kernel. [3.0e - Unlimited] With a Digi-Board 8 port Int. Comm. controller. On a Compaq 386/20 if that matters... It consistantly does this.. And I have 13 things defined....(Does this matter??) -- Chert Pellett Also, It would be nice if U-Port would compile ALL programs that use floating point under gcc so that THEY WOULD WORK!! (Awk fails on my machine - Dumps core).. Specific to the Compaq I'm told...Any chance I can get a floppy with all system utilities recompiled using gcc? (Any floating point in the kernel? [I doubt it, but then who knows?.. DOS-Merge is rather slow...]
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!apple!rutgers!mailrus!ames!killer!texbell!ssbn!bill
From: bill@ssbn.WLK.COM (Bill Kennedy)
Newsgroups: comp.sys.att,comp.unix.microport
Subject: DWB to HP Laser Jet V/386
Keywords: troff Laser printer JetRoff
Message-ID: <366@ssbn.WLK.COM>
Date: 2 Jan 89 19:43:49 GMT
Organization: W.L. Kennedy Jr. & Associates, Pipe Creek, TX
Lines: 53
I've seen several inquiries about the AT&T Documentor's Workbench with
HP Laser Jet support under AT&T/Microport/ISC 386 SysVr3.x. There are
several alternatives. Personally I use Elan's eroff package and I am
satisfied with it. If you don't have an application that can justify
the expense it might be out of reach.
ISC sells DWB 2.0 separately, I don't know what they charge for it, I
bought it in a chunk of other stuff. Microport also sells it. Do not
make the mistake of getting their '286 version. The troff is brain dead
and the STL object format will not run on a '386. I've not tried the
'386 version but I'll ASSume it works (not always a safe assumption with
Microport). The latest Programmer Shop catalog shows Microport DWB 2.0
for $185. Team that up with the shareware JetRoff and you have a complete
typesetting system with as much capability as you can expect from a 300dpi
laser printer. The total cost clocks out at $235 + S&H. You can reach
The Programmer's Shop at 800-421-8006 or 800-442-8070 in Massachusetts.
I have dealt with them several times over five years and have never had a
problem that they didn't solve promptly and courteously. I'm not sure
how to get JetRoff but it was posted to comp.sources.misc or you could ask
Rick Richardson (jetroff@pcrat.UUCP, uunet!pcrat!jetroff).
Unless you have Microport V/386 you might not have their package installer
that groks the diskette format they use. They have a control file that gets
read in from /dev/rdsk/f0q15dt. The rest of the diskette is in standard
cpio format but you read it in from /dev/rdsk/f0q15d.
You will probably want to ditch all of the AT&T typesetter postprocessors
and fonts and stick with what comes with JetRoff. After you register with
PC Research you can get diskettes with the other fonts and sizes that weren't
posted to the net. You also get a special uucp login so that you can collect
the latest goodies and fixes that weren't in the original distribution
(like making a Series-I Laser Jet work correctly). There are some real live
advantages to JetRoff, not the least of which is full source code. Elan does
support soft fonts but unless the font has a landscape orientation you can
only use portrait. If you specify landscape orientation to JetRoff and feed
it a portrait soft font, he will torque it around 90 degrees for you and you
have it landscape. JetRoff has a much richer collection of bit mapped
graphics formats supported and with the source you can fairly easily implement
one that it doesn't support (MacPaint comes to mind, Elan supports that).
There's an invaluable tool included with JetRoff, Elan says that they have it
now. When you run the jetroff script it will check your document to see what
preprocessors you have invoked and run them for you in the correct sequence.
As I said, I'm happy with the Elan product. It's robust and predictable. The
'386 version lists for $895 and I have not seen it discounted anywhere. The
JetRoff shareware requests a $50 registration fee for individuals and $100 for
companies. I use both, they are worthwhile companions, but if you don't have
$900 to blow on your Laser Jet you will get by just fine with JetRoff. I have
no affiliation with PC Research or Elan other than having sent them some money
for their product.
--
Bill Kennedy usenet {killer,att,cs.utexas.edu,sun!daver}!ssbn!bill
internet bill@ssbn.WLK.COMuucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!apple!bbn!csd4.milw.wisc.edu!uwmcsd1!marque!uunet!mcvax!enea!log-hb!staffan From: staffan@log-hb.se (Staffan K-E Eriksson) Newsgroups: comp.unix.microport Subject: gcc version Summary: What version of gcc has a 386-backend? Keywords: gcc, backend Message-ID: <6865@log-hb.se> Date: 2 Jan 89 12:29:29 GMT Reply-To: staffan@log-hb.UUCP (Staffan K-E Eriksson) Organization: TeleLOGIC AB, Nynashamn, Sweden Lines: 7 I have seen articles about the Gnu C-compiler running under Microport/386 Unix. From what version of GCC is this 386-backend present ? Which is the latest GCC version available? -- Staffan Eriksson TeleLOGIC AB SWEDEN
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!apple!bbn!csd4.milw.wisc.edu!leah!itsgw!steinmetz!uunet!wa3wbu!john From: john@wa3wbu.UUCP (John Gayman) Newsgroups: comp.unix.microport Subject: Re: System Crash Summary: Another possibility Message-ID: <195@wa3wbu.UUCP> Date: 2 Jan 89 14:26:27 GMT References: <249@cosi.UUCP> <1700004@spdyne> Organization: WA3WBU, Marysville,PA Lines: 37 In article <1700004@spdyne>, root@spdyne.UUCP writes: > > >> > >> Also - I recall seeing something about support for more than 4 virtual > >> consoles in 3.0e. Does anyone know what I have to do to get, say, 10 > >> consoles? > >> > > The first thing I did when I installed 3.0e was to set it up for > > 10 virtual consoles like my V/AT had. Everything is already configured > > Ok, So I executed `mknod cons4 c 5 4' Added a getty into the /etc/inittab > and guess what? I got a bunch of errors on the console...about not > being able to open it...... > > Do I have to bring the System down or what? > You should not have to bring the system down. The only exception to what you and I are doing is that I did not use the plain vanilla kernel that came with the system. I immediately generated a kernel with the Everex Tape driver, rebooted and then added the extra consoles. I did not do anything in linkkit to enable them. It is possible that the kernel which linkkit generates is slightly different than the released one. All I then did was the mknod for each, enable them in inittab, add them to gettydefs, and do an "init q". Try "mkunix" and then use that kernel. Unless someone on here knows specifically that the distribution kernel differs from the one linkkit makes. John -- John Gayman, WA3WBU | UUCP: uunet!wa3wbu!john 1869 Valley Rd. | ARPA: john@wa3wbu.uu.net Marysville, PA 17053 | Packet: WA3WBU @ AK3P
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!apple!rutgers!cs.utexas.edu!natinst!bigtex!james From: james@bigtex.cactus.org (James Van Artsdalen) Newsgroups: comp.unix.microport Subject: Re: missing 384K on V/386 Message-ID: <12352@bigtex.cactus.org> Date: 3 Jan 89 03:13:09 GMT References: <1263@altger.UUCP> Reply-To: james@bigtex.cactus.org (James Van Artsdalen) Organization: Institute of Applied Cosmology, Austin TX Lines: 23 In <1263@altger.UUCP>, dirk@altger.UUCP (dirk) wrote: > Where did the 384K go ? > If you install 2MB on a Compaq 386 you'll get 640K conventional memory > and 1024K extended memory == 1664K. When booting 386/ix it reports > 1703936 Bytes of real memory. So, where are they ? Not all motherboard hardware supports mapping the "missing" 384K into the extended memory space. Some can map that 384K to the 1meg mark, but only if there is no other memory at the 1meg address. It's just a fact of life: too many chipset designers have a Mess-DOS mindset. I should point out that shadow RAM *is* a tremendous win under DOS... > [...] On a Chips+Tech chipset I saw an option to enable shadow > memory by 16K page increments. 386/ix is probably only using the 0-640K and > 1meg memory. A clever trick would be to enable all of the shadow memory possible in read/write mode and use it too, meaning you'd lose only the memory used by the video display and any memory mapped devices. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" DCC Corporation 9505 Arboretum Blvd Austin TX 78759 512-338-8789
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!apple!rutgers!gatech!unmvax!tut.cis.ohio-state.edu!mailrus!csd4.milw.wisc.edu!leah!itsgw!steinmetz!uunet!wa3wbu!john
From: john@wa3wbu.UUCP (John Gayman)
Newsgroups: comp.unix.microport
Subject: >4 virtual cons on V/AT 2.4
Message-ID: <197@wa3wbu.UUCP>
Date: 2 Jan 89 21:43:22 GMT
Organization: WA3WBU, Marysville,PA
Lines: 15
Has Anyone added more than the default 4 virtual consoles to
Microport V/AT 2.4 ? On 2.3 all that was required was to add the
device names and edit inittab. 2.4 seems to be hard coded in the config
for only 4. What is the procedure for adding addition virtual consoles,
say like 10 total ? Thanks!
John
--
John Gayman, WA3WBU | UUCP: uunet!wa3wbu!john
1869 Valley Rd. | ARPA: john@wa3wbu.uu.net
Marysville, PA 17053 | Packet: WA3WBU @ AK3P uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!pyramid!oliveb!amdahl!pacbell!belltec!dar From: dar@belltec.UUCP (Dimitri Rotow) Newsgroups: comp.periphs,comp.unix.microport Subject: Re: tape streamers question Summary: comments on BTI pals Message-ID: <321@belltec.UUCP> Date: 2 Jan 89 22:33:02 GMT References: <1516@bebux.UUCP> <895@starfish.Convergent.COM> <314@belltec.UUCP> <271@dcs.UUCP> Organization: Bell Technologies, Fremont, CA Lines: 39 In article <271@dcs.UUCP>, wnp@dcs.UUCP (Wolf N. Paul) writes: > Would you care to comment on the REASON for the change of PALS on the Bell Tech- > supplied EV-811-B controller, which in effect makes the use of Bell Tech's > System V/AT tape driver impossible with a non-Bell Tech EV-811-B? > You bet! Bell started shipping tape drives at a time when there were 15 or 20 different implementations of QIC-36 tape drives. The initial PAL was used simply for version control and host board identification. We keep using it because we read Usenet and don't want to get involved supporting other people's tape controllers and tape hardware. Sure, in theory you can whack together just about any QIC-36/QIC-02 generic controller and tape mechanism and expect it to go, but (as readers of this and the comp.unix.xenix group know) it just doesn't work that way in practise. Our own line of integrated controllers, tapes and software provides special value which we intend to keep selling for our benefit. As it so happens, we *do* sell a commodity tape interface that works on almost anybody's controller/driver pair ... that's the "qt" (for Qic Tape) streamer driver that's part of our UNIX System V/386 Release 3.2 distribution. You get that driver free as part of the standard release. If you buy a Bell Tech streamer tape, you get our tape stuff free as well. The Bell tape software streams a heck of a lot better than the AT&T stuff. One reason is that it is precisely integrated with a specific family of controllers and tape mechanisms. You pays your money and you takes your choice. Note, by the way, that your posting makes an inaccurate assumption in that you imply that there is only one EV-811-B controller, when in fact their are very many different revs of that controller boards that ship under the very same or similar part numbers. This is not a criticism of the EV product, just a note on the hidden dimension of version skew. One of the ways we've been forced into dealing with version skew is to start fabbing our own QIC-02 series tape controllers. This assures us that our customers will not be hurt by hardware version skew. Wangtek, by the way, is also fabbing their own EV series controllers as well. - dimitri rotow
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!pyramid!oliveb!amdahl!pacbell!belltec!dar From: dar@belltec.UUCP (Dimitri Rotow) Newsgroups: comp.unix.microport,comp.unix.wizards,comp.unix.questions,comp.unix.xenix Subject: Re: how to order a V3.2 driver design manual Summary: Geez! Keywords: Integrated Software Design Guide ISDG V3.2 Message-ID: <322@belltec.UUCP> Date: 2 Jan 89 22:49:19 GMT References: <363@siswat.UUCP> Organization: Bell Technologies, Fremont, CA Lines: 45 In article <363@siswat.UUCP>, buck@siswat.UUCP (A. Lester Buck) writes: > A while ago, Dimitri Rotow of Bell Technologies posted the following: > [Repeat of my earlier posting deleted except for 800 number...] > ]To order AT&T documents, call their Customer Information Center at > ]800-432-6600. They take VISA and are very responsive. The material > > I finally got around to try ordering these two manuals and called the > 800 number. The Device Driver Reference Manual was easy with the > select code, but they could not find the ISDG from the above title > (and missing a select code). I called Bell Tech for a select code, > but they couldn't find one on their documentation. (They suggested > I buy their version of V3.2...) I sent email to Dimitri Rotow but > never got a reply back. > > Does the Integrated Software Design Guide exist as an AT&T publication > available for sale separately? Does anyone know a select code > to use for this ISDG? > > A. Lester Buck ...!uhnix1!moray!siswat!buck You know, I've gotten about 150 mail messages and over two dozen phone calls on this issue. Why is it that people expect us to function as an 800 number information operator? AT&T references its documents in many ways. If you can't get to the ISDG by that title only, try by asking for the documentation for their UNIX Release 3.2 package. If that mystifies the operator, work with her/him a little. Try "simultask" for WGS 6386 or a variety of other AT&T nomenclature items. We've never had any problems ordering ISDG by calling the 800 numbers. For the record, the listed select code in *some* AT&T documents for the ISDG is 307-072. This is no guarantee that the CIS will have that select code in their computer. If you can't figure out how to get this document from AT&T, call AT&T. If you want to buy it from us, we can't sell it to you (since it is UNIX licensed material and AT&T has given Prentice Hall an exclusive on selling UNIX manuals outside of an association with a UNIX software license) *unless* you also buy 3.2. Their rules, not ours. - dimitri rotow
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!pyramid!oliveb!amdahl!pacbell!belltec!dar From: dar@belltec.UUCP (Dimitri Rotow) Newsgroups: comp.unix.microport,comp.unix.xenix Subject: Re: Which one: Interactive, Microport, Xenix? Summary: Ours, of course. Message-ID: <324@belltec.UUCP> Date: 2 Jan 89 22:56:18 GMT References: <2410@stiatl.UUCP> Distribution: usa Organization: Bell Technologies, Fremont, CA Lines: 36 In article <2410@stiatl.UUCP>, todd@stiatl.UUCP (Todd Merriman) writes: > Our company is trying to select a Unix (Sys. V) for 386. On the > basis of: > > SVID compliance > Availability of drivers for add-on peripherals > Support for X-Windows > Ethernet-TCP/IP support > Quality of documentation and support > 3rd party software availability > No system call differences with 3B2 and Convergent (shmem(), semctl()) > Up-to-date curses and terminfo > Full complement of uucp utilities > > The system in production will be handling multiple communications > sessions with modems and a user interface under X-Windows. > > What are your suggestions? Ours, of course. Everything is just echoes of the standard AT&T/Intel release. Some are very nice echoes (ISC, for example), and others are not-so-nice. Note that with us you can run all software written for Interactive, Microport, *or* SCO Xenix on the 286 and 386. Plus you get production X and Ethernet code shipping today, and perfect compatiblity with 3B2. With us you also get the very fastest X Window environment in the world, as well as support for X in a very wide range of display resolutions (640 x 480, 1024 x 768, 1024 x 1024, 1280 x 1024, and 1660 x 1200). Our X packages support Hercules, Bell Tech Blit lo-res color, high res mono, high res color, Microfield T8, and Univision's 1660 x 1200 color. We also provide Ethernet and X window on the same board in our "Instant Workstation" (which also has a mouse port on-board). - dimitri rotow, bell technologies 800-for-UNIX
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!pyramid!oliveb!amdahl!pacbell!belltec!dar From: dar@belltec.UUCP (Dimitri Rotow) Newsgroups: comp.periphs,comp.unix.microport Subject: Re: tape streamers question Summary: Nope, our stuff works fine with generic drivers Message-ID: <325@belltec.UUCP> Date: 2 Jan 89 23:01:59 GMT References: <1516@bebux.UUCP> <895@starfish.Convergent.COM> <314@belltec.UUCP> <379@ispi.UUCP> Organization: Bell Technologies, Fremont, CA Lines: 17 In article <379@ispi.UUCP>, jbayer@ispi.UUCP (Jonathan Bayer) writes: [Quotations about Bell copy protection deleted] > Unfortunately, Bell Technologies is practicing copy protection on > Unix/Xenix. By changing the PALS they ensure that only their software > will work with their board, and that their board will only work with > their software. I found this out the hard way after SCO came out with > direct support of the QIC-36 boards. I now have a customer who is stuck > Not so! the PAL locks no one out ... you can run SCO just fine with our boards using the built-in SCO drivers. Just make sure to set the interrupts, etc, correctly. Note that SCO itself quotes Bell Tech boards as supported streamer tape plug ins in the SCO documentation. - dimitri rotow
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!pyramid!oliveb!amdahl!pacbell!belltec!dar From: dar@belltec.UUCP (Dimitri Rotow) Newsgroups: comp.unix.microport Subject: Re: Microport, Xenix, Interactive: Which one? Summary: get a second opinion from microsoft and at&T Message-ID: <326@belltec.UUCP> Date: 2 Jan 89 23:15:05 GMT References: <285@longway.TIC.COM> <Jan.1.14.26.26.1989.4289@ron.rutgers.edu> Distribution: usa Organization: Bell Technologies, Fremont, CA Lines: 42 In article <Jan.1.14.26.26.1989.4289@ron.rutgers.edu>, ron@ron.rutgers.edu (Ron Natalie) writes: > It's a moot point. All the 386 system V ports are essentially the > same one done by Interactive Systems. They are fairly decent > Sys 5 R 3 ports and you can even get TCP for them. > > -Ron Ron - I agree with you that it is a moot point in that there is convergence towards a standard, but you may want to check with AT&T, Intel, and Microsoft about who's did the work. The original UNIX System V/386 Release 3.0 came out from Intel Corporation as the general contractor. Interactive did a lot of work for Intel, especially on the base AT device drivers, and based its own "386/ix" product on the stock Intel/AT&T product. However, the Intel OPO guys up in Oregon and the Intel MCG guys in Santa Clara like to think that the few thousand man hours they spent with AT&T creating the final 3.0 product had a bit to do with the effort. According to AT&T, the device driver content in Release 3.2, the "merged" Xenix/UNIX release is "less than 10% residual intellectual property based on Interactive's contributions in 3.0." In particular, the console/keyboard driver is pretty much the Microsoft Xenix driver (note the presence of multiscreen in console, etc). According to AT&T and Intel, *they* are the ones doing essentially *all* of the work in Release 3.2. They have incorporated stuff from numerous third parties (Microsoft, etc), but it is a very large mistake to think that anyone but AT&T is steering the boat from here on in. Of all the commercial releases, the Intel/AT&T release that we publish is obviously the closest to AT&T's standard (because it *is* AT&T's standard), but Interactive is easily the next closest. Because of the high quality and timeliness of ISC's work it is easy to misidentify their close relationship to the AT&T port in 3.0 with the same identity in 3.2, but that is not the case. Note also that AT&T's own commercial binary UNIX for their 6386 WGS line is different than the official standard AT&T/Intel product licensed through Greensboro. - dimitri rotow
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!pyramid!amdahl!ames!haven!aplcen!wb3ffv!fallst!tkevans
From: tkevans@fallst.UUCP (Tim Evans)
Newsgroups: comp.unix.microport
Subject: uPort 2.4 'cron' and/or HDB 'Poll'
Message-ID: <491@fallst.UUCP>
Date: 2 Jan 89 14:25:20 GMT
Organization: Tim Evans, Fallston, MD
Lines: 16
I'm finding that uPort 2.4 seems to have corrected the old 'cron' bug
(i.e., everything ran twice), _except_ with respect to UUCP calls
generated by the HDB 'uudemon.poll'. These still seem to get generated
in twos. (I run this script via cron every half hour, then run
'uusched' a little later--also every half hour.) Whenever
'uudemon.poll' generates its "phony" work file for a system, it seems
to do so in such a way that the remote system gets called _twice_,
a half hour apart.
Anyone know anything about this?
--
UUCP: ...!{rutgers|ames|uunet}!mimsy!aplcen!wb3ffv!fallst!tkevans
INTERNET: tkevans%fallst@wb3ffv.ampr.org
OTHER: ...!attmail!fallst!tkevans
Tim Evans 2201 Brookhaven Court, Fallston, MD 21047 (301) 965-3286uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!pyramid!prls!mips!wyse!vsi1!ames!mailrus!cwjcc!tut.cis.ohio-state.edu!osu-cis!att!ihuxv!bareta
From: bareta@ihuxv.ATT.COM (Benyukhis)
Newsgroups: comp.unix.microport,comp.unix.xenix,misc.forsale
Subject: 80286 For Sale
Keywords: PC's Limited 80286 8/6 for sale
Message-ID: <3097@ihuxv.ATT.COM>
Date: 3 Jan 89 17:10:09 GMT
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 22
I have a 1 year old PC's Limited 286/AT 8/6 mhz keyboard
switchable for sale. It has a built in ROM setup routine
42 MB hard drive
1 1.2 MB floppy
1 360 K floppy
1024 Kbytes of RAM on the mother board
EGA board
Mitsubishi EGA monitor
2 serial ports
1 parallel port
1 game port
AT style keyboard (tactile feel)
Price: Asking $2400.00 or BEST OFFER.
Phone (312)998-5276 - home
(312)979-0307 - office
Will come out and help install the machine and software if
purchased in chcagoland area.
Will give away tons of software!!!!!!!!!!! (with machine purchase)uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/06/89)
Path: tolerant!voder!pyramid!prls!mips!wyse!vsi1!ames!killer!mjbtn!gsy1!root From: root@gsy1.UUCP (Scott Yates N4BBB) Newsgroups: comp.unix.microport,comp.unix.xenix Subject: Re: NEC P2200 driver for Microport UNIX 286 Summary: P2200 Drivers.. Keywords: NEC P2200, Microport UNIX 286, availability Message-ID: <22@gsy1.UUCP> Date: 2 Jan 89 14:10:01 GMT References: <1994@botter.cs.vu.nl> Organization: Yates Pest Control, Rockvale, TN, USA Lines: 16 In article <1994@botter.cs.vu.nl>, bagron@tjalk.cs.vu.nl (Rene Baart) writes: > I am looking for a printer driver for my NEC P2200 printer > that I can use with Microport UNIX 286. Does anyone know if > it is available and if it is, where I can buy it and how much > it costs ??? I am using an NEC P2200 on a 286 machine with SCO 286 Xenix. The only adjustment that I had to make was the selection of NL and CR Mapping. Otherwise, it has worked flawlessly. I hope you enjoy the P2200 as much as I have. -- Scott Yates, N4BBB o o DOMAIN: gsy@gsy1.UUCP || gsy@raider.UUCP Yates Pest Control \ / UUCP: ...!{ames,rutgers}!killer!mjbtn!gsy1!gsy Rockvale, Tennessee (OO) FIDO: Scott Yates at Net/Node 1:116/12 / 1:116/9 "Bugs are my Life!" <> VOICE: (615) 274-2156 / (615) 459-2636
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/07/89)
Path: tolerant!voder!apple!bloom-beacon!think!ames!oliveb!amdahl!pacbell!belltec!dar From: dar@belltec.UUCP (Dimitri Rotow) Newsgroups: comp.periphs,comp.unix.microport Subject: Re: tape streamers question Summary: QIC-36 vs QIC-02 Message-ID: <314@belltec.UUCP> Date: 23 Dec 88 02:17:09 GMT References: <1516@bebux.UUCP> <895@starfish.Convergent.COM> Organization: Bell Technologies, Fremont, CA Lines: 47 In article <895@starfish.Convergent.COM>, cdold@starfish.Convergent.COM (Clarence Dold) writes: > From article <1516@bebux.UUCP>, by henk@bebux.UUCP (Henk Dijkstra): > > I would like to purchase a tape-streamer however one of my wishes is > > that it is compatible with "frequently" used tape-streamers on UNIX systems. > > From what I hear that means I have to buy a "QIC-24" format compatible > One of the points Clarence makes needs clarification. There are two tape interface standards commonly used between PC boards and tape mechanisms. The QIC-36 interface is really a command interface whereas the QIC-02 interface is more of a bus adaptor spec. That's why QIC-36 cards are typically "long" format cards, because they contain the formatter/command electronics, while QIC-02 cards (being mere bus adaptors) tend to be short cards. Almost all streamers use the QIC-36 command interface. The original QIC-36 card was designed by Northern Telecom and put into mass production by Everex in their EV series. Since then, numerous third parties (Wangtek, etc) are building "PC36" compatible streamer tape controllers. The tape software most vendors use will work with all such cards (keeping in mind that any given driver is always vulnerable to changes in ROMs, PALS, and other individual design changes). In recent years tape electronics have advanced to the point that much of the formatting/command electronics can be integrated onto the tape mechanism's own circuit board. Thus the QIC-36 command interface can be buried inside the tape unit itself, allowing it to communicate to the host system via a QIC-02 bus adaptor. In a correctly implemented QIC-02/Tape system, the board/drive will look exactly the same to the device driver. Thus only one set of Bell Tech drivers is used for all Bell Tech tape devices, regardless of their size or whether the particular adaptor card plugged into the AT is a QIC-36 unit or a QIC-02. Again, keep in mind that any particular installation is vulnerable to version skew. For example, the PC36 style controllers (because some command intelligence and information is on the PC card) need to have their on-board firmware match the size of the tape, be it 60, 125, or 150 MB. One nice thing about QIC-02 is that since all of the implementation of the QIC-36 command interface is buried inside the drive, any correclty implemented QIC-02 controller will work with a QIC-02 interface tape mechanism, regardless of the tape unit's size, without need for firm ware changes on the controller. - dimitri rotow PS - My only regret is that Wangtek doesn't make their 60 MB unit as a QIC-02. Nice line of drives, but I wish we could source them all as QIC-02's and be done with the "long card" controllers.
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/07/89)
Path: tolerant!voder!apple!rutgers!mailrus!ames!killer!dcs!wnp From: wnp@dcs.UUCP (Wolf N. Paul) Newsgroups: comp.unix.microport Subject: Floppy Minor Device Numbers for V/AT Summary: Here is the information for V/AT 2.4 Message-ID: <270@dcs.UUCP> Date: 23 Dec 88 04:56:46 GMT Reply-To: wnp@dcs.UUCP (Wolf N. Paul) Organization: DCS, Dallas, Texas Lines: 94 In response to my recent posting asking for information about System V/AT floppy driver minor device numbers, a number of people sent me information, and after checking it all out with Microport Tech Support, I compiled the following information, which is here presented in the form of a C language header file. I hope it proves helpful to someone. John Sully said that a revised fl(7) manual page was supposed to go out with 2.4, but was somehow omitted; he promised to post it to the Uport BBS in the near future. In the meantime, here's this. ----cut here---- /* * floppy.h * Floppy Drive Minor Number Bit Definitions for System V/AT */ /* * Compiled by Wolf N. Paul (dcs!wnp@killer.dallas.tx.us) * based on information from Mark Zenier (markz@ssc.uucp) and * John Sully (jmsully@uport). * * This information is correct to the best of my knowledge, but * I make no warranties as to its correctness or usefulness for * any purpose. Use at your own risk (in other words, experiment * with it before relying on it!). * * I hope this information is helpful to someone. Comments and corrections * (but not flames) are welcome. * * Thu Dec 22 19:46:43 CST 1988 wnp@dcs.uucp */ /* * Layout of Bits in Floppy Device Minor Numbers: * * * Bit 0: 0=8 sectors/track, 1=9 sectors/track * * | Bit 1: 0=single sided, 1=doublesided * * | | Bit 2: 0=40 cylinders 1=80 cylinders * * | | | Bit 3: 0=Drive 0 (A:) 1=Drive 1 (B:) * * | | | | Bit 4: 0=HD (500 kbps) 1=DD * * | | | | | Bit 5: 0=5.25" Drive 1=3.5" Drive * * | | | | | | Bit 6: 0=doublestep 1=singlestep * * | | | | | | | Bit 7: 0=start on cyl 0 1=start on cyl 1 * | | | | | | | | * | | | | | | | | Min. Microport Names Name@dcs Note * 0 1 0 0 0 1 1 0 = 70 fd, fd096, fd096ds15, 0s24 fd0hd * 0 0 0 1 0 1 1 1 = 23 fd048, fd048ds9 fd0dd (HD Drive) * 0 1 0 1 0 0 1 1 = 83 fd048, fd048ds9 fd0dd (DD Drive) * 0 1 0 1 0 1 1 1 = 87 fd096ds9 fd0qd (5.25") * 0 1 1 1 0 1 1 1 = 119 fd0mf2dd fd0qd (3.5") * 0 1 1 0 0 1 1 0 = 102 fd0mf2hd fd0xd * * 0 1 0 0 1 1 1 0 = 78 fd196, fd196ds15 fd1hd * 0 0 0 1 1 1 1 1 = 31 fd148, fd148ds9 fd1dd (HD Drive) * 0 1 0 1 1 0 1 1 = 91 fd148, fd148ds9 fd1dd (DD Drive) * 0 1 0 1 1 1 1 1 = 95 fd196ds9 fd1qd (5.25") * 0 1 1 1 1 1 1 1 = 127 fd1mf2dd fd1qd (3.5") * 0 1 1 0 1 1 1 0 = 110 fd1mf2hd fd1xd * * 1 1 0 0 0 1 1 0 = 198 0s25 5.25" high density installit, drive 0 * 1 1 0 0 1 1 1 0 = 206 ???? 5.25" high density installit, drive 1 * 1 1 1 0 0 1 1 0 = 230 ???? 3.5" high density installit, drive 0 * 1 1 1 0 1 1 1 0 = 238 ???? 3.5" high density installit, drive 1 * * Some variations in these numbers can occur because certain bits override * other bits; i.e., unless bit 3 is 0 (HD, 15tps, 500 kbps), the setting of * bit 0 (9 tps) is irrelevant, it can be on or off without effect. * * The names for devices given in the "Name@dcs" column are the names I use * on my system; I find them more mnemonic than the names on the Microport * distribution floppies: * * dd=double density, 360K; qd=quad density, 720K; hd=high density, 1.2M; and * xd=eXtra high density, 1.44M. * * If I ever need names for "installit" floppies other than 0s25, I will * probably use the same names, substituting "if" for "fd". * */ #define FLMIN_9SECTOR 1 #define FLMIN_DBLSIDE 2 #define FLMIN_80TRACK 4 #define FLMIN_UNITNUM 8 #define FLMIN_DBLDENS 16 #define FLMIN_MICROFL 32 #define FLMIN_SGLSTEP 64 #define FLMIN_FSOFFST 128 ------cut here------ -- Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101 UUCP: killer!dcs!wnp ESL: 62832882 DOMAIN: dcs!wnp@killer.dallas.tx.us TLX: 910-380-0585 EES PLANO UD
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/07/89)
Path: tolerant!voder!apple!rutgers!ucsd!ames!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!ut-emx!mybest!moray!splut!jay From: jay@splut.UUCP (Jay "you ignorant splut!" Maynard) Newsgroups: comp.unix.microport Subject: Re: Keyboard lockup bug in 2.4 and 3.0e Message-ID: <790@splut.UUCP> Date: 23 Dec 88 12:33:11 GMT References: <1702@maccs.McMaster.CA> <281@uport.UUCP> Reply-To: jay@splut.UUCP (Jay "you ignorant splut!" Maynard) Distribution: na Organization: Confederate Microsystems, League City, TX Lines: 30 Posted: Fri Dec 23 06:33:11 1988 In article <281@uport.UUCP> plocher@uport.UUCP (John Plocher) writes: > Engineering is working on it now. It is a "High Priority" bug. > The problem is VERY keyboard/motherboard specific; it only shows > up here on one keyboard <mine :-( > and then only once a week or so. Amazing how high priority problems seem to affect someone's machine at Microport, while low priority problems don't. :-) :-) > I will post a note here when the fix is avaliable. >>2) What use is a support contract. > When the fix is avaliable, you can get it (no charge) just by calling > and asking for it. If you don't have a hotline support agreement, > you get to wait till the next release. Great. Does this mean that when I finally get my copy of 2.4 (which I STILL haven't gotten yet, despite my paid update contract that's just now a year old) that, if I have the keyboard-lock bug, that I'll have to revert to buggy old 2.3 until 2.5 is available?? Yeesh. What ever happened to the concept that a software vendor was selling basically working stuff, and users that experienced documented problems could get them fixed in accordance with the above premise? Why should I have to pay $150/year to get a working system? -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. hoptoad!academ!uhnix1!splut!jay +---------------------------------------- {killer,bellcore}!tness1! | Free Texas from its chains: SECEDE!!
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/07/89)
Path: tolerant!voder!apple!rutgers!ucsd!sdcsvax!ucsdhub!hp-sdd!ncr-sd!ncrlnk!uunet!attcan!utgpu!tmsoft!mcl!unibase!roe From: roe@unibase.UUCP (Roe Peterson) Newsgroups: comp.unix.microport Subject: Re: Efficient tape I/O, Followup. Message-ID: <105@unibase.UUCP> Date: 22 Dec 88 07:33:39 GMT References: <321@focsys.UUCP> Organization: EMIS Consulting, Regina, Saskatchewan, Canada Lines: 38 From article <321@focsys.UUCP>, by larry@focsys.UUCP (Larry Williamson): > | > | Streaming tape I/O with 386/ix seems to be rather slow. The drive > | is not streaming very well. It spends most of it's time stopping > | and starting. > ... description of many good attempts with dd, etc, deleted. > A 500k write takes about an hour! Here's the problem: it sounds like your operating system is either implementing tape I/O in a blocked fashion (ie: 1K blocks, no chance to change it), or it implements both, and your /dev/rmt0 should actually be called /dev/mt0. If find..|dd with a large block size does not change the duration of a write to the tape (listen to it - with large blocks, the forward motion is audibly much longer), the device driver is chopping data into small blocks for you (this is a nono). Raw device drivers (at least, for tape) are not supposed to do this. Some systems provide both blocked and character (true rawmode) tape devices- check your manual (try mt(4) or mt(7)). Incidentally, on systems with proper device drivers (ie, most I've seen), the best way to approach streaming speed is with a utility that uses shared memory between the writer and the tape device to collect input into larger blocks. The advantage here is that the writer will not block waiting for the output to occur. If there is enough interest, I'll post a small buffering utility to comp.sources.misc. Roe Peterson. -- Roe Peterson uunet!attcan!utgpu!tmsoft!mcl!unibase!roe
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/07/89)
Path: tolerant!voder!apple!rutgers!ucsd!ucbvax!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!hp4nl!ctisbv!pim From: pim@ctisbv.UUCP (Pim Zandbergen) Newsgroups: comp.unix.microport,comp.unix.xenix Subject: System V release 3.2 Message-ID: <616@ctisbv.UUCP> Date: 27 Dec 88 15:15:49 GMT Reply-To: pim@ctisbv.UUCP (Pim Zandbergen) Organization: CTI Software BV, The Hague, The Netherlands Lines: 26 Hi Netland, Now that Unix and Xenix will merge together into Unix System V release 3.2. it will not matter (I suppose) whether you buy SCO, Interactive, AT&T or some other vendor's implementation. In either case, you will be able to run both Unix COFF binaries as well as Xenix binaries. But we as software developers will have to maintain production of both the Unix and Xenix versions of our application software. This is because not all customers will want to upgrade to either Xenix 2.3 or Unix 3.2 and 286 owners will never be able to. However, we would like to produce both versions on one machine. Currently, for the Intel processors, we are supporting a Xenix 286 and a Unix 386 version of our software. Will it be possible to produce Unix and Xenix binaries with Unix 3.2, or otherwise, is it possible to install the Microsoft Xenix compiler on Unix 3.2 ? Any hints are welcome. -- --------------------+------------------------------------+--------------------- Pim Zandbergen | CTI Software BV | Phone: +31 70 542302 pim@ctisbv.UUCP | Laan Copes van Cattenburch 70 | Fax: +31 70 512837 ..!mcvax!ctisbv!pim | 2585 GD The Hague, The Netherlands | Telex: 32133 CTI NL
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/07/89)
Path: tolerant!voder!apple!bloom-beacon!tut.cis.ohio-state.edu!rutgers!bellcore!faline!thumper!ulysses!andante!alice!debra From: debra@alice.UUCP (Paul De Bra) Newsgroups: comp.unix.microport,comp.unix.xenix Subject: Re: Connecting Xenix with the outside world Keywords: Usenet, Ethernet, Yello, Mom's apple pie Message-ID: <8628@alice.UUCP> Date: 29 Dec 88 21:47:52 GMT References: <616@ctisbv.UUCP> <377@ispi.UUCP> <3423@ucdavis.ucdavis.edu> Reply-To: debra@alice.UUCP () Organization: AT&T, Bell Labs Lines: 23 In article <3423@ucdavis.ucdavis.edu> tuck@iris.ucdavis.edu (Devon Tuck) writes: >I keep hearing people ask about ethernet and usenet, and keep seeing people >who's Xenix system is a valid internet address. My question is, what does >it take to connect a Xenix system to the outside world? We are looking at >ethernet options, but right now we have only extension dispatched phone >lines. What kind of set up do people have to have so: ONE, they may be >mailed to at their machine from people through uucp, internet, etc and >TWO, so they may access the usenet. > Getting onto usenet only requires a modem and some software, which as I'm told is supplied by SCO at no cost. (you may need a better mailer than the standard one, but archive sites carry those.) Ethernet is a completely different story. Several companies offer "intelligent" ethernet boards and software for Xenix, including TCP/IP, the "r"-commands (rsh rlogin, ...) and ftp. I won't mention any names here as I don't want to advertise any product I don't actually know. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/07/89)
Path: tolerant!voder!apple!rutgers!mailrus!b-tech!zeeff
From: zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff)
Newsgroups: comp.unix.microport
Subject: Re: Green Hills 386 compiler
Keywords: gcc shared libraries
Message-ID: <5023@b-tech.ann-arbor.mi.us>
Date: 29 Dec 88 16:00:08 GMT
References: <293@ssbn.WLK.COM>
Reply-To: zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff)
Distribution: na
Organization: Branch Technology Ann Arbor, MI
Lines: 44
/*
This allows gcc (Green Hills) to be used with shared libraries
To install,
1) compile this program creating ld
3) cp /usr/ghs/BIN/386/lib/crt0.o to crt0.o.bak
4) cp /lib/crt1.o to /usr/ghs/BIN/386/lib/crt0.o
5) mv /bin/ld /bin/ld.real
6) mv this program (ld) to /bin/ld
7) cp /bin/gcc to /usr/gcc/cc
8) use -lc_s on your cc lines.
9) set your path to use /usr/gcc before /bin
Anything you compile should now used shared libraries
*/
#include <stdio.h>
main(argc,argv)
int argc;
char **argv;
{
int i;
char *new_argv[500];
for (i = 0; i < argc; ++i) {
new_argv[i] = argv[i];
}
new_argv[i++] = "/lib/crtn.o";
new_argv[i] = NULL;
execv("/bin/ld.real",new_argv);
return 1;
}
--
Jon Zeeff zeeff@b-tech.ann-arbor.mi.us
Support ISO 8859/1 zeeff%b-tech.uucp@umix.cc.umich.edu
Ann Arbor, MI umix!b-tech!zeeffuucp@tolerant.UUCP (UNIX-UNIX Cp) (01/07/89)
Path: tolerant!voder!apple!bloom-beacon!tut.cis.ohio-state.edu!mailrus!csd4.milw.wisc.edu!leah!itsgw!steinmetz!uunet!wa3wbu!john From: john@wa3wbu.UUCP (John Gayman) Newsgroups: comp.unix.microport Subject: Re: file size limits Summary: You have found "ulimit" Message-ID: <185@wa3wbu.UUCP> Date: 29 Dec 88 12:07:19 GMT References: <125@wybbs.UUCP> Distribution: usa Organization: WA3WBU, Marysville,PA Lines: 26 In article <125@wybbs.UUCP>, diekema@wybbs.UUCP (Jon Diekema) writes: > I am running version 2.4 of System V/AT and have noticed the following > behavior of cat: > > I was trying to concatenate 42-100k files togather and cat > complained about an output file error. No matter what I tried, > I couldn't get the output file larger then 1,228,800 bytes. You have hit upon the configured maximum file size on the standard release of V/AT or otherwise called "ulimit". It is set to the default of 2400 blocks which is the 1,228,800 bytes your referring to. You can change this to any value you wish. I beleive the release notes gives the proper syntax for using the "patch" command with the "ulpatch" paramter. I'm running V/386 and I don't quite recall the exact syntax on changing ulimit. You can tell what its currently set to just by typing "ulimit" at the prompt. John -- John Gayman, WA3WBU | UUCP: uunet!wa3wbu!john 1869 Valley Rd. | ARPA: john@wa3wbu.uu.net Marysville, PA 17053 | Packet: WA3WBU @ AK3P
news@tolerant.UUCP (The Daily Fishwrap) (01/07/89)
Path: tolerant!voder!apple!rutgers!njin!princeton!siemens!drexel!ipc From: ipc@drexel.UUCP (Image Processing Center) Newsgroups: comp.unix.microport Subject: Re: Ramdisks and microport unix Summary: INBOARD and bus memory. Message-ID: <845@drexel.UUCP> Date: 4 Jan 89 10:56:18 GMT References: <732@inuxh.UUCP> <5022@b-tech.ann-arbor.mi.us> Distribution: usa Organization: Drexel University, Phila., Pa. Lines: 27 In article <732@inuxh.UUCP> dyson@inuxh.UUCP (John Dyson) writes: >the top instead of from the bottom. Since I have an Inboard/386 and >only 3MB of its memory is 32bits and the top of the memory is supplied >by and Above Board, the ramdisk also keeps programs from executing from >the slow memory. The /unix runs in slow memory also, but I have not noticed Does any brand of '386 unix automatically allocate it's buffers (and maybe kernel space) starting from upper memory? If not, can it be made to do so? > You will find that the INBOARD works very well with bus memory if you perform the ollowing modifications: 1) Increase the bus speed to 10mhz. This usually requires only burning faster roms. 2) Replace the memory board with an Everex RAM 3000, which can run with 0 wait states at up to 10mhz using ordinary 120ns parts, and costs less than $100 unpopulated. The net improvment is to halve the access time of bus memory, according to the following formula: Tnew = Told (8/10) X (2/3) = 0.533 Told The result is that the difference in throughput will be negligible, and you won't have to scheme about memory allocation.
news@tolerant.UUCP (The Daily Fishwrap) (01/07/89)
Path: tolerant!voder!apple!bloom-beacon!tut.cis.ohio-state.edu!cs.utexas.edu!ssbn!texbell!egsner!spdyne!root From: root@spdyne.UUCP Newsgroups: comp.unix.microport Subject: Re: Setkey problem... Message-ID: <1700007@spdyne> Date: 4 Jan 89 21:08:00 GMT References: <1700002@spdyne> Lines: 56 Nf-ID: #R:spdyne:1700002:spdyne:1700007:004:2996 Nf-From: spdyne.UUCP!root Jan 4 15:08:00 1989 >I wrote: >> >> >> Greetings, >> >> I have sent this 8 ways to try to get it into uport... INCLUDING >> directly connecting to uport! No response... > >My guess is that are in fact not reaching a read account. Are you using the >"techs" account or are you going direct? Microport does reply to mail or >else they would see a lot more of this type of flame. (Which was quite common >not all that long ago.) > Well, I sent it to the following accounts: techs, plocher, jmsully. all at uport, with no luck.. (this was a couple of months ago, and I was giving them time to respond, not knowing how overloaded their time may be...) Refering to the original question: (Setkey) > >I feel (as apparently so does Microport) that an ioctl to one console device >should not affect ALL console devices. (Just as NDELAY on ttys should affect >only the tty set with NDELAY and not all ttys or even all fds open to that tty.) > >This behavior (albeit not exactly what you had in mind) is correct and should >stay the way it is. (How difficult is it to simulate using what is correct >behavior to make things be the way you want? My guess is a three line shell >script.) > >Good luck. > David F. Carlson, Micropen, Inc. Did I miss something here? You say that executing login on a DIFFERENT console terminal SHOULD Zap all of the setkey assignments on the console and every other /dev/cons*?!!? And the back it up with some something about ONLY affecting the ONE console device that it was executed on?? I don't understand. Did you understand my original question? I think that it should work AS DOCUMENTED: if executed on the console it will affect all consoles, if executed on a virt. console, it will affect ONLY that console. After some more checking, I found that if you execute setkey -d on any console, it will clear all of them. It seems that the other bug that I had, namely that reassigning a key that was once assigned causing it to scramble all of the assignments, no longer is a problem. (Now that I have upgraded to 3.0E. To fix the problem with it scrambling the assignments, I had a setkey -d in my .login (Before all of the other setkey's, I have fixed this by only executing setkey on the console.. but.. it still is broken.) -Chert Pellett
news@tolerant.UUCP (The Daily Fishwrap) (01/07/89)
Path: tolerant!voder!apple!bloom-beacon!tut.cis.ohio-state.edu!cs.utexas.edu!ssbn!texbell!egsner!spdyne!root From: root@spdyne.UUCP Newsgroups: comp.unix.microport Subject: Re: Setkey problem... Message-ID: <1700008@spdyne> Date: 4 Jan 89 23:14:00 GMT References: <1700002@spdyne> Lines: 67 Nf-ID: #R:spdyne:1700002:spdyne:1700008:004:2996 Nf-From: spdyne.UUCP!root Jan 4 17:14:00 1989 >I wrote: >> >> >> Greetings, >> >> I have sent this 8 ways to try to get it into uport... INCLUDING >> directly connecting to uport! No response... > >My guess is that are in fact not reaching a read account. Are you using the >"techs" account or are you going direct? Microport does reply to mail or >else they would see a lot more of this type of flame. (Which was quite common >not all that long ago.) > Well, I sent it to the following accounts: techs, plocher, jmsully. all at uport, with no luck.. (this was a couple of months ago, and I was giving them time to respond, not knowing how overloaded their time may be...) >> 1) Login on the console, type setkey f10 "echo hello^M" >> Test this by hitting F10, and it will `echo hello'. >> 2) Login to a normal user account on Cons2. >> 3) Switch to the console and Hit F10.... Surprise! you get >> <ESC>X or something....(an X echos)... it is as if you did >> a setkey -d on the console!... >> This seems to happen when you login to ANY of the consoles...a real pain >> in the ... if you are expecting your function keys to do something >> useful. > >I feel (as apparently so does Microport) that an ioctl to one console device >should not affect ALL console devices. (Just as NDELAY on ttys should affect >only the tty set with NDELAY and not all ttys or even all fds open to that tty.) > >This behavior (albeit not exactly what you had in mind) is correct and should >stay the way it is. (How difficult is it to simulate using what is correct >behavior to make things be the way you want? My guess is a three line shell >script.) > >Good luck. > David F. Carlson, Micropen, Inc. Did I miss something here? You say that executing login on a DIFFERENT console terminal SHOULD Zap all of the setkey assignments on the console and every other /dev/cons*?!!? And the back it up with some sorta bunk about ONLY affecting the ONE console device that it was executed on?? I don't understand. Do you? As for the how difficult is it to simulate.. I would have to reexecute the setkey assignements on the console EVERY time someone loggs into the virtual console port. True, I have a command to do this now, but really I think that it should work AS DOCUMENTED: if executed on the console it will affect all consoles, if executed on a virt. console, it will affect ONLY that console. After some more checking, I found that if you execute setkey -d on any console, it will clear all of them. It seems that the other bug that I had, namely that reassigning a key that was once assigned causing it to scramble all of the assignments, no longer is a problem. (Now that I have upgraded to 3.0E. To fix the problem with it scrambling the assignments, I had a setkey -d in my .login (Before all of the other setkey's, I have fixed this by only executing setkey on the console.. but.. it still is broken.) -Chert Pellett
news@tolerant.UUCP (The Daily Fishwrap) (01/07/89)
Path: tolerant!voder!apple!bloom-beacon!mit-eddie!rutgers!att!alberta!ubc-cs!van-bc!softop!jeff From: jeff@softop.UUCP (Jeff) Newsgroups: comp.unix.microport Subject: /dev/dsk for TWO fdisk partitions Keywords: fdisk disk Message-ID: <228@softop.UUCP> Date: 30 Dec 88 00:34:27 GMT Organization: Soft Options, Vancouver, BC. Lines: 21 I plan to purchase a 200M drive for a 286 based uPort system. 4 file systems on this drive is insufficient for my needs, so I wish to use fdisk to create 2 disk partitions, and then to divvy each partition into 4 filsys's. 1/ Will it work 2/ What are the correct parameters for the /dev/dsk and /dev/rdsk special files that will be needed ---------------------------------------------------------------------------- | Jeff Tate | 2425 Pandora Street, Vancouver, BC, Canada | | van-bc!softop!jeff | (604) 254-4583 | ---------------------------------------------------------------------------- -- ---------------------------------------------------------------------------- | Jeff Tate | 2425 Pandora Street, Vancouver, BC, Canada | | van-bc!softop!jeff | (604) 254-4583 | ----------------------------------------------------------------------------
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/07/89)
Path: tolerant!voder!apple!claris!ames!amdcad!sun!pitstop!sundc!seismo!uunet!uport!ken From: ken@uport.UUCP (Ken Chapin) Newsgroups: comp.unix.microport Subject: Re: Ramdisk usage on V/386 Keywords: ramd configuration Message-ID: <288@uport.UUCP> Date: 5 Jan 89 15:23:40 GMT References: <176@wa3wbu.UUCP> <6515@killer.DALLAS.TX.US> <144@inxsvcs.UUCP> Reply-To: ken@uport.UUCP (Ken Chapin) Organization: Microport Systems, Scotts Valley, CA Lines: 6 In article <144@inxsvcs.UUCP> mwg@inxsvcs.UUCP (Phil Blecker) writes: >I took ramd out of /etc/atconf/systems/system.std without any problems. There >appears to be a way to change the size of the "disk", but I don't want one By changing a few things in the space.c of modules/ramd, the ram disk can be configurable.
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/07/89)
Path: tolerant!voder!apple!claris!ames!amdcad!sun!pitstop!sundc!seismo!uunet!uport!ken From: ken@uport.UUCP (Ken Chapin) Newsgroups: comp.unix.microport Subject: Re: file size limits Keywords: patch Message-ID: <289@uport.UUCP> Date: 5 Jan 89 15:52:54 GMT References: <125@wybbs.UUCP> Reply-To: ken@uport.UUCP (Ken Chapin) Distribution: usa Organization: Microport Systems, Scotts Valley, CA Lines: 16 In article <125@wybbs.UUCP> diekema@wybbs.UUCP (Jon Diekema) writes: >I am running version 2.4 of System V/AT and have noticed the following >behavior of cat: > > I was trying to concatenate 42-100k files togather and cat > complained about an output file error. No matter what I tried, > I couldn't get the output file larger then 1,228,800 bytes. > There must be some limit that I am hitting. Try "patch /unix Ulpatch" as super-user. That will report the current value. To change this value, type "patch /unix Ulpatch 0x???" where ??? is a hex value. This value controls the maximum size file a non-super-user can write. Ken Chapin UUCP: ...!{sun | ucbvax | ihnp4}!amdcad!uport!ken Microport Systems Technical Support
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/07/89)
Path: tolerant!voder!apple!claris!ames!amdcad!sun!pitstop!sundc!seismo!uunet!uport!ken From: ken@uport.UUCP (Ken Chapin) Newsgroups: comp.unix.microport Subject: Re: Setkey problem... Keywords: Compaq, Merge, no floating point Message-ID: <290@uport.UUCP> Date: 5 Jan 89 16:25:50 GMT References: <1700002@spdyne> <1700006@spdyne> Reply-To: ken@uport.UUCP (Ken Chapin) Organization: Microport Systems, Scotts Valley, CA Lines: 17 In article <1700006@spdyne> root@spdyne.UUCP writes: > I guess that I forgot to include that I'm running the DOS-Merge Kernel. > [3.0e - Unlimited] With a Digi-Board 8 port Int. Comm. controller. > >On a Compaq 386/20 if that matters... It consistantly does this.. >And I have 13 things defined....(Does this matter??) > >Also, It would be nice if U-Port would compile ALL programs that use floating >point under gcc so that THEY WOULD WORK!! (Awk fails on my machine - Dumps >core).. Specific to the Compaq I'm told...Any chance I can get a floppy with Call up tech support. We have a fix for people with (Compaqs, no coprocessor, Merge kernel). Ken Chapin UUCP: ...!{sun | ucbvax | ihnp4}!amdcad!uport!ken Microport Systems Technical Support
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/07/89)
Path: tolerant!voder!apple!rutgers!ucsd!sdcc6!sdcc19!sdcc15!pa1293 From: pa1293@sdcc15.ucsd.edu (pa1293) Newsgroups: comp.unix.microport Subject: Re: Compaq 386/25mhz bugs Keywords: Compaq, fuser, getty Message-ID: <836@sdcc15.ucsd.edu> Date: 5 Jan 89 20:09:15 GMT References: <4464@pbhyf.PacBell.COM> Reply-To: pa1293@sdcc15.UUCP () Organization: University of California, San Diego Lines: 25 In article <4464@pbhyf.PacBell.COM> jlkar@pbhyf.PacBell.COM (SRVAC 4w400ee-John L. Karsner) writes: >1) I hooked up a NEC 2420/30 (2400baud) modem to port 0 and found a very >interesting little annoyance. That is, when calling into the machine from the >outer worlds and trying to log off, you can't. Well I mean you can't do it the >normal way. Upon entering ^D or exit at your prompt, this darn thing spawns >a new getty so fast that you get a login in prompt once again. The only thing >that really works and does not leave the modem hung is to logout using the >command stty 0. I called tech support and they confirmed this little bug for try putting this in .profile as a temporary fix. logout () { banner "Bye Bye!!!" stty 0 } trap logout 0 this will leave the logout function in the lowest level shell and will log the user out using "stty 0" even if ctrl-D is hit. I use this method on my account to log both logins and logouts to a file and it has not failed so far. ----------------- John Marco pa1343@sdcc15.ucsd.edu
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/07/89)
Path: tolerant!voder!apple!rutgers!mailrus!uflorida!novavax!twwells!bill
From: bill@twwells.uucp (T. William Wells)
Newsgroups: comp.unix.microport
Subject: Re: Where do crash dumps go on V/386 ?
Message-ID: <296@twwells.uucp>
Date: 5 Jan 89 19:01:12 GMT
References: <183@wa3wbu.UUCP>
Reply-To: bill@twwells.UUCP (T. William Wells)
Organization: None, Ft. Lauderdale
Lines: 15
In article <183@wa3wbu.UUCP> john@wa3wbu.UUCP (John Gayman) writes:
: I managed to panic my 386 system running V/386 while ...
: It came up telling me
: it was saving a "crash" or "image" file containing 1532 pages. Then
: waited for me to re-boot it. Question: where did it put this file ?
: I assume it dumped it somewhere to disk ? I would like to remove it.
It dumps it to your swap partition. If you want the dump, you copy
your swap partition to some file early in the boot sequence.
Otherwise, the dump just gets overwritten when the system wants the
swap space.
---
Bill
{ uunet!proxftl | novavax } !twwells!billuucp@tolerant.UUCP (UNIX-UNIX Cp) (01/07/89)
Path: tolerant!voder!apple!rutgers!att!whuts!homxb!genesis!odyssey!gls From: gls@odyssey.ATT.COM (g.l.sicherman) Newsgroups: comp.unix.microport Subject: superslow mode on 6386 WGS Message-ID: <773@odyssey.ATT.COM> Date: 5 Jan 89 18:11:24 GMT Organization: AT&T Bell Laboratories, West Long Branch, NJ Lines: 14 I'm running AT&T Vr3.2 on a 6836 WGS. Our application programs do a lot of message-passing. Now and then the system goes into "superslow" mode. Response time is measured in minutes. Keyboard input loses data if you type faster than 15 cpm. The only useful symptoms are (1) heavy floppy I/O (apparently), and (2) the bdflush process seems to have a lot of CPU time (5 minutes). Has anybody else seen this problem? Fixed it? And what's bdflush? -- G. L. Sicherman gls@odyssey.att.COM
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/07/89)
Path: tolerant!voder!apple!rutgers!cmcl2!phri!marob!daveh From: daveh@marob.MASA.COM (Dave Hammond) Newsgroups: comp.unix.microport,comp.unix.xenix Subject: Re: Which one: Interactive, Microport, Xenix? Message-ID: <445@marob.MASA.COM> Date: 5 Jan 89 20:07:15 GMT References: <2410@stiatl.UUCP> <324@belltec.UUCP> Reply-To: daveh@marob.masa.com (Dave Hammond) Distribution: usa Organization: ESCC New York City Lines: 20 In article <324@belltec.UUCP> dar@belltec.UUCP (Dimitri Rotow) writes: >In article <2410@stiatl.UUCP>, todd@stiatl.UUCP (Todd Merriman) writes: >> Our company is trying to select a Unix (Sys. V) for 386. On the >> basis of: [...] >> What are your suggestions? >Ours, of course. [...] I have all the respect in the world for Dimitri Rotow and the Bell Tech organization, but newsgroups are NOT an appropriate forum for commercial advertisements. And the XENIX newsgroup, especially, is no place for the president of Bell Tech to pitch his own (competing) firm's software. I have nothing against satisfied consumers of a software package extolling said package's virtues [in fact, I preach of SCO's qualities whenever appropriate], however I find Mr. Rotow's article to be blatant commercialism and out of character with the spirit of Usenet. -- Dave Hammond ...!uunet!masa.com!{marob,dsix2}!daveh
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/07/89)
Path: tolerant!voder!apple!bloom-beacon!think!ames!mailrus!cornell!batcomputer!itsgw!steinmetz!uunet!uport!dougm From: dougm@uport.UUCP (Doug Moran) Newsgroups: comp.unix.microport Subject: Re: How does Microport System V/AT handle bad blocks? Message-ID: <291@uport.UUCP> Date: 5 Jan 89 17:36:54 GMT References: <460@tarpit.UUCP> <326@focsys.UUCP> <464@tarpit.UUCP> <2689@nuchat.UUCP> <211@trevan.UUCP> Reply-To: dougm@uport.UUCP (Doug Moran) Organization: Microport Systems, Scotts Valley, CA Lines: 19 In article <211@trevan.UUCP> trevor@trevan.UUCP (trevor) writes: >This must be the worst bug in Microports system and is worse than most >viruses. Why didnt Microport warn us of this problem? If they knew >about it I think it was totally negligent of them not to have told us. In the Release Notes for Release 2.4 of System V/AT, on page R-21, is the following: "File systems greater than approx. 130000 blocks experience corruption over time that fsck can't repair. fsck may report negative numbers and corrupt the file system further (#605)." There *is* a bug in fsck, we *are* aware of it, and we *are* trying to fix it. And we did try and warn you. How can we we warn you better (no sarcasm intended; I am trying to make the Release Notes etc. more user-friendly)? Doug Moran, Tech. Pubs.
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/07/89)
Path: tolerant!voder!apple!rutgers!mailrus!ncar!tank!mimsy!haven!grebyn!johnk
From: johnk@grebyn.COM (John Kennedy)
Newsgroups: comp.unix.microport
Subject: Problems with compiles on Sys V/AT; compress.c; large model
Message-ID: <11732@grebyn.COM>
Date: 6 Jan 89 02:58:38 GMT
Reply-To: johnk@grebyn.com (John Kennedy)
Distribution: na
Organization: Grebyn Corp. & Timesharing
Lines: 24
Anyone had success with the 286 architecture and compiling the *compress.c*
program from the archives? Here's the scenario:
1) decompressed compress.c.Z on host system (3B2, not 286 or uport)
2) downloaded compress.c from host system.
3) compiled compress.c from Makefile
4) added -DM_XENIX to Makefile to alleviate "too large array" errors
5) got link time errors indicating compile should be done with large model
6) added -Ml to Makefile to recompile with large model
7) compiles completed without errors
8) executed compress to decompress another program.c.Z, and much
garbage was generated in output.
I find it hard to believe that *compress*, even with its many options, has
never been compiled in the Microport System V/AT environment. I would rather
believe that I haven't found the right flags to define at compile time.
Any suggestions from anyone who has made it work?
Please email any ideas to johnk@grebyn.com
Thanks,
Johnuucp@tolerant.UUCP (UNIX-UNIX Cp) (01/07/89)
Path: tolerant!voder!apple!rutgers!mailrus!ames!killer!texbell!egsner!spdyne!root From: root@spdyne.UUCP Newsgroups: comp.unix.microport Subject: Re: System Crash Message-ID: <1700009@spdyne> Date: 5 Jan 89 21:24:00 GMT References: <249@cosi.UUCP> Lines: 46 Nf-ID: #R:cosi.UUCP:249:spdyne:1700009:004:1146 Nf-From: spdyne.UUCP!root Jan 5 15:24:00 1989 In reference to the virtual consoles question: >>> Do I have to bring the System down or what? >>> >> >> You should not have to bring the system down. The only exception >>to what you and I are doing is that I did not use the plain vanilla >>kernel that came with the system. I immediately generated a kernel >>with the Everex Tape driver, rebooted and then added the extra >>consoles. I did not do anything in linkkit to enable them. It is >[...] > >Use patch to look at a kernel variable called 'kd_numttys'. I This >is (I think) the maximum number of virtual consoles. It is set in the >linkkit to be 32. It may however only be four in the distributed >version. > >-brian Well, no luck, I too don't have a plain vanilla system, I have linked in a Digi-board driver for additional comm ports.. (Comm/Xi board). I looked at that variable and it came back 0x20 or 32 just like yours. So what do I try next? - Chert Pellett root@spdyne -- Brian D. Cuthie uunet!umbc3!cbw1!brian Columbia, MD brian@umbc3.umd.edu /* End of text from spdyne:uport */
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/07/89)
Path: tolerant!voder!apple!rutgers!uwvax!tank!mimsy!dftsrv!ames!pasteur!ucbvax!hplabs!hp-sdd!ncr-sd!serene!rfarris From: rfarris@serene.UUCP (Rick Farris) Newsgroups: comp.unix.microport,comp.unix.xenix Subject: Re: Which one: Interactive, Microport, Xenix? Message-ID: <267@serene.UUCP> Date: 6 Jan 89 09:22:39 GMT References: <2410@stiatl.UUCP> <324@belltec.UUCP> <445@marob.MASA.COM> Reply-To: rfarris@serene.UUCP (Rick Farris) Followup-To: alt.flame Distribution: usa Organization: RF Engineering, Del Mar, California Lines: 15 In article <445@marob.MASA.COM> daveh@marob.masa.com (Dave Hammond) writes: > ... but newsgroups are NOT an appropriate forum for commercial > advertisements. You think that's a problem? We were just suckered into creating an entire newsgroup (comp.lang.sigplan) so that ACM/SIGPLAN could advertise their (for pay) seminars. An entire newsgroup so that one small faction of the usenet community could make money. And they have the gall to moderate it, and refuse access to anyone that doesn't kick into their kitty. Rick Farris RF Engineering POB M Del Mar, CA 92014 voice (619) 259-6793 rfarris@serene.cts.com ...!uunet!serene!rfarris serene.UUCP 259-7757
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/07/89)
Path: tolerant!voder!pyramid!oliveb!ames!hc!pprg.unm.edu!unmvax!tut.cis.ohio-state.edu!rutgers!att!mtuxo!mtgzy!mtgzz!avr From: avr@mtgzz.att.com (a.v.reed) Newsgroups: comp.unix.microport,comp.unix.wizards,comp.unix.questions,comp.unix.xenix Subject: Prentice-Hall exclusive? Summary: I don't think its true Message-ID: <4837@mtgzz.att.com> Date: 5 Jan 89 21:45:31 GMT References: <363@siswat.UUCP> <322@belltec.UUCP> Organization: AT&T, Middletown NJ Lines: 14 In article <322@belltec.UUCP>, dar@belltec.UUCP (Dimitri Rotow) writes: > If you want to buy it from us, we can't sell it to you (since it is > UNIX licensed material and AT&T has given Prentice Hall an exclusive > on selling UNIX manuals outside of an association with a UNIX software > license) *unless* you also buy 3.2. Their rules, not ours. An exclusive to Prentice Hall? I doubt it, especially since UNIX-related stuff is usually available either to anyone willing to pay for it, or to no-one, with the possible exception of academic researchers, outside the company. I know for a fact that CBS College Publishing, and its Holt, Rinehart and Winston subsidiary, also publich reprints of AT&T UNIX(R) documentation; there may be others. Adam Reed (avr@mtgzz.ATT.COM)
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/07/89)
Path: tolerant!voder!pyramid!amdahl!pacbell!ditka!cocktrice!mdm From: mdm@cocktrice.UUCP (Mike Mitchell) Newsgroups: comp.unix.microport Subject: Re: uPort 2.4 'cron' and/or HDB 'Poll' Message-ID: <359@cocktrice.UUCP> Date: 6 Jan 89 00:33:38 GMT References: <491@fallst.UUCP> Reply-To: mdm@cocktrice.UUCP (Mike Mitchell) Organization: Mike's Playground, Santa Fe, New Mexico Lines: 26 In article <491@fallst.UUCP> tkevans@fallst.UUCP (Tim Evans) writes: >I'm finding that uPort 2.4 seems to have corrected the old 'cron' bug >(i.e., everything ran twice), _except_ with respect to UUCP calls >generated by the HDB 'uudemon.poll'. These still seem to get generated >in twos. (I run this script via cron every half hour, then run >'uusched' a little later--also every half hour.) Whenever >'uudemon.poll' generates its "phony" work file for a system, it seems >to do so in such a way that the remote system gets called _twice_, >a half hour apart. The fix to this is quite easy to do, it is documented in the HDB install documentation (if you can get a copy). In the file /usr/lib/uucp/Maxuusched place a single line which reads "1". The default distribution is "2", hence two copies of uusched can run at the same time. In the file /usr/lib/uucp/Maxuuxqts place a single line which reads "1". The default distribution also contains "2". -- Mike Mitchell BELL: (505) 471-7639 2020 Calle Lorca #43 ARPA: mdm@cocktrice.UUCP Santa Fe, NM 87505 UUCP: ...!uunet!dmk3b1!cocktrice!mdm
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/08/89)
Path: tolerant!voder!apple!rutgers!att!ihuxv!bareta From: bareta@ihuxv.ATT.COM (Benyukhis) Newsgroups: comp.unix.microport,comp.unix.xenix,comp.sys.ibm.pc,comp.sys.intel Subject: 386 Motherboards vs. Acceleratr Boards Keywords: From 286 to 386 Message-ID: <3106@ihuxv.ATT.COM> Date: 6 Jan 89 20:32:34 GMT Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 15 Need a lot of advice on upgrading 286 to 386 (ideally one would sell one and buy the other... but it is impossible to sell the used machine for as much as you have already invested so ....) I am looking for an information on how to upgrade an AT type machine to a 386 i.e what are the available products, known limitations, etc. For information: I have a PC's Limited 286 AT 6/8Mhz switchable with Phoenix BIOS, 40Mb ST-251, EGA, and 3MB (120 or 100 ns RAM) 1024 on the mother board and 2Mb on the Everex Ram board (3000 I beleive) I need all of the information I can gather (prices too if known) Will summarize the results to the net. Thanks much, Edward Benyukhis
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/08/89)
Path: tolerant!voder!apple!claris!ames!amdcad!sun!pitstop!sundc!seismo!uunet!ateng!chip From: chip@ateng.ateng.com (Chip Salzenberg) Newsgroups: comp.unix.wizards,comp.unix.microport,comp.emacs Subject: Checking return values of system calls Message-ID: <1989Jan6.173809.15868@ateng.ateng.com> Date: 6 Jan 89 22:38:07 GMT References: <828@ubu.warwick.UUCP> <28173@tut.cis.ohio-state.edu> <10960@bigtex.cactus.org> <8791@wright.mips.COM> <1138@csuchico.EDU> <429@lehi3b15.UUCP> <121@cbw1.UUCP> <8525@alice.UUCP> <448@myab.se> <8547@alice.UUCP> Followup-To: comp.unix.wizards Organization: A T Engineering, Tampa, FL Lines: 22 [followups directed to comp.unix.wizards] In article <448@myab.se> lars@myab.UUCP (Lars Pensj|) reminds us that all programs should check return values of system calls, such as write(). This is obviously good policy. However, according to debra@alice.UUCP (Paul De Bra): >... unfortunately very few programs actually do this for read and write... >Reasons are obvious: programmers are a bit lazy, and the programs become >smaller and faster if you don't check. (so not checking also makes your >system look better in benchmarks which use standard utilities...) This misconception about "efficiency" is, alas, all too common. Checking the return values of system calls takes some programmer time during coding, but this is more than returned during debugging and use. ("A bit lazy"? Try "lazy enough to get fired"!) And as for execution speed: how long does an integer comparison take? Certainly not enough to worry about, once you've accepted the overhead of a kernel trap. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/08/89)
Path: tolerant!voder!apple!rutgers!mit-eddie!uw-beaver!cornell!batcomputer!itsgw!steinmetz!uunet!ficc!peter From: peter@ficc.uu.net (Peter da Silva) Newsgroups: comp.unix.microport,comp.unix.xenix Subject: Re: Which one: Interactive, Microport, Xenix? Message-ID: <2650@ficc.uu.net> Date: 6 Jan 89 20:01:00 GMT References: <2410@stiatl.UUCP> <324@belltec.UUCP> <445@marob.MASA.COM> Distribution: usa Organization: Xenix Support Lines: 19 In article <445@marob.MASA.COM>, daveh@marob.MASA.COM (Dave Hammond) writes: > I have all the respect in the world for Dimitri Rotow and the > Bell Tech organization, but newsgroups are NOT an appropriate forum for > commercial advertisements. And the XENIX newsgroup, especially, is no place > for the president of Bell Tech to pitch his own (competing) firm's software. Why not the Xenix newsgroup, particularly? This is the closest there is to a comp.unix.intel, after the attempt to create that newsgroup was so badly fumbled. Maybe it's time to resubmit a request for comp.unix.intel? No fancy footwork with renaming comp.unix.xenix or comp.unix.microport... just a new group for discussing intel-based UNIX systems. Maybe split it into .i386 and .i286, but no more. Let .xenix and .microport revert to their original charter. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/08/89)
Path: tolerant!voder!pyramid!decwrl!decvax!tektronix!uunet!fsc2086!jim From: jim@fsc2086.FSC.COM (Jim O'Connor) Newsgroups: comp.unix.microport Subject: Re: /dev/dsk for TWO fdisk partitions Keywords: fdisk disk Message-ID: <374@fsc2086.FSC.COM> Date: 6 Jan 89 23:20:26 GMT References: <228@softop.UUCP> Organization: Filtration Sciences Corp., Chattanooga, TN Lines: 24 In article <228@softop.UUCP>, jeff@softop.UUCP (Jeff) writes: > I plan to purchase a 200M drive for a 286 based uPort system. > > 4 file systems on this drive is insufficient for my needs, > so I wish to use fdisk to create 2 disk partitions, and then > to divvy each partition into 4 filsys's. Just out of curiousity, what application would need or require 8 separate 25Meg filesystems? > 1/ Will it work I don't know if you can do it, but I have a suspicion you may have trouble mounting 9 filesystems (the 8 on this drive, plus at least /dev/root), unless you re-link the kernel and specify a larger maximum mounted file system number. Since the data structures pertaining to mounted file systems are fairly large, this may not be easy, if your kernel is already close to the max size allowable. --jim ------------- James B. O'Connor jim@FSC.COM Filtration Sciences Corp. +1 615 821 4022 x651 105 W. 45th St. - Chattanooga, TN 37409
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/08/89)
Path: tolerant!voder!apple!bbn!csd4.milw.wisc.edu!uwmcsd1!marque!uunet!mcvax!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.unix.microport
Subject: Re: >4 virtual cons on V/AT 2.4
Message-ID: <485@aber-cs.UUCP>
Date: 6 Jan 89 21:45:31 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Distribution: eunet,world
Organization: Dept of CS, UCW Aberystwyth, Wales
(Disclaimer: my statements are purely personal)
Lines: 44
In article <197@wa3wbu.UUCP> you write:
Has Anyone added more than the default 4 virtual consoles to
Microport V/AT 2.4 ? On 2.3 all that was required was to add the
device names and edit inittab. 2.4 seems to be hard coded in the config
for only 4. What is the procedure for adding addition virtual consoles,
say like 10 total ? Thanks!
I have eight consoles here without problems. All you have to do
is to look at the dfile.wini file, line that begins with 'kd' and
modify it to
kd 0 8 * maximum of 8 virtual consoles
if it is not already 8. Then either you use /etc/vcon, that automagically
creates the /dev/cons? files it needs, or you create them yourself and use
/etc/getty on each of them.
Note that the major device number is 0, not 5 like I saw in another posting:
/etc/mknod /dev/cons7 c 0 7
Two words of advice:
Don't use /etc/vcon, it behaves funnily (somebody posted a list of funnies,
maybe it was you). Use /etc/getty.
Better still, use uutty, for console, local and dialin logins. A bit quicker,
a bit safer, you have sources... It works virtually out of the box; with a
couple of lines of modification it works better (add MAIL to the environment,
have /etc/issue copied to stdout before asking login:, output a newline in
the state entered after the password is read). Other little mods were
described in some previous posting by sombody, either here or comp.unix.xenix.
Overall I am quite more pleased with 2.4 than with 2.3; in particular the
disk driver looks, well, significantly improved. Some fairly awful
(documented!) bugs remain, e.g. in the compiler, fsck, dcopy, sdb, floating
point handling, but is quite more usable. Still it is no match for
SysV3.2/386, and I am going to get it (my 386 machine has just arrived) as
soon as I decide which supplier to choose.
--
Piercarlo "Peter" Grandi | INET: pcg%cs.aber.ac.uk@nss.cs.ucl.ac.uk
Dept of CS, UCW Aberystwyth, Wales | UUCP: ...!mcvax!ukc!aber-cs!pcguucp@tolerant.UUCP (UNIX-UNIX Cp) (01/08/89)
Path: tolerant!voder!apple!rutgers!mailrus!csd4.milw.wisc.edu!nic.MR.NET!eta!dbright From: dbright@eta.unix.ETA.COM (David A. Bright) Newsgroups: comp.unix.microport,comp.unix.xenix Subject: Advice on 386 systems needed Message-ID: <906@elroy.unix.ETA.COM> Date: 7 Jan 89 17:54:09 GMT Reply-To: dbright@unix.eta.com (David A. Bright) Distribution: usa Organization: ETA Systems, Inc., St Paul, MN Lines: 29 Posted: Sat Jan 7 11:54:09 1989 I am considering the purchase of a 386 machine to replace my current 286 machine. I would like to solicit all opinions on what machines people might recommend or condemn. My objective is to get a machine that will run a 386 version of Unix (Microport, Interactive, Everex Enix, etc.) and to get one at the least possible initial outlay of money. I can cannibalize my 286 for video (Hercules) and some memory, if need be. Specific things I need to know about: What motherboards are better than others? What BIOS is better than others? What vendors are better than others? Secondly, I need the following in the Unix version I buy: Tape drivers (I already have a Sysgen 4540 controller (QIC-36) and Wangtek tape drive, but can't get it to work with Microport System V/AT 2.4, I suspect that it is because the controller appears not to be interrupt-driven), X-windows (maybe even with a Hercules driver?), and ability to support RLL, SCSI, and/or ESDI disk drives. I will also be glad to receive comments about the various versions of Unix (I've heard of Enix, but not been able to locate a vendor; any pointers?). Thanks in advance to all those who will respond. Please reply directly to me, as I know this has been discussed before on the net and doesn't need to be rehashed. -- David A. Bright 910 W. Burke Avenue dab@Bright.MN.ORG (Home) Roseville, MN 55113 dbright@unix.ETA.COM (Work) 612 487-2407 (Voice) 612 487-2416 (Data)
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/08/89)
Path: tolerant!voder!apple!bbn!csd4.milw.wisc.edu!mailrus!ncar!ames!elroy!cit-vax!tim From: tim@cit-vax.Caltech.Edu (Timothy L. Kay) Newsgroups: comp.unix.microport,comp.unix.xenix Subject: differences in Xenix and the rest Message-ID: <9049@cit-vax.Caltech.Edu> Date: 7 Jan 89 23:50:28 GMT Reply-To: tim@cit-vax.UUCP (Timothy L. Kay) Distribution: usa Organization: California Institute of Technology Lines: 20 I am in the market for a Unix for a 386. I was considering Microport, but I have heard many bad things, and now they have raised their prices. I have looked into 386/ix and the rest of the version derived from the base port done for AT&T by Intel/Interactive/etc.,etc.,etc. I have decided that it is now time to consider Xenix. I have several questions: 1. Now that SVR3.2 is out (with the Xenix merged stuff), is SCO Xenix just another derivation from the same sources? 2. Is the Xenix that Microsoft is selling just a repackaging of SCO Xenix? Are they up to date? 3. If the answer to either of the two previous question is no, then what are the differences? Tim
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/08/89)
Path: tolerant!voder!apple!rutgers!mailrus!ncar!ames!killer!wybbs!jdbbs!diekema
From: diekema@jdbbs.UUCP (Jon Diekema)
Newsgroups: comp.unix.microport
Subject: Trying to make an Everex 125 Meg tape system work (long)
Keywords: Everex, Wangtek, Cartridge tape, QIC-36, Tape backup
Message-ID: <8@jdbbs.UUCP>
Date: 7 Jan 89 19:04:13 GMT
Organization: JD's connection, Jenison, MI
Lines: 266
I am having trouble getting my Everex Stream 125 Tape sub-system
to work under System V/AT version 2.4.0. The Everex Stream
125 package has the following components:
o Everex QIC-36 Tape controller, EV-831 Rev F
o Wangtek 125Meg DC600A cartridge tape drive
The hardware configuration that I am using is:
Computer: Suntek ATEGA 1000 (AT Clone)
Processor: 80286 6/12 Mhz (12 Mhz with 1 wait state)
Ports: 1 Parallel 2 Serial (all on the Motherboard)
Bios: Phoenix 80286 ROM BIOS Version 3.00 9/1
Memory: 5 Meg total
640k base 384k expansion on the motherboard
"The King Bishop" 4 Meg card from Micron Technology
Monitor: NEC Multisync JC-1401P3A
Video card: Paradise Auto Switch EGA
Modem: Evercom 2400 from Everex (internal)
Printer: Microline 82A from Okidata
80 columns 120 CPS with tractor feed
Floppy disk: 1.2M Teac FD-55GFV-17-U
Hard Disk: Miniscribe 6085, 71.3 Meg, 1024 Cylinders 8 Heads
Controller card: WDC 1985 vintage, WD1003-WA2
Line printer Devices:
lp0 - NOT used
lp1 - connected to a Okidata printer
lp2 - NOT used
COM Devices:
COM1 - serial port located on the motherboard
/etc/ttypatch -t0 -a1016 -i4 -m0x0c
COM2 - Evercom 2400 baud internal modem
/etc/ttypatch -t1 -a760 -i3 -m0x08
The EV-831 tape controller is configured as follows:
o Port 300-301, IRQ 5, DRQ 1, DACK 1
The Everex tape diagnostics, that run under MS-DOS, report a clean
bill of health. This gives me a strong indication that the cables
are connected correctly, and the tape controller is configured in
a reasonable manner. The standard UNIX kernel (version 2.4.0) didn't
come with the Everex tape driver installed. The link kit needed to
be run to create a kernel with this driver in place. There are two
files that needed to be modified, and they are shown below:
$ cat /usr/linkkit/cf/master
* %W%
*
* The following devices are those that can be specified in the system
* description file. The name specified must agree with the name shown.
*
* blk chr
* name vector hndlrs type prefix maj maj max # struct decl.
*----- ------ ------ ---- ------ --- --- ----- ----------------
*
wini 46 ocrwi rbc hd 0 4 4
flop 38 socrwi rbc fd 1 6 4
rdswap 0 ocrwi rbc rd 2 11 1
asy 36,35 ocrwi ctn asy 0 5 4
sema 0 sx so sem 0 0 1
mesg 0 s so msg 0 0 1
shmem 0 fex so shm 0 0 1
sxt 0 ocrwi co sxt 0 12 32
lp 39 ocwis c lp 0 7 3
cmos 0 rw co cmos 0 8 1
ev 37 ocrw c ev 0 9 1
kd 33 ocrwis cot kd 0 0 64
*
* The following devices must not be specified in the system description
* file. They are here to supply information to the config program.
*
memory 0 rwi srco mm 0 1 1
tty 0 orwi srco sy 0 2 1
errlog 0 ocrs srco err 0 3 1
$$$
*
* The following entries form the alias table.
*
dsk wini
$$$
*
* The following entries form the tunable parameter table.
*
buffers NBUF
inodes NINODE
files NFILE
mounts NMOUNT
swapmap SMAPSIZ
coremap CMAPSIZ
calls NCALL
procs NPROC
texts NTEXT
clists NCLIST
sabufs NSABUF 0
power POWER 0
emul EMUL_0 1
maxproc MAXUP 25
* hashbuf must be a power of 2
hashbuf NHBUF 64
physbuf NPBUF 4
csibnum CSIBNUM 20
vpmbsz VPMBSZ 8192
vpmnexus VPMNEXUS 0
x25links X25LINKS 1
x25bufs X25BUFS 256
x25nexus X25NEXUS 0
x25bytes X25BYTES (16*1024)
bx25links BX25LINKS 2
bx25bufs BX25BUFS 80
bx25bytes BX25BYTES (16*1024)
bx25hlprot BX25HLPROT 2
bx25nexus BX25NEXUS 0
sesbufs SESBUFS 32
sesbytes SESBYTES (8*1024)
mesg MESG 1
msgmap MSGMAP 10
msgmax MSGMAX 8192
msgmnb MSGMNB 8192
msgmni MSGMNI 10
msgssz MSGSSZ 8
msgtql MSGTQL 40
msgseg MSGSEG 1024
sema SEMA 1
semmap SEMMAP 10
semmni SEMMNI 10
semmns SEMMNS 60
semmnu SEMMNU 30
semmsl SEMMSL 25
semopm SEMOPM 10
semume SEMUME 10
semvmx SEMVMX 32767
semaem SEMAEM 16384
shmem SHMEM 1
shmmax SHMMAX 65535
shmmin SHMMIN 1
shmmni SHMMNI 10
shmseg SHMSEG 8
shmbrk SHMBRK 32
shmall SHMALL 1024
stibsz STIBSZ 8192
stobsz STOBSZ 8192
stihbuf STIHBUF (ST_0*4)
stohbuf STOHBUF (ST_0*4)
stnprnt STNPRNT (ST_0>>2)
stnexus STNEXUS 0
emtbsz EMTBSZ 8192
emrbsz EMRBSZ 8192
emrcvsz EMRCVSZ 2048
embhdr EMBHDR (EM_0*6)
emnexus EMNEXUS 0
flckrec FLCKREC 100
flckfil FLCKFIL 25
autoup AUTOUP 20
$ cat /usr/linkkit/cf/dfile.wini
* @(#)dfile.microport 2.3
* Copyright 1986 by Microport. All Rights Reserved
* Default configuration settings for Winchester rooted kernel.
wini 0 2
flop 0 1
rdswap 0 1
root wini 0
pipe wini 0
swap wini 1 20000 6000
dump wini 0
asy 0 4
sxt 0 8
lp 0 3
ev 0 1
kd 0 8
cmos 0 1
emul 0
buffers 0 * 2.3.0
inodes 125 * 2.2
files 120 * 2.3.0
mounts 8
swapmap 75
coremap 150 * 1.3.8
calls 50
procs 75 * 2.2
texts 40
clists 0 * 2.3.0
mesg 1 * 1.3.8
shmem 1 * 1.3.8
sema 1 * 1.3.8
$ cd /usr/linkkit/cf
$ make wini
This makes a relinked kernel called /usr/linkkit/system5.
$ cp /usr/linkkit/system5 /system5
This makes the linked kernel the system default. Before doing
this, you might want to save off /system5 to something like
/OLDsystem5. This comes in handy if the new kernel won't boot.
The $ make wini operation displayed the following tables. These
tables describe the block and character devices that are present
in my system.
Block Devices
major device handler count
0 wini hd 2
1 flop fd 1
2 rdswap rd 1
Character Devices
major device handler count
0 kd kd 8
1 memory mm 1
2 tty sy 1
3 errlog err 1
4 wini hd 2
5 asy asy 4
6 flop fd 1
7 lp lp 3
8 cmos cmos 1
9 ev ev 1
11 rdswap rd 1
12 sxt sxt 8
You may have been wondering, If I'll ever get around to describing
the problem. Well here is:
I get the illusion that I am writing data the tape, but am
unable to read it. Using cpio -ocv, the tape drive sounds
like it should and more importantly the cpio -ocv runs to
completion without hanging or giving any indication of errors.
Reversing the process, gives the "out of phase" message.
2> find z* -print | cpio -ocv >/dev/mt/rmt0
z_news_feed
z_tape
14 blocks
3> cpio -itcv </dev/mt/rmt0
Out of phase--get help
Perhaps the "-c" option should be used
4> l /dev/mt
total 0
brw-r--r-- 5 root sys 1, 70 Dec 29 07:48 0m
crw-rw-rw- 3 root sys 9, 0 Jan 7 13:19 1m
crw-rw-rw- 2 root sys 9, 64 Jan 4 21:57 erase
crw-rw-rw- 2 root sys 9, 4 Apr 21 1988 norewind
crw-rw-rw- 2 root sys 9, 8 Jan 4 21:53 pretension
crw-rw-rw- 2 root sys 9, 16 Jan 4 22:00 reset
crw-rw-rw- 3 root sys 9, 0 Jan 7 13:19 rewind
crw-rw-rw- 3 root sys 9, 0 Jan 7 13:19 rmt0
crw-rw-rw- 2 root sys 9, 16 Jan 4 22:00 rmt16
crw-rw-rw- 2 root sys 9, 4 Apr 21 1988 rmt4
crw-rw-rw- 2 root sys 9, 64 Jan 4 21:57 rmt64
crw-rw-rw- 2 root sys 9, 8 Jan 4 21:53 rmt8
Plea for Help:
Does anybody have any ideas of what I am doing wrong or
suggestions for things to try? I thought this was going to
be simple matter, but has instead turned into a nightmare.
--
diekema@jdbbs.UUCP | Jon Diekema
..garp.MIT.EDU!wybbs!jdbbs!diekema | JD's Connection (616) 669-3792
USMAIL: 7719 Park Lane | Jenison, Michigan 2400
Jenison, MI 49428 |uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/08/89)
Path: tolerant!voder!apple!rutgers!mailrus!ames!amdahl!uunet!van-bc!sl From: sl@van-bc.UUCP (pri=-10 Stuart Lynne) Newsgroups: comp.unix.microport Subject: Re: tape streamers question Message-ID: <2120@van-bc.UUCP> Date: 8 Jan 89 08:56:40 GMT References: <1516@bebux.UUCP> <895@starfish.Convergent.COM> <314@belltec.UUCP> <379@ispi.UUCP> Reply-To: sl@van-bc.UUCP (pri=-10 Stuart Lynne) Organization: Wimsey Associates, Vancouver, BC. Lines: 30 >Not so! the PAL locks no one out ... you can run SCO just fine with our >boards using the built-in SCO drivers. Just make sure to set the interrupts, >etc, correctly. Note that SCO itself quotes Bell Tech boards as supported >streamer tape plug ins in the SCO documentation. > >- dimitri rotow Believe the man. It works fine with SCO built in drivers. I'm using an XTC external with SCO 2.3, using SCO's drivers. You may have to re-address the drive. Takes about 2 minutes. I've also used an Archive 499 type controller with the Bell Tech drive and SCO's drivers. Worked fine. There was no perceptible difference in speed between Bell Tech Controller and driver; Archive Controller and Bell Tech drive; and Archive Controller with Archive drive when all where used with SCO's drivers. They were all *very* fast. (For those who need to know, Bell Techs drive - at least in the box I have - is a Wangtec. Archive's was a Sidewinder I believe.) The only annoyance I have with the Bell Tech card is that it doesn't have an internal cable header, so I can't use it with an internal drive. -- Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/09/89)
Path: tolerant!voder!apple!rutgers!att!ulysses!andante!alice!debra From: debra@alice.UUCP (Paul De Bra) Newsgroups: comp.unix.microport,comp.unix.xenix Subject: Re: differences in Xenix and the rest Message-ID: <8705@alice.UUCP> Date: 8 Jan 89 18:21:57 GMT References: <9049@cit-vax.Caltech.Edu> Reply-To: debra@alice.UUCP () Distribution: usa Organization: AT&T, Bell Labs Lines: 27 In article <9049@cit-vax.Caltech.Edu> tim@cit-vax.UUCP (Timothy L. Kay) writes: >I am in the market for a Unix for a 386. I was considering Microport, >but I have heard many bad things, and now they have raised their >prices.... > >1. Now that SVR3.2 is out (with the Xenix merged stuff), is SCO Xenix >just another derivation from the same sources? Thank God no! It is still SCO Xenix, but it has been somewhat extended to be able to run 386-Unix binaries. It is supposed to become more SVID compliant too I believe. >2. Is the Xenix that Microsoft is selling just a repackaging of SCO >Xenix? Are they up to date? I don't know exactly what Microsoft is selling nowadays. They did the initial port to the Intel architecture, and many companies have bought that version and added machine-specific things. (Altos-Xenix, IBM-PC Xenix...) SCO does all the XT, AT and 386-AT stuff, added virtual consoles, and more stuff. They have the most up to date version for AT's, PS/2's and 386-AT's at all times. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
john@john.UUCP (John Conover) (01/09/89)
We have evaluated most of the available UNIX's for the 386 and have settled on Bell Technologies. We found that only Xenix (from SCO) and Bell's were stable. The support from SCO is superior, but Bell's is cheaper John
news@tolerant.UUCP (The Daily Fishwrap) (01/09/89)
Path: tolerant!voder!apple!bloom-beacon!gatech!ken From: ken@gatech.edu (Ken Seefried III) Newsgroups: comp.unix.microport Subject: SVID (was: Submission for comp-unix-microport) Message-ID: <17801@gatech.edu> Date: 9 Jan 89 04:31:46 GMT References: <8901082322.AA19653@handel.TOLERANT> Reply-To: ken@gatech.UUCP (Ken Seefried iii) Organization: School of Information and Computer Science, Georgia Tech, Atlanta Lines: 15 >Reply-To: debra@alice.UUCP () >Organization: AT&T, Bell Labs > >Thank God no! It is still SCO Xenix, but it has been somewhat extended >to be able to run 386-Unix binaries. It is supposed to become more SVID >compliant too I believe. > Point of clarification: please correct me if I am wrong, but my understanding of SVID is that you are either SVID compliant or you are not. Being 'more compliant' is like being 'more pregnant'. Is this not correct? ...ken
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/09/89)
Path: tolerant!voder!apple!rutgers!mailrus!bbn!gatech!mcdchg!ddsw1!karl From: karl@ddsw1.MCS.COM (Karl Denninger) Newsgroups: comp.unix.microport,comp.unix.xenix Subject: Re: differences in Xenix and the rest Summary: SCO is now advertising SVVS complience.... Message-ID: <2660@ddsw1.MCS.COM> Date: 9 Jan 89 02:40:11 GMT References: <9049@cit-vax.Caltech.Edu> <8705@alice.UUCP> Reply-To: karl@ddsw1.UUCP (Karl Denninger) Distribution: usa Organization: Macro Computer Solutions, Inc., Mundelein, IL Lines: 21 In article <8705@alice.UUCP> debra@alice.UUCP () writes: >In article <9049@cit-vax.Caltech.Edu> tim@cit-vax.UUCP (Timothy L. Kay) writes: >>I am in the market for a Unix for a 386. ... microport .... xenix .... >>1. Now that SVR3.2 is out (with the Xenix merged stuff), is SCO Xenix >>just another derivation from the same sources? >Thank God no! It is still SCO Xenix, but it has been somewhat extended >to be able to run 386-Unix binaries. I understand, from the brochure we have here, that SCO Xenix V/386 V2.3.1 has passed the SVVS..... the older versions (2.2.x) were "almost" there -- I believe there were two exceptions (one having to do with file locking). I've got the update on order... should be here in a few days. It will be interesting to see if it indeed is fully complient. --- Karl Denninger (karl@ddsw1.MCS.COM, ddsw1!karl) Data: [+1 312 566-8912], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality solutions at a fair price"
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/09/89)
Path: tolerant!voder!apple!rutgers!rochester!uhura.cc.rochester.edu!sunybcs!bingvaxu!leah!itsgw!steinmetz!uunet!smosjc!john! From: john@john.UUCP (John Conover) Newsgroups: comp.unix.microport Subject: Re: Submission for comp-unix-microport Summary: Might try Bell Technologies ... it's cheaper. Message-ID: <104@john.UUCP> Date: 9 Jan 89 06:16:20 GMT References: <8901081128.AA17414@handel.TOLERANT> Organization: Campbell, Ca. Lines: 6 We have evaluated most of the available UNIX's for the 386 and have settled on Bell Technologies. We found that only Xenix (from SCO) and Bell's were stable. The support from SCO is superior, but Bell's is cheaper John
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/09/89)
Path: tolerant!voder!apple!rutgers!rochester!uhura.cc.rochester.edu!sunybcs!bingvaxu!leah!itsgw!steinmetz!uunet!smosjc!john! From: john@john.UUCP (John Conover) Newsgroups: comp.unix.microport Subject: Hung comm line Keywords: Hung Communications line Message-ID: <105@john.UUCP> Date: 9 Jan 89 06:27:10 GMT Distribution: usa Organization: Campbell, Ca. Lines: 8 I am running HDB on Bell Technologies version 3.1 Unix. I am respawning uugetty in inittabs. Unfortunately, the line will hang and refuse logins for hours on end. Trying to cu the line from an external terminal fails because no Login: prompt is issued (ie, a \r can not get a login prompt.) Anybody have any ideas? Thanks in advance ... John
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/10/89)
Path: tolerant!voder!pyramid!oliveb!ames!xanth!nic.MR.NET!csd4.milw.wisc.edu!leah!itsgw!steinmetz!uunet!ispi!jbayer From: jbayer@ispi.UUCP (Jonathan Bayer) Newsgroups: comp.unix.microport,comp.unix.xenix,comp.sys.ibm.pc,comp.sys.intel Subject: Re: 386 Motherboards vs. Acceleratr Boards Keywords: From 286 to 386 Message-ID: <400@ispi.UUCP> Date: 7 Jan 89 14:46:29 GMT References: <3106@ihuxv.ATT.COM> Reply-To: jbayer@ispi.UUCP (Jonathan Bayer) Organization: Intelligent Software Products, Inc. Lines: 24 In article <3106@ihuxv.ATT.COM> bareta@ihuxv.ATT.COM (Benyukhis) writes: >Need a lot of advice on upgrading 286 to 386 (ideally one would sell one >and buy the other... but it is impossible to sell the used machine >for as much as you have already invested so ....) I am looking >for an information on how to upgrade an AT type machine to a 386 i.e >what are the available products, known limitations, etc. >For information: I have a PC's Limited 286 AT 6/8Mhz switchable with >Phoenix BIOS, 40Mb ST-251, EGA, and 3MB (120 or 100 ns RAM) >1024 on the mother board and 2Mb on the Everex Ram board (3000 I beleive) > A major possibility is to junk the 286 motherboard and get a replacement 386 board. There are many of them out on the market for prices starting at $1000 (rare), moving up to $1500 (happauge 386) or higher. JB -- Jonathan Bayer "The time has come," the Walrus said... Intelligent Software Products, Inc. 19 Virginia Ave. ...uunet!ispi!jbayer Rockville Centre, NY 11570 (516) 766-2867 jbayer@ispi
uucp@tolerant.UUCP (UNIX-UNIX Cp) (01/10/89)
Path: tolerant!voder!pyramid!decwrl!ucbvax!pasteur!ames!killer!dcs!wnp From: wnp@dcs.UUCP (Wolf N. Paul) Newsgroups: comp.unix.microport Subject: Re: SVID (was: Submission for comp-unix-microport) Message-ID: <294@dcs.UUCP> Date: 9 Jan 89 13:50:46 GMT References: <8901082322.AA19653@handel.TOLERANT> <17801@gatech.edu> Reply-To: wnp@dcs.UUCP (Wolf N. Paul) Organization: DCS, Dallas, Texas Lines: 30 In article <17801@gatech.edu> ken@gatech.UUCP (Ken Seefried iii) writes: >>Reply-To: debra@alice.UUCP () >>Organization: AT&T, Bell Labs >> >>Thank God no! It is still SCO Xenix, but it has been somewhat extended >>to be able to run 386-Unix binaries. It is supposed to become more SVID >>compliant too I believe. >> > >Point of clarification: please correct me if I am wrong, but my >understanding of SVID is that you are either SVID compliant or you are >not. Being 'more compliant' is like being 'more pregnant'. > >Is this not correct? Well, complying with a standard is really not quite the same as being pregnant. Apart from AT&T's contractual language and interpretation, it is well possible to call something "more" or "less" compliant, or maybe a better terminology would be "closer to" the standard. So, for example, System V is closer to POSIX than Version 7; the merged UNIX/XENIX release is closer to SVID than previous XENIX releases. If you do wish to use pregnancy as an example, a woman in her eighth month is closer to giving birth than a woman in her second week, even though they are both equally pregnant. -- Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101 UUCP: killer!dcs!wnp ESL: 62832882 DOMAIN: dcs!wnp@killer.dallas.tx.us TLX: 910-380-0585 EES PLANO UD
debra@alice.UUCP (Paul De Bra) (01/10/89)
In article <104@john.UUCP> john@john.UUCP (John Conover) writes: > >We have evaluated most of the available UNIX's for the 386 and >have settled on Bell Technologies. We found that only Xenix >(from SCO) and Bell's were stable. The support from SCO is >superior, but Bell's is cheaper > John You mean that Bell Tech is now offering support? They didn't used to but kept promising they would start doing that soon. Until recently Bell Tech did offer NO support at all, just a (30 day?) money-back guarantee. So "superior" seems like an understatement when you compare having support to not having support. From following discussions on the net my conclusion is that Bell Tech is indeed the most stable Unix. This is achieved by not fixing known problems by not providing a means to know the problems (sometimes they read this group though). People for whom Bell Tech's Unix doesn't work (incompatible hardware or wanting to use some broken software) just return the product and buy another Unix. There is an argument in favor of that. If someone buys a Bell-Tech PC with Bell-Tech Unix, why should they try to fix a problem, known to exist with say a Compac and risk breaking something that used to work on the Bell-Tech PC? Most companies try to offer a Unix that works on ALL AT-compatibles (with or without 386), and that is bound to fail. Bell-Tech does not try to do that. Right? Personally I wouldn't go for Bell Tech, because I don't want to keep looking for a Unix that will work with whatever I buy. I'd rather buy something that probably works and for which there is support so I can report a problem and get a fix. Well, you know what's second on your list... Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
john@smosjc.UUCP (John Conover) (01/10/89)
In article <8901052114.AA14652@handel.TOLERANT>, uucp@tolerant.UUCP (UNIX-UNIX Cp) writes: > > It's a moot point. All the 386 system V ports are essentially the > same one done by Interactive Systems. They are fairly decent > Sys 5 R 3 ports and you can even get TCP for them. > I would like to know availability of any TCP/IP software/drivers/hardware for the Microport 386 Unix John Conover { ... uunet!smosjc!john} (408) 922-0200 (voice) Thanks, John
ken@uport.UUCP (Ken Chapin) (01/10/89)
In article <1@smosjc.UUCP> john@smosjc.UUCP (John Conover) writes: >I would like to know availability of any TCP/IP software/drivers/hardware >for the Microport 386 Unix > >John Conover We have here both Excelan and Micom/Interlan hardware-software combos. Also available from third parties is a Wollengong-3Com package that supports NFS and something from CMC Corp. Ken Chapin UUCP: ...!{sun | ucbvax | ihnp4}!amdcad!uport!ken Microport Systems Technical Support
dar@belltec.UUCP (Dimitri Rotow) (01/11/89)
[ Edits ... John sez our UNIX and SCO are stable, Paul sez we're stable only 'cause we ignore problems and don't offer support] > > You mean that Bell Tech is now offering support? They didn't used to but > kept promising they would start doing that soon. Until recently Bell Tech > did offer NO support at all, just a (30 day?) money-back guarantee. An old argument. You'd rather we rip you off like some people do and *not* provide a money back guarantee? Paul, could you please explain to me and the other people reading this group why an absolute "customer must be satisfied" money back guarantee is an evil thing? I always thought it was a sign of one's confidence in one's products coupled with a respect for one's customers. If you convince me that a money back guarantee is an evil thing and bad for customers, we'll change the policy. This is not sarcasm, I am sincerely baffled why every so often someone gets on USENET and flames away at a money-back guarantee. > > There is an argument in favor of that. If someone buys a Bell-Tech PC with > Bell-Tech Unix, why should they try to fix a problem, known to exist with > say a Compac and risk breaking something that used to work on the Bell-Tech > PC? Most companies try to offer a Unix that works on ALL AT-compatibles > (with or without 386), and that is bound to fail. Bell-Tech does not try > to do that. Right? > Au contraire, we *do* provide installation level support and have a roster of support programs (pay for play) beyond that. Better still, we fold support for bugs into new releases, just like AT&T does. Instead of revving the product every week, we align with major release cycles about every six to nine months. That we can do so is testimony to the intrinsic stability of the Intel/AT&T product. While we *do* use our own PC's in house, the majority of development work on UNIX System V/386 is being done on Intel and AT&T boxes. The principle targets, of course, are Compaq and the other name brand clones. After all, they outsell all others by substantial margins. I believe it is foolish, by the way, to fixate on supporting eight hundred different systems and peripherals within one release. After all, we all only use one system at a time. For the guy running a Compaq, all he cares about is that the system supports *his* machine. He doesn't care about 300 different varieties of X, Y, and Z clones. That's why he bought a Compaq, probably, so he could get some assurance of quality and compliance with standards. If your O/S vendor is chasing ten thousand incompatible, poorly implemented clones then he only has less time to do quality work on mainstream UNIX for mainstream clones. What would you rather have: STREAMS, RFS, NFS, X and the full panopy of Release 3.2 delivered today in a thoroughly debugged release for mainstream clones, or an O/S that's a year behind the times which supports a zillion devices you never will use and don't care about? Isn't it the job of the clone vendors to make their clones compatible with industry standards? Another example is ports cards. Our release ships without linked in drivers for our own line of ports cards. Why? Because we don't think it appropriate to clutter the kernel with lots of varient code that people might not want. We ship our card drivers as an "installpkg" shrink wrap end user diskette bundled with the card. I think that's where they belong. When you clutter the kernel with device drivers for 80 different devices, you simply increase the risk of problems and make life different for users. After all, people are probably going to buy only one type of ports card for any given computer. Why should they pay (and you *do* pay, you know) for the support of 30 other cards in the kernel? I know that if you don't know what you want, it's nice to know you have a roster of cards to pick from, but do you really want to tie your life to a ports card vendor that can't deliver elementary software support for their own card? All the leading ports cards vendors can now do so. I don't mean to minimize the benefit of multiple card support: if you want that built into your O/S you are lucky to have a first rate vendor in the form of SCO to buy from. In addition to supporting SCO, we also ship an option for those people who have alternate needs. For the record, our distribution supports all of the big name clones. Some need to be configured (on board SIO's jumpered correctly, etc) for correct use just as they would for Microport, ISC, or any of the other releases. If you want a different sort of system, you are lucky to be in the Intel processor world where you have lots of choices for operating systems vendors. That's why we are so emphatic in our support of SCO in our peripheral line: we think SCO provides terrific solutions in areas where other releases do less well and vice versa. Release 3.2 closes the deltas, but there are still major differences between product and company offerings which customers can use to their advantage. - Dimitri Rotow
john@smosjc.UUCP (John Conover) (01/11/89)
In article <292@uport.UUCP>, ken@uport.UUCP (Ken Chapin) writes: > In article <1@smosjc.UUCP> john@smosjc.UUCP (John Conover) writes: > >I would like to know availability of any TCP/IP software/drivers/hardware . . . Thanks ken, great help John
ruiu@dragos.UUCP (dragos) (01/13/89)
In article <8901091903.AA24711@handel.TOLERANT>, uucp@tolerant.UUCP (UNIX-UNIX Cp) writes:
We have been getting billions of repeats of comp.unix.microport.
The net-vortex seems to be at tolerant. Could someone please let them
know...
--
Dragos Ruiu ruiu@dragos.UUCP "Yes, Dragos is my first name."
...alberta!edm!dragos!ruiu "Why? Someone said it sounded like a nodename!"