HDTenEightyP/NetNews huggingface dataset:
From: adrie@ica.philips.nl (Adrie Koolen)
Newsgroups: comp.unix.sysv386
Subject: Re: sector remapping woes with 1542A/SCO Unix
Date: 21 Jul 92 10:02:07 GMT
Organization: Philips Consumer Electronics, Eindhoven, The Netherlands

In article <467@wurtel.hobby.nl> paul@wurtel.hobby.nl (Paul Slootman) writes:
>I have a strange problem. I recently added a SCSI controller and
>disk to my 386 system (Adaptec 1540A and Fujitsu M2249SA (I think)).
>I already have an Adaptec RLL controller with two drives in my machine.
>
>The problem is this: if I disable the two "standard" disks in the CMOS
>setup of the machine, the Adaptec SCSI controller properly sees the
>SCSI disk and installs it as C:. If I put DOS on it, there's no problem,
>I can boot from it, run apps, etc.: everything works ok. The SCSI BIOS
>remaps the sectors to 318 cylinders of 64 heads, 32 sectors, giving me
>318 MB, which is right.
>
>However, when I access it from UNIX by installing SCO Unix 3.2.2, SCO
>tells me it's a disk with 1272 cylinders, 16 heads, 32 sectors, also
>giving me 318MB. However, after installing everything, I can't boot from
>it ("NO OS").

I'm no expert on this, but I think that you've got a `old' 1540A with an
updated BIOS EPROM. Old 1540A's have a BIOS which maps the disk on 16
heads. With 1024 cylinders and 32 sectors per track, disks max-out at
256MB. Newer EPROMS map at 64 heads per cylinder. You can ask the
AHA154x adapters for their type. Your 1540A obviously reports that it's
a 1540A, which the SCO thinks that it has a 16 head BIOS. That's why
it maps the disk that way. It talks directly with the 1540A so it has
no 1024 cylinder limit of the PC BIOS.

>Some exploratory work shows me that the PC BIOS wants to load the stuff
>from the hard disk, but does this using the first translation (64 heads).
>As the partition table is written while 16 heads are assumed, the stuff
>can't be found, and the bootstrap fails.
>
>Why does SCO Unix think that a different sector translation is called
>for?

You've got a problem here. You could switch to the old BIOS, but I don't
know where to get one (although a brother of mine has an 16 head 1540A,
you probably don't want a copy of its PROM). You'd lose 62MB this way!
You also could have the microcontroller PROM replaced so that it reports
as a 1540A with 64 heads. I'm not sure if this PROM update exists and
where to get it. The last possible solution is to update the SCO SCSI
driver that it maps the disk with 64 heads per track.

Note, I'm only guessing, but I think that I'm in the right direction.

Adrie Koolen (adrie@ica.philips.nl)
Philips Consumer Electronics, Eindhoven, the Netherlands
Newsgroups: comp.unix.sysv386
From: larry@trauma.rn.com (Larry Snyder)
Subject: Re: HELP!! run out of spaces for news
Organization: Gator Conferencing Systems - 219-289-0777 - 6 lines
Date: Wed, 22 Jul 1992 17:52:11 GMT

a-willyp@microsoft.com (Willy Paine) writes:

>My hardware is:  DELL UNIX SVR4 with ESDI 650 meg 
>                 hard drive.

OK

>I need your help on setting mkfs for news spools
>(/usr/spool/news).   I get running out of disk
>spaces (out of inodes), even I have 94 megB left.

>I am trying to use 1/2 of whole hard drive for
>one file system named /usr/spool/news.  Can you
>please help me to build file system with enough
>inodes for full newsfeed?   Need to know the
>information on getting block and inodes numbers
>plus parameters of mkfs.

you could look in the manual for mkfs under the ufs page --

but something like

mkfs -Fufs -onbpi=2048,free=0,opt=s ..... should work

the key is the nbpi parameter which handles the inode blocking

-- 
Larry Snyder                                    internet: larry@gator.rn.com
4950 Estero Blvd, Ft. Myers Beach, FL            uucp: uunet!rde!nstar!larry
From: johnr@mendip.UUCP (John Redden)
Newsgroups: comp.unix.sysv386
Subject: esix 4.0.4 experiences
Date: 24 Jul 92 14:07:25 GMT
Organization: ICL North America, Irvine, CA 92718


Have any of you purchased or upgraded to Esix 4.0.4?  

What bugs have been fixed?

Was the bug fixed that prevented access of Dos partitions on the hard disk?

Specifically, what features were added?

thanks in advance,

John Redden

johnr@al.irv.icl.com   (work)
zenred!redden@xenon.sr.com (home)
Newsgroups: comp.unix.sysv386
From: fr@compu.com (Fred Rump from home)
Subject: Re: Dell Unix..
Organization: CompuData Inc.
Distribution: usa
Date: Wed, 22 Jul 1992 18:02:58 GMT

witr@rwwa.COM (Robert Withrow) writes:

>In article <1992Jul17.214224.5589@dellunix.dell.com>,
>  donn@dellunix.dell.com (Donn Baumgartner) writes:

>| Give us a frigging BREAK! [...][Dell] sales people are notorious
>| for knowing little about software and quick to dispose of callers
>| who waste their time asking about it.

>Naah.  I'm betting on these being forgeries.  I'm sure we will get
>a disclaimer soon, right?

I've had words with Donn. The guy is honest about his feelings. Personally,
I'd rather that than to have a smile in my face and a dagger in my back.

Donn could well have substituted the name of any technically oriented company
above.  It should surprise no one to know that when a customer calls, he first
breathes a sigh of relief to have finally found a salesperson to whom he can
talk.  We hear this all the time.  "I've checked everywhere and you're tha
first person who understands what I'm talking about." Normally one has a
customer for life at that point.

Let's face it, sales folks are not generally known to be technically literate
too. I think that is what Donn said above under the Dell signature. I don't
think it's anything to get upset about.

Fred

-- 
W. Fred Rump 	office:	   fred@COMPU.COM     'mans feet have grown/so big 
26 Warren St.   home: fred@icdi10.compu.com  that he/forgets his littleness'
Beverly, NJ. 08010                          		Don Marquis 
609-386-6846    bang:uunet!cdin-1!icdi10!fr
From: nc00@eurotherm.co.uk (Neil Corlett)
Newsgroups: comp.unix.sysv386
Subject: Re: What the 17" monitor reviews never tell you [28] Stephen Hite
Date: 27 Jul 92 08:24:22 GMT
Organization: Eurotherm Limited

We had similar problems with a EIZO/Nanao T560i. We eventually persuaded them
to swap it for another unit. It's the only fix possible. Even then, they told
us that the dodgy unit was well withing their specifications.

You can always try Sony, who make the Trinitron tubes, as an alternative.

Neil
-- 

Janet:    nc00@uk.co.eurotherm    | Eurotherm Limited, Faraday Close,
Internet: nc00@eurotherm.co.uk    | Durrington, Worthing, W.Sussex, England.
UUCP:     {ukc,uunet}!etherm!nc00 | Phone: +44 903 68500  Fax: +44 903 65982
Newsgroups: comp.unix.sysv386
Subject: uugetty -> too many respawns???
From: bmyers@mcopn3.dseg.ti.com
Date: 20 Jul 92 08:12:19 CST
Organization: Texas Instruments Defense Systems & Electronics Group

Here's the scenerio:  Consensys V4 with beta test Mouse driver disk, Telebit
WorldBlazer connected via 9-to-25 serial cable.

If i switch over to using the inittab entry, with the following as an example:

01:23:respawn:/sbin/uugetty -r -t 60 19200NP

and issue a 'init q' command, I get a msg back from the system telling me that
there is something wrong; that the process is respawning too fast for the
system.

any ideas?  if i change the uugetty to getty, and drop the '-r -t 60', I
have a working input line.  

-bob

p.s.  I waiting for SASS 2.0 to show up, instead of trying to install/debug
sas-1.25 on my machine.
From: kd1hz@anomaly.sbs.risc.net
Newsgroups: comp.unix.sysv386
Date: 19 Jul 92 16:08 MDT
Subject: Re: >>An example of Dell's product 
Nf-ID: #R:BrKM6r.656@acsu.buffalo.edu:1442127962:1992Jul19.150851.16330@anomaly.s:-1275490557:001:623
Nf-From: anomaly.sbs.risc.net!kd1hz    Jul 19 16:08:00 1992


jones@acsu.buffalo.edu (terry a jones) writes:

>The up side is that if he keeps this up for long he may
>end up in the doghouse.  The down side is that he may end up demoted....
>to technical support.  "What do you mean your boot floppy won't boot?
>Dell does not produce that floppy disk!  Your complaint is unjustified."

Nah, with this attitude, I tend to think he will be hired by SCO's Channel
Marketing group.

MD
-- 
--  Dr. Michael P. Deignan (deg.pend.)      /   "Its okay dear,
--  Domain: kd1hz@anomaly.sbs.risc.net     /     you can show me...
--    UUCP: ..!uunet!anomaly!kd1hz        /      I'm a Doctor..."
From: Eugene Dworechensky <jno@glas.apc.org>
Newsgroups: comp.unix.sysv386
Date: 21 Jul 92 21:53 MDT
Subject: Re: Real time in UNIX ???
Nf-ID: #R:glas:10200004:glas:10200005:000:158
Nf-From: glas.UUCP!jno    Jul 21 21:53:00 1992


Hi again!

Many thanks for your assistance!
But sound is bad to me :-(
UNIX seems to be not able to handle millisecond intervals...
Thanks again

regards
jno
From: stan@dixie.com (Stan Brown)
Newsgroups: comp.unix.sysv386
Subject: Re: Dell SVR$ (and Dell hardware) total lack of success on Postscript
Date: 21 Jul 92 21:45:40 GMT
Organization: Dixie Communications Public Access.  The Mouth of the South.

rhealey@dellr4.digibd.com (Rob Healey) writes:

>In article <t3bm!g+@dixie.com>, stan@dixie.com (Stan Brown) writes:
>|>    I have spent over 15 years working on computers and industrail
>|>    control equipment and making strange and unusal stuff work with
>|>    each other.  I have 10 years of UNIX experience.  I am almost at
>|>    the point of rwnting a RS-232 line anlyzers and sending you guys a
>|>    print out! 
>|> 
>	The printout would probably show the HP printer was screwing up
>	on serial flow control, they tend to do that. I've long since
>	given up on HP's doing serial flow control properly and just
>	use the parallel interface. My guess is you'll get it to
>	work just fine if you do that. I've installed HP and HP alike

   Unfortunatly that is not suported because the Dell's Postcript
   filter wants to query the printer for status and a parallel port is
   output only.

>	printers on a couple of different SVR4's, Dell and AmigaUNIX
>	mostly, and the parallel interface works great on both systems.
>	The serial wouldn't fly no matter what I tried and it didn't
>	seem worth the effort to bother.

   There are known bugs in the USL serail driver, which Dell has
   fixed.  And contributed back to USL to allow this to propogate to
   other vendors.

>	HP has some strange beasts for hardware, really bizzare
>	flow control stuff if you aren't used to it.

   you mean like "robust XON"? or the Enq Ack stuff ?

-- 
Stan Brown					    Electric Systems Inc.
Home (404) 299-2225				Atalanta Ga. (USA)
Home (615) 894-5781				Chattoonaga TN (USA)
Work (615) 899-1714				stan@dixie.com
dixie.com = Public Access UNIX in Georgia
Newsgroups: comp.unix.sysv386
From: ihno@generics.ka.sub.org (Ihno Krumreich)
Subject: Re: How to debug a PANIC??
Organization: Generics GmbH
Date: Fri, 24 Jul 1992 17:19:42 GMT
Keywords: unix panic interactive debug

howardl@wb3ffv.ampr.org (Howard Leadmon - WB3FFV) writes:


>    Hello,

>I am currently running Interactive UNIX version 3.0, and things have 
>generally been great.  The other day I had my system PANIC and crash
>twice within a couple hours.  I know there is supposed to be a way I
>can find what program was dying by using the kernel debugger, but am
>not sure how to do this.  If somenody on the net would be so kind as
>to give me a little instruction it would be most appreicated...

>Just for information sake, the panic was a Trap 0x0000000E

Bad luck for you trap 0xe says nearly nothing.

The way to find the programm probably killing the machine is the following:

1) After the panic the system should report how many pages it has written to
   the swap space. If that does not happen, no need to read the rest.

2) When the system comes up again, the system shouls ask you, whether you
   want to save the memory dump. Save it. (if you want to save to diskettes,
   prepare enough. If you have 16 Meg of memory you need 14 diskettes)

3) If the system is up again load the dump to the disk with the command
   ldsysdump.
   Now you can use the command crash to analyse the dump.
   All commands, wich are discribed now are within crash

   crash>  p	# gives you all processes that have been on the system
		# when it crashed. In the second coloum (ST) the state of
		# process is noted. s for sleeping, r for runnable and
		# p for on processor. So the one with the p should be
		# of intressed for you..
		# Have a look at the slot number (first coloum).
   crash> t #s  # t with the slot number gives you a trace of the called
		# procedures of the numbered process. This may give you an
		# idea which driver was the bad one.

   crash uses the /unix for the symbols and other information. If you want
   to analyze the dump on a different machine, you always need the kernel from
   the machine which paniced. 

   hope that helped you.

Ihno

=======================================================

Ihno Krumreich     | Phone (49) 721 38 70 94
Generics Gmbh      | email: ihno@generics.ka.sub.org
Breite Strasse 24  | FAX   (49) 721 38 56 22
D-W7500 Karlsruhe  |
-- 
Ihno Krumreich     | Phone (49) 721 38 70 94
Generics Gmbh      | email: ihno@generics.ka.sub.org
Breite Strasse 24  | FAX   (49) 721 38 56 22
D-W7500 Karlsruhe  |
Newsgroups: comp.unix.sysv386
From: andy@homebase.vistachrome.com (Andy Finkenstadt)
Subject: Re: ISC 3.2 2.21
Reply-To: andy@homebase.vistachrome.com
Organization: Vista-Chrome Incorporated
Date: Sun, 26 Jul 1992 19:04:31 GMT

larry@trauma.rn.com (Larry Snyder) writes:
>I have a copy of ISC 3.2 2.21 and can't find smtp --
>which disk does smtp reside?  It's not on the TCP disks
>which is where I would expect to find it...
>larry
>-- 
>Larry Snyder                                    internet: larry@gator.rn.com
>4950 Estero Blvd, Ft. Myers Beach, FL            uucp: uunet!rde!nstar!larry

-rwsr-xr-x   3 root     bin       138998 Apr  6 15:56 /usr/lib/sendmail

This is the SMTP daemon. :-)  And the SMTP client.

-Andy
-- 
Andrew Finkenstadt       | Vista-Chrome, Inc.   |    NIC Handle: AF136
GEnie Unix Sysop/Manager | The Printing House   |   ...!uunet!rde!andy
+1 904 222 2639 home     | 1600 Capital Cir SW  |  andy@GEnie.geis.com
+1 904 575 0189 work     | Tallahassee FL 32310 | andy@vistachrome.com
Newsgroups: comp.unix.sysv386
From: beattie@hfsi.uucp (Brian Beattie)
Subject: Re: Warning about Diamond Speedstar 24
Organization: /etc/organization
Date: Fri, 24 Jul 1992 02:18:11 GMT

In article <9790@fs3.cam.nist.gov> crosson@cam.nist.gov (Robert Crosson) writes:
>
>Please say this isn't so!!!  I just ordered a Diamond SpeedStar 24, but
>before I did I called Diamond's technical assistance line to ask if it would
They lied!
>run X386.  They said it would.  Has >anybody< been able to get this new
>board running?
>
>Bob Crosson
>crosson@cam.nist.gov

I have been able to use the Speed Star 24 using the following kludge.

1. boot dos, run vmode.exe (supplied by Diamond)

2. select monitor configuration.

3. select custom monitor, run through the 640x480 setup, the 800x600 setup
   when the 1024x768 setup screen mode comes up CTL+ALT+DEL

4. boot UNIX and the third clock will be set at the speed for 1024x768.

This is good until the power is turned off.

Now if somebody can pry the information required to program the clock
out of Diamond I sure we can get somebody to add speed star support
to X386.
Xref: sparky comp.unix.sysv386:12255 comp.os.linux:6429
From: shite@sinkhole.unf.edu (Stephen Hite)
Newsgroups: comp.unix.sysv386,comp.os.linux
Subject: Followup on Nanao F550i and Diamond Speedstar 24
Date: 22 Jul 92 17:52:28 GMT
Organization: Univ. of North Florida


   I had posted a previous message earlier today describing an
out of the ordinary moire problem I was having with my new Nanao
F550i.  I also purchased a Diamond Speedstar HIColor (the company that
sent it to me must be sending out 24's now instead of the original
HIColor).  The problem with the DS 24 is being discussed in the comp.os.linux 
newsgroup and I suggest those reading comp.unix.sysv386 who have X386 1.2E
and a DS 24 (or are thinking about getting one) read this discussion.
Anyway, the short version of what's being discussed is that the DS 24 
comes with a DOS software program called VMODE which programs the card
to send the correct vertical and horizontal scanning frequencies to the
monitor.  In my case it is a Nanao F550i.  

Now back to the Nanao (after talking with Nanao tech support)...

  The F550i uses a Mitsubishi tube.  Their reason was that out of the
6 or so manufacturers who make 17" .28mm dot pitch tubes, they felt
the Mitsubishi had the sharpest beam focus from corner to center.  I can
attest to this..the corners areas are as sharp as a tack (to steal PC
Magazine's line ;-)).  This increase in picture sharpness apparently
results in moire being more of a factor.  Moire is found in all monitors
with the better focused ones possibly being more sensitive than others
(people who have written me having the  Sony Trinitron tubes have mentioned
this).

  So, how can moire be controlled to "normal" levels?  The answer I've
come up with is that your timings coming from your graphics card have
to be more precise.  The reason I was experiencing these horrendous moire
patterns in 1024x768 on the Nanao F550i when testing with et4000 Windows 
3.1 drivers was because the Diamond Speedstar 24 was not setup correctly
with the VMODE program.  My F550i is not defective (my brain is 
dubious though ;-)).  It's just much more sensitive to card timings with
the result being manifested as obtrusive moire.

Footnote: the seriousness of the moire I'm talking about doesn't get corrected
          by the usual adjusting of the vertical stretch panel control
          unless you want a *very* small 1024x768 on your nice 17" monitor. ;-) 

What problems still remain?

  Windows 3.1 is nice but frankly I'm on the Unix side of the fence at home
much more often running X386 1.2E.  The Diamond Speetstar 24's funky
new method of programming dot clocks makes it unusable with X386 1.2E
right now, but hopefully I can get some information from Diamond
and pass it on to some people on the net who are much better adept at
graphics drivers than I so this can be fixed by the next release. 



Steve Hite
shite@sinkhole.unf.edu 
Newsgroups: comp.unix.sysv386
From: ignatz@chinet.chi.il.us (Dave Ihnat)
Subject: Re: The grammar idiot. (was Re: AN ABJECT APPOLOGY)
Summary: Well, gosh, we just needed an explanation
Organization: Chinet - Public Access UNIX
Date: Tue, 28 Jul 1992 17:49:16 GMT

In article <rzlmxgh@dixie.com> jgd@dixie.com (John De Armond) writes:
>
>You must have a very boring life.  
>
>I started to reply to this bozo in Email but I decided he needed to
>be addressed in public.
>
>Stan is nearly blind.  I've never asked him but I assume this qualifies
>as legally blind.

John, I'd just like to comment that I've heard, in private face-to-face
conversation, a number of comments about the spelling and grammar in Stan's
postings; it's not just Fred.  He's just the first to mention it.

In combination with Stan's involvement in the furor in this group, it didn't 
reflect well on his professional image--since we were unaware of the difficulty
he has physically composing articles.  Nobody (reasonable) is going to fault
Stan for difficulties due to physical handicap, *if they know about them*;
obviously, many of us don't.  (I personally understand; I'm legally blind
without glasses or contacts, although I'm fortunate enough to be correctable
to 20/20 and 20/15 with them.  But I have that shadow hanging over me, all the
same.)

I believe that Fred's point is that if someone doesn't have such a handicap
that correction of spelling and grammar requires a great effort, then it's
a courtesy to use such tools as 'spell' to help at least approach standard
English spelling.  It's a small irritation, like the consistent misuse of
'kernal' for 'kernel'; nothing that will cause the fall of western
civilization, but an itch you can't scratch.  I don't think it deserves
calling Fred (or anyone) a bozo.  Let's be a bit more generous in our
assumptions, and a bit less touchy on the flames.  This is a professional,
technical group.  Alt.flames is there for recreational carbonization...

Thanks,
		Dave Ihnat
		ignatz@homebru.chi.il.us (preferred return address)
		ignatz@chinet.chi.il.us
From: mattair@sun44.synercom.hounix.org (Charles Mattair)
Newsgroups: comp.unix.sysv386
Subject: Re: Dell Unix..
Date: 27 Jul 92 14:10:23 GMT
Organization: Synercom Technology, Inc., Houston, TX

In article <1992Jul17.214224.5589@dellunix.d> donn@dellunix.dell.com writes:
>							- Donn
> [stuff deleted]
>        _
>       (")                                    Donn Baumgartner
>    \___|___/    Fear no Evil!                Staff Systems Programmer
>        |                                     Unix Development
>        |        Just Wanna Skate...          Dell Computer Corporation
>        |                                     1807 W Braker Ln, Bldg C
>       / \       Skate Free or Die!           Austin, Texas 78758
>    __/   \__                                 email: donn@dellunix.dell.com
>    oo     oo                                    or  uunet!dell!donn
>                                              TEL: (512) 339-5470
>disclaimer:  I speak for myself...            FAX: (512) 338-8780
>
>P.S.  I am not your personal contact at Dell :-)   If you have a question
>      about Dell or Dell Unix, send mail to support@dell.com or info@dell.com
>      [My mail box thanks you :-]
>

Is a fifteen line .sig really necessary?
-- 
Charles Mattair			      (preferred) mattair%synercom@hounix.org
Fast, Cheap, Good.  Choose Two. (anon)		   (or)	mattair@synercom.UUCP
Any opinions offered are my own and do not reflect those of my employer.
--------------------------------------------------------------------------------
From: andreas@xenox.w.open.de (Andreas Laumann)
Newsgroups: comp.unix.sysv386
Subject: Re: uugetty -> too many respawns???
Date: 22 Jul 92 23:58:12 GMT
Organization: Public News Server Wuppertal

In <1992Jul20.081219.155@mcopn3.dseg.ti.com> bmyers@mcopn3.dseg.ti.com writes:

->Here's the scenerio:  Consensys V4 with beta test Mouse driver disk, Telebit
->WorldBlazer connected via 9-to-25 serial cable.

->If i switch over to using the inittab entry, with the following as an example:

->01:23:respawn:/sbin/uugetty -r -t 60 19200NP
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I think here is your problem ...  You forgot the Devicename  e.g. tty00

This is a working entry to inittab for me ...

F2:23:respawn:/usr/lib/uucp/uugetty -t 45 ttyFM02 38400H # HST  38400 302656



->p.s.  I waiting for SASS 2.0 to show up, instead of trying to install/debug
->sas-1.25 on my machine.

Sas-1.25 works fine for me (DELL 2.1)  ...  

Ciao
	Andreas 
-- 
andreas@xenox.w.open.de    Voice: +49 202/306081 Data: +49 202/(307856/302656)
Andreas Laumann Wuelfrather Str 5, 5600 Wuppertal 1, Germany, Europe, Terra
" Ich hasse dieses bloede Geraet, verkaufen sollte man diese Plage,
  Wenn es, was ich will, nur taet' und nicht nur das, was ich ihm sage ...... "
From: herbst@seq.uncwil.edu (R.T. Herbst)
Subject: uugetty
Keywords: uugetty
Organization: Univ. of North Carolina @ Wilmington
Date: Sat, 25 Jul 1992 01:31:13 GMT

According to the rel3.2.2 manual the syntax for the uugetty 
entry in /etc/inittab is

30:2:respawn /usr/lib/uugetty -r -t<timeout> -d<delay> <line> <speed>
<type> <linedisc>
-r causes uugetty to delay putting out a login prompt until
it reads a character.

-t<timeout> quit if no response to login.
-d delay login prompt for <delay> seconds.
Speed line speed.
<type> of terminal connectecd to line.
<linedisc> set line discipline default is LDISCO.
uugetty -c <file> checks speed and tty defs in <file>
results to stdio.
Turn out that rel4.1 does not show uugetty in /etc/inittab
rather sac -t shown. 

This is new. One should use sysadm to set up a line.
warning first set up line using bnu then set port services.



Also "...CAN'T FIND DEVICE" may mean that you modem is not initialized.
I fine that power down of modem helps this disease.

herbst@seq.uncwil.edu