HDTenEightyP/NetNews huggingface dataset:
From: nigel@isgtec.com (Nigel Burnett)
Newsgroups: comp.sys.unisys
Subject: Disks on SCSI/combo on S/320 - HELP!
Date: 10 Apr 92 01:54:12 GMT
Distribution: world
Organization: ISG Technologies Inc., Mississauga Ontario

Thanks to Clarence Dold in San Jose and a desperate starving sales person
in Toronto, we now have the SCSI/Combo card for the S/120/22x/320/640
series.

After meticulously following the instructions in the Admin manuals re: the
addition of SCSI disks to a MightyFrame, the system finds the SCSI card
fine but nary a disk drive in sight.

This is pretty important to us so we can upgrade many of our customer sites
that are suffering disk i/o bottlenecks.

Any help (especially from someone who has actually done this) would be
very much appreciated.  Thanks in advance for all replies.  We offer a
free 3D reconstruction of your favourite CAT or MRI scan (worth over
$300 to your insurance company (sorry - citizens of socialist countries
like Canada not eligble)) printed on a colourful 8x10 glossy print.
Seriously, I really do need some help here.

Nigel

--
"It is an infantile superstition of the human spirit that virginity would be
thought a virtue and not the barrier that separates ignorance from knowledge"                                                                       Voltaire
Nigel Burnett:  business: 3030 Orlando Dr., Mississauga, Ont.,  416-672-2100
Send e-mail to nigel@isgtec.com, uunet.ca!isgtec!nigel, or nigel@isgtec.UUCP
Newsgroups: comp.sys.unisys,comp.sys.sequent
From: pete@wvus.org (Pete Gregory - UNIX SA)
Subject: SCED FCN (dropping packets)
Organization: World Vision U.S.
Date: Fri, 10 Apr 92 20:30:13 GMT

Hi - 3 x 6000/70, 1 x 6000/80 (Sequent S27,S81 respectively) + 
        PTX 1.1.1 here...

We, along with some of you out there in netland, have experienced problems
with the SCED card dropping packets.  Reprinted (without permission) in 
near entirety is Unisys' FCN for determining whether the SCED card should
be upgraded to rev 47:

------------------------------------------------------------------------
PROBLEM VERIFICATION

This test MUST be run on the U6000/70 or /80 system that is suspected
of having a data of traffic handling problem.  If this test indicates
that this FCN will solve this problem then the customer engineer must
call the Customer Service Support Center to get approval to order this
FCN.

1. This FCN has been generated to provide a solution to a specific high
density traffic handling problem on the 6000/70's and 6000/80's.  This
FCN is ONLY required if other systems on the Ethernet are transmitting
at or near the limits of the 10 megabit Ethernet standard (ie.
interframe spacing is at or near 9.6 microseconds).  THIS IS NOT AN
UPGRADE FOR PERFORMANCE ENHANCEMENT.  It will only help when Ethernet
packets are having to be retransmitted due to a source system
transmitting at or near the limits of the 10 megabit Ethernet standard.

2. The FCN is ONLY required if the SCED Ethernet is experiencing 1 or
more receiver overflows per 1000 good packets received.  This is
easily determined.

3. To determine if this problem exists on a customer's system, use the
following procedure.

Note: each SCED should be evaluated individually.

PTX 1.1.1 or 1.2 Operating Systems

[procedure for running ethstat -z to reset statistics, then ethstat to
to look at the statistics.  ratio calculated is "receiver overflows"
as a percentage of "good packets received".  if "receiver overflows" x 1000
is greater than "good packets received", Unisys recommends the rev 47
SCED card be installed.]
------------------------------------------------------------------------
of our four machines, three are on the local Ethernet LAN.  of these three,
one has had its SCED card replaced with a rev 47 SCED card (all cards
were rev 44 beforehand).  the percentage of receiver overflows to good
packets received for our SCED v44 systems is 0.0119% and 0.00882%, and
the percentage on our SCED v47 system is 0.002%, or a 90% reduction in the
rate of receiver overflows.  Hence, the v47 SCED significantly improves
the situation (for our site, anyway) but does not solve it altogether.
-- 

Pete Gregory       |  Internet: pete@wvus.org
UNIX SA            |  Bangpath: ames!elroy!wvus!pete
World Vision U.S.  |  Slowpath: 919 W. Huntington Dr., Monrovia, CA 91016
From: toad@cellar.org (Tony Shepps)
Newsgroups: comp.sys.unisys
Subject: Re: Unisys 6000/65 + SVR4
Date: 16 Apr 92 15:08:25 GMT
Organization: The Cellar BBS and public access system

scannon@bluemoon.rn.com (Sam Cannon) writes:

> Where did you come in contact with the [U6000/65] machines?

Until Mid-February, I worked at the Unisys Support Center in Blue Bell,
manning the support line for Unix system software.

----------------------------------------------------------------------------
- Tony Shepps      toad@cellar.org      (...{tredysvr|uunet}!cellar!toad)  -
- The Cellar BBS  +1 215 654 9184   Reliable hardware, responsible sysops, -
- and line no^se is nev^r a pr\377bl~{{{7z@#zz{K~o8f#         NO CARRIER
Newsgroups: comp.sys.unisys
From: scannon@bluemoon.rn.com (Sam Cannon)
Subject: Unisys 6000/65 + SVR4
Organization: Blue Moon BBS ((614) 868-998[024])
Date: Sun, 12 Apr 92 13:06:36 EDT

Looking for someone who is diddling with the new 65 boxes.  I've
heard that there aren't many outside K-Mart.  Anyone familiar
with these interesting machines?

 This is from
     scannon@bluemoon.rn.com
who doesn't have their own obnoxious signature yet
From: laborell@mimosa.unice.fr (Louis Laborelli)
Newsgroups: comp.sys.unisys
Subject: Speed of 2200 Mainframes range
Keywords: 2200,1100
Date: 7 Apr 92 18:12:27 GMT
Organization: University of Nice-Sophia Antipolis

I would like to have an idea of the speed of a 2200/1100 mainframe, 
for OLTP  (TPC...) 
 Since I have heard that Unix can be used on this big iron, 
have somebody tried the Specmarck suite ? 
What are the main differences between 1100 architecture and 2200s ? 
Is there a third party market for peripherals (Disks...) 
I would appreciate email, since I seldom read this group 

-- 
 Louis Laborelli
 Universite de Nice Sophia Antipolis  / phone: (33) 92 94 26 89	       
 I3S LISAN - CNRS Batiment 4          \	telex: GRP 970006F
 250 rue Albert Einstein	      / fax: (33) 92 94 28 98
 Sophia Antipolis	              \ e-mail:laborell@zig.inria.fr
 06560 Valbonne FRANCE                / or laborell@mimosa.unice.fr
Newsgroups: comp.sys.unisys,comp.sys.3b1
From: merce@iguana.uucp (Jim Mercer)
Subject: Re: SLIP on the Miniframe
Organization: Ed (the iguana) Memorial Society
Date: Sat, 11 Apr 92 03:54:18 GMT

In article <1992Apr9.233746.17495@wpi.WPI.EDU> mute@wpi.WPI.EDU (Madman Omar) writes:
>Has anyone implemented SLIP (Serial Line Internet Protocol) on the
>Convergent MiniFrame? I would be interested in getting my hands on 
>a copy of the sources, if you have, and would be generous enough
>to allow me to have them.

i have the 3b1 version of KA9q running on my miniframe.

i used some binary gcc stuff i found somewhere via ftp, and compiled it up.

seems to work ok.

problem is that anything else i compile with the gcc don't seem to work to
good.

less and elm dump core, and other things are pretty broken.

i think this is a result of broken libraries for the gcc.

has anyone got a decent gcc suite for the miniframe?

-- 
[ Jim Mercer   work: jim@lsuc.on.ca  home: merce@iguana.uucp  +1 519 893-6085 ]
[            "We are doing everything we can. which means nothing"            ]
[    Paul Vixie, with regards to the NIC munging DNS for gatekeeper.dec.com   ]
Organization: Masters student, Information Networking Institute, Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.sys.unisys
Date: Tue,  7 Apr 1992 11:17:56 -0400 
From: Luis J Mendez <lm2k+@andrew.cmu.edu>
Subject: Survey

	Sorry for the waste of bandwidth...
	My name is Luis Mendez, student at the Information Networking Institute
at Carnegie Mellon and I am working on a survey for an Industrial
Administration course.  The purpose of the survey is to collect
information regarding the characteristics that industrial customers look
for in a firm from which they plan to buy a product or service and how
those characteristics affect the selection process.  As area of study, I
have chosen computer hardware firms.  It is of my interest to learn what
characteristics are considered by corporations when deciding from which
firm it is desirable to buy computer hardware.  If any of this netnews'
readers is related to hardware purchasing at a company and would like to
participate on this survey, please send me an email and a fax number
where I can reach you, and I will fax you back the questions and all the
information concerning the survey.  Any help you can bring me will be
really appreciated.  Copies of the team's final report will be available
upon request.  Thanks for your help.

	Luis Mendez
	lm2k@andrew.cmu.edu  
Newsgroups: comp.sys.unisys
From: scannon@bluemoon.rn.com (Sam Cannon)
Subject: Re: Unisys 6000/65 + SVR4
Organization: Blue Moon BBS ((614) 868-998[024])
Date: Wed, 15 Apr 92 21:59:50 EDT

> 
> The SVR4 OS seems pretty reliable -- not many problems reported with it.
> Most support issues were more or less related to everyone getting used to
> release 4 -- so much has changed!  Basically, you have to re-learn Unix.
> 


I don't find the UNIX re-learning terrible, but better docs would
help.  Also the hardware seems 'just OK'.  I had some pretty severe
SCP I/O problems with the serial ports.  Next week, I'm working
with an Ethernet solution.  That'll probably be better, but I don't
know!  Where did you come in contact with the machines?

 This is from
     scannon@bluemoon.rn.com
who doesn't have their own obnoxious signature yet
Newsgroups: comp.sys.intel
From: cfj@SSD.intel.com (Charlie Johnson)
Subject: Re: LetsGetHelp on i860
Reply-To: cfj@SSD.intel.com (Charlie Johnson)
Organization: Intel Corporation
Date: Fri, 10 Apr 1992 14:49:33 GMT

N10 was to project name for the i860.

-- 
Charles Johnson
Intel Corporation
Supercomputer Systems Division
MS CO1-01
15201 NW Greenbrier Pkwy
Beaverton, OR  97006           phone: (503)629-7605  email: cfj@ssd.intel.com
From: qlown@qlunix.abg.sub.org (Albert Schwark)
Newsgroups: comp.sys.intel
Subject: 386SX as embedded controller
Date: 11 Apr 92 00:17:24 GMT
Organization: Albert Schwark, D-8900 Augsburg, Germany
Reply-To: qlown@qlunix.abg.sub.org

Hi!

I'm looking for application notes about experiences with the
386SX as an embedded Controller.

Could you please answer per e-mail, because I do not receive 
this group.

Thanks very much.....



So long

       Albert alias QLown
       ^^^^^^^^^^^^^^^^^^
--
  _____
 /  |O \  Direkt: Music-Box Augsburg: 0821/528406, 526088, UName QLown    |
|   | W | Domain: qlown@qlunix.abg.sub.org                                |
|   |  N| Voice:  0821 / 437 559 - Albert Schwark                         |
|   |___|_________________________________________________________________|
 \_____/  Beam me up, Scotty, there's no intelligent life on THIS planet  |
Organization: Masters student, Information Networking Institute, Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.sys.intel
Date: Wed,  8 Apr 1992 00:03:14 -0400 
From: Luis J Mendez <lm2k+@andrew.cmu.edu>
Subject: Survey

	Sorry for the waste of bandwidth...
	My name is Luis Mendez, student  at the Information Networking
Institute at Carnegie Mellon and I am working on a survey for an
Industrial Administration course.  The purpose of the survey is to
collect information regarding the characteristics that industrial
customers look for in a firm from which they plan to buy a product or
service and how those characteristics affect the selection process.  As
area of study, I have chosen computer hardware firms.  It is of my
interest to learn what characteristics are considered by corporations
when deciding from which firm it is desirable to buy computer hardware. 
If any of this netnews' readers is related to hardware purchasing at any
company and would like to participate on this survey, please send me an
email with a fax number where I can reach you, and I will fax you back
the questions and all the information concerning the survey.  Any help
you can bring me  will be really appreciated.  Copies of the team's
final report will be available upon request.  Thanks for your help.

	Luis Mendez
	lm2k@andrew.cmu.edu
From: haibo@bones.caedm.byu.edu (haibo yu)
Newsgroups: comp.sys.intel
Subject: Kingston SX/Now or Intel's SnapIn?
Date: 15 Apr 92 08:42:59 GMT
Organization: Brigham Young University, Provo UT USA

I want to upgrade a PS/2 60 to 386SX.  Which one is better? Intel's
SnapIn or Kingston's SX/Now?  I saw the benchmark for Kingston's
SX/Now, anyone know Intel's?  Thank you

haibo
Organization: The American University - University Computing Center
Date: Tuesday, 7 Apr 1992 13:10:46 EDT
From: Guy Hadsall <GHADSAL@auvm.american.edu>
Newsgroups: comp.sys.intel
Subject: Re: HELP-Intel 386/PC board installation
 <92096.141115GHADSAL@auvm.american.edu>


Got it.   Thanks for the assistance to all that mailed.
From: bergstro@src.honeywell.com (Pete Bergstrom)
Newsgroups: comp.sys.intel
Subject: RapidCAD CoProcessor
Date: 16 Apr 92 15:29:38 GMT
Article-I.D.: data.9204161529.AA17540
Organization: Honeywell Systems & Research Center
To: comp.sys.intel
Posted-Date: Thu, 16 Apr 92 10: 29:38 CDT
Received-Date: Thu, 16 Apr 92 10: 26:19 CDT


The May issue of Byte has an ad for intel's RapidCAD Engineering
CoProcessor.  It is a drop in replacement for the 386/387 duo that
supposedly gives up to 70% speedup on certain CAD functions.


So what's the story here?  What does this look like, how much of my 3d
graphics stuff has to be specialliy coded to take advantage of it,
etc?

Pete
Newsgroups: comp.sys.intel
From: adingus@magnus.acs.ohio-state.edu (Aaron T Dingus)
Subject: P5
Organization: The Ohio State University
Date: Fri, 17 Apr 1992 00:36:46 GMT

I have heard that the P5 is capable of exceeding 100 MIPS.
That is quite a jump from a 486/50's 20 or so.  I have also
heard that it uses a special set of registers, and other
interesting new stuff.

If someone in the know about the capabilites/release date of this
new processor would like to drop me a line, it would be greatly
appreciated.

Thanks.

-ATD
-- 
Aaron T. Dingus
Professional Athelete
The Ohio State Univeristy
adingus@magnus.acs.ohio-state.edu
Newsgroups: comp.sys.intel
From: mccreary@sword.eng.hou.compaq.com (Ed McCreary)
Subject: Re: DX vs DX2
Organization: Compaq Computer Corp.
Date: Wed, 15 Apr 1992 19:59:20 GMT

In article <1992Apr15.170929.5484@unixg.ubc.ca> twong@civil.ubc.ca (Thomas Wong) writes:
>Hello all. I have a thing I wanted to verify with the Intel gurus on the
>net since someone is asking me this very question and I wanted to double
>check before I put my foot in my mouth...
>
>Is it true that a 50 Mhz 486 DX is a true 50 mhz chip all in one.
>Whereas DX2 is just 2 25mhz 486s, one sitting in the CPU socket, the
>second sitting in the Weitek math coprocesser socket?
>Thank you.
>


Well, I'm not an intel guru, but no, that's not true.  The 50 MHz 486DX
is a true blue 50 MHz processor inside and out.  The DX2 on the other
hand operates internally at 50MHz but at 25MHz externally.  A 25MHz clock
is fed to the chip which contains special clock doubling circuitry.  The
DX2 is not as fast as a 50MHz but is much faster than a 25MHz DX.


--
McCreary@sword.eng.hou.compaq.com     Computers are like Old Testament gods;
Me? Speak for Compaq?  Yeah, right.   lots of rules and no mercy.
                                                             Joseph Campbell
From: dpeterso@mipos2.intel.com (David Peterson)
Newsgroups: comp.sys.intel
Subject: Re: AMD - Intel lawsuit, the winner? AMD!
Summary: Not - the lawyers won.
Date: 1 Apr 92 21:22:11 GMT
Reply-To: dpeterso@mipos2.UUCP (David Peterson)
Organization: Intel Corporation, Santa Clara, CA

In article <1992Apr1.022155.1074@adobe.com> pngai@adobe.com (Phil Ngai) writes:
>In article <2303@accucx.cc.ruu.nl> nevries@accucx.cc.ruu.nl (Nico de Vries.) writes:
>>Judge Phelps ruled that Intel has to pay AMD $15.256.472. Also he granted
>>AMD the permanent, royalty free right to produce and sell the Am386. Intel
>>is warned not to hinder AMD anymore in doing this.
>>
>>Seems pretty tough for Intel. Wonder what the future will bring.
>
>What amuses me is that Intel claims they won the arbitration and then
>in the next breath say they will appeal. Why would you want to appeal
>if you won?

	Please remember, much of this banter is PR. The general
opinion around here seems to be that the agreement between Intel
and AMD was violated by both parties to some extent. Most people
are ignorant of many of the facts, including myself, so I do not
wish to get into a discussion about who was right and who was 
wrong. The reason Intel claims victory in this case is that the 
monitary penalty was paltry compaired to quarterly revenues. 
Compairable to an award of a dollar to the plantif in the People's 
Court. ;-)
	By the way, AMD was seeking unconditional rights to the
386 design. They did not recieve this. They are not allowed to
use the design in any future products. Ho hum, I smell another 
court battle. Enough bandwidth on this subject. Take it to
lawyer.money.money.money .

-------------------------------------------------------------------------
David Peterson 
Intel Corp., M/S SC4-69, 2625 Walsh Ave.
Santa Clara, Ca. 95052-9940
dpeterso@mipos3.intel.com
Dave Peterson
SC4-69
765-5109
dpeterso@mipos3
From: crichmon@sedona.intel.com (Chris Richmond)
Newsgroups: comp.sys.intel
Subject: Re: IC number
Date: 1 Apr 92 16:09:22 GMT
Reply-To: crichmon@sedona.intel.com
Distribution: comp.sys.intel
Organization: Intel Corporation, Embedded Microcomputer Division


In article <1992Mar31.150134.14255@bilver.uucp>, wbeebe@bilver.uucp (Bill Beebe) writes:
> In article <hoole.701640529@apricot8> hoole@rtsg.mot.com (Elliott D. Hoole) writes:
> >	#1)  40 pin	D5C090-50
> >	#2)  40 pin	D5C121-65
> >	#3)  20 pin	D5C032-35
> >
> >Any info on these chips would be very much appreciated.
> 
> These chips are Intel's EPLD (Erasable Programmable Logic Device) family.
> The 032 is a 300 gate, the 090 is a 900 gate, and I can't recall anymore
> what the 121 is. The dash numbers at the end are the prop delays in ns,
> i.e. -50 is 50 ns.

I used to be the product engineer on these products and have a data
book with me now.  The 5C121 is a 1200 gate device that is out of
production.  The others are still being made.  If anyone needs help 
with these, let me know... 
--
 Chris Richmond         |     Internet: crichmon@sedona.intel.com
 Intel, Corp. C3-21     |     Phone: (602)-554-8827
 5000 W. Chandler Blvd. |     This crazy is a world place. 
 Chandler, AZ  85226    |     My think losing I'm mind.
From: mvs7812@tamuts.tamu.edu (Michael Vaclav Stembera)
Newsgroups: comp.sys.intel
Subject: 486 MOTHERBOARDS
Date: 6 Apr 92 22:19:15 GMT
Organization: ~/lib/organization

I got a few questions going through my head regarding
motherboards and so I decided to post them.  My main interest
is in 486DX or DX2 motherboards.

1) What are the basic motherboard differences besides ISA,
   EISA, different cash sizes, and Mhz?

2) Is the speed of the SIMMS a motherboard uses an indicator
   of how fast the board is?
   If I have a 486 motherboard with 60ns SIMMS and another
   with 80ns SIMMS is the earlier faster? (Provided all else
   is the same.)
   Can I speed up a board by switching to faster SIMMS?

2) Are identical motherboards made by different manufacturers
   identically fast?  If not who makes the best or fastest
   motherboards?

3) What other indicators should one consider when looking for
   a fast motherboard?

4) What is a good source for getting one?


Thanks in advance

Mike
 
Xref: sparky comp.sys.intel:828 comp.lang.c:7303
From: kjb@ (Kendall Bennett)
Newsgroups: comp.sys.intel,comp.lang.c,comp.sys.ibm-pc.programmer
Subject: Detecting the 80x87
Date: 7 Apr 92 10:31:21 GMT
Organization: RMIT Computer Centre, Melbourne Australia.

How do I go about detecting the presence of the 8087 thru to the i487
Numeric co-processor chips? I already have written a routine to detect
all processor types, but I have got no idea about the NDP and I would
like to be able to autodetect this also...

Thanks,

+------------------------------------------+----------------------------------+
| Kendall Bennett,                         | Internet:                        |
| Advanced Computer Graphics Centre,       | s892992@minyos.xx.rmit.oz.au     |
| Royal Melbourne Institute of Technology, | s892992@yallara.cs.rmit.oz.au    |
| Victoria, AUSTRALIA.                     | kjb@godzilla.cgl.citri.edu.au    |
+------------------------------------------+----------------------------------+
| CoSysop (Bossman), PC Connection Australia:                  +61 3 688 0909 |
+-----------------------------------------------------------------------------+
From: guille@goofi.greco-prog.fr (GUILLE Patrick)
Newsgroups: comp.sys.intel
Subject: MIPS/FLOPS ratings
Date: 13 Apr 92 03:59:46 GMT
Organization: ENSERB (Electronic & Computer Science School) Bordeaux FRA
Originator: guille@goofi

Hello,

Could anybody give me the average MIPS/FLOPS ratings of the i80x86
range, with/without copro? Especially interested in 80386 and 80486.

Thanks,

Guille Patrick
guille@goofi.greco-prog.fr
From: pchen@crhc.uiuc.edu (Paul Chen)
Newsgroups: comp.sys.intel
Subject: iPSC/2 query
Date: 10 Apr 92 03:24:03 GMT
Organization: Center for Reliable and High-Performance Computing, University of Illinois at Urbana-Champaign
NNTP-Posting-Host: jarrett.crhc.uiuc.edu
Summary: does hrecv work as advertised?
Keywords: hypercube, iPSC/2, hrecv

i've been having problems with the hrecv() function implemented
for the iPSC/2.  i've built a bare-bones test implementation involving
just 2 nodes.  each sends 1 msg to the other [recv'd via hrecv()]
and expects an acknowledgment [sent using csend() inside the hrecv()'s
handling procedure].  sometimes the program runs fine to completion,
but about 50% of the time the program hangs.  using printf()s to debug,
my conclusion is that the handling procedure invoked by a msg recv
using hrecv() sometimes does not return properly.

has anyone else come across this problem, and if so, is my conclusion
well-founded?  any suggestions or comments otherwise?

any help is appreciated.  (i've tried decon without much success in even
getting the application to run with breakpoints without crashing the
entire system.)  it's driving me crazy.

paul chen
pchen@uiuc.edu
From: nevries@accucx.cc.ruu.nl (Nico de Vries.)
Newsgroups: comp.sys.intel
Subject: Re: RapidCAD CoProcessor
Date: 16 Apr 92 17:11:47 GMT
Organization: Academic Computer Centre Utrecht

In <9204161529.AA17540@data.src.honeywell.com> bergstro@src.honeywell.com (Pete Bergstrom) writes:


>The May issue of Byte has an ad for intel's RapidCAD Engineering
>CoProcessor.  It is a drop in replacement for the 386/387 duo that
>supposedly gives up to 70% speedup on certain CAD functions.
Seems to be the answer of Intel to Cyrix etc.

>So what's the story here?  What does this look like, how much of my 3d
>graphics stuff has to be specialliy coded to take advantage of it,
>etc?
None. The RapidCAD just needs less clock cycles per instructions. Other
manufarturers do this already (Cyrix, IIT etc) and this is taking market
share away from Intel so thay had to device something better.

>Pete


Nico E. de Vries
-----------------------------------------------------------------------------
USENET: nevries@cc.ruu.nl                 FIDO      : 2:281/708.1  
VOICE : +31-3404-24931 (+31-30-316931)    FAX       : +31-30-312033 
BBS   : +31-30-341401 (Nico De_vries)     COMPUSERVE: (coming "soon")

IMPORT Disclaimer, MyPersonalOpinion;            O O  Place reserved for
Complaints about my typostyle to DEV/NUL please.  |   funny joke. Sugestions 
I work for BITECH, I don't SPEAK for BITECH.     \_/  apreciated. <== WELL ?
Newsgroups: comp.sys.intel