HDTenEightyP/NetNews huggingface dataset:
From: marion@crl.LABS.TEK.COM (Marion E. Pfaff)
Newsgroups: or.forsale,pdx.forsale
Subject: House for Sale
Date: 12 Aug 92 15:49:49 GMT
Article-I.D.: crl.4670
Followup-To: send
Distribution: or
Organization: Tektronix Inc., Beaverton, Or.


                        FOR SALE  - BALD PEAK

Custom built 4 bedroom home (Approx. 2500 sq. ft.)
5 wooded acres with view of pastures and coast range
Very secluded and private
Spring fed or city water available
3 bathrooms, two pantry's, large family room
Large wrap around deck on second level
Fruit trees
2 efficient wood stoves - heats entire home
Shop/second garage 
Large carport under deck
Taxes: $2200

If you like black starry nights and beautiful sunsets, no water bill,
Yamhill county taxes (the back property is the county line) and miles
of horse riding trails or hiking trails this is a very special piece
of property. Part of the acreage has been cleared as I was going to
build barn etc for horses.

It takes 30 minutes to get to Tek Beaverton, 40 minutes if you get 
stuck behind a school bus. Most of the 18 mile drive are country roads. 

Contact me immediately as I will be listing with relator in less than
one week.

Am asking $179,500.
628-3252
Newsgroups: vmsnet.uucp
Subject: Re: pathalias V1.2 fails with "out of memory error"
From: allebrandi@inland.com (Tom Allebrandi)
Date: 17 Aug 92 12:16:39 CST
Organization: Inland Steel Company; East Chicago, IN

In article <4077.2a88f843@prowest.propress.com>, pan@prowest.propress.com writes:
> While I was on vacation (of course), pathalias started failing with and leaving
> zero-block files in uucp_data:paths.  This started happening on two different
> machines at the same time.
> 
> The pathalias.log looks like this:
> 
> ...
> "DISK_0:[UUCP.DATA.MAPSRC]U.USA-WY-1;20", line 1: parse error
> "DISK_0:[UUCP.DATA.MAPSRC]U.ZAF-1;20", line 1: parse error
> $2$dua0:[uucp.bin]pathalias.exe;4: out of memory (7864k allocated); notify the
> authorities
> 

What version are you running? The article subject indicates 1.2 and I
think there lies the problem. These messages look real familiar, but
I think the underlying problem was fixed in 1.3...

--- Tom
Tom Allebrandi             | Mail guru   - DECUS UUCP Development Team
Inland Steel Research Labs | NFS grunt   - CMU/Tek-IP
East Chicago, IN           | Chairperson - VMSnet Working Group, DECUS VAX SIG
219 399 6306               | Internet:  allebrandi@inland.com
DECUServe: allebrandi      | UUCP:      ...!uunet!inland!allebrandi
Newsgroups: vmsnet.uucp
Subject: UUCP 2.0 and ALLIN1
From: system@nuconvex.com
Date: Tue, 18 Aug 92 15:53:29 EDT
Reply-To: synful+vmsnet@DRYCAS.CLUB.CC.CMU.EDU
Organization: The Internet
Return-Path: <synful+vmsnet-errors@DRYCAS.CLUB.CC.CMU.EDU>
Errors-To: synful+vmsnet-errors@DRYCAS.CLUB.CC.CMU.EDU
X-Vms-Mail-To: UUCP%"vmsnet@drycas.club.cc.cmu.edu"

I have installed UUCP 2.0 and it's a good thing.  A number of people at my
site use ALLIN1.  I have set up the UUCP host as a "firewall" such that all
addresses appear to originate from "nuconvex", and incoming mail is
forwarded to the proper node.  Now with 2.0 I am suddenly sending addresses
like "nuconvex.com!allin1.dnet!mrgate.dnet!a1.dnet!simonpg".  I haven't
decided whether this is a bad thing in my case or not.  But I sure don't
know how to handle it!  What does the rewrite rule to handle this look like
?  If I wish to continue "firewalling", how do I get this back to
"simonpg@nuconvex.com"?

Paul
From: allebrandi@inland.com (Tom Allebrandi)
Newsgroups: vmsnet.uucp
Subject: Re: Logging outgoing mail?
Date: 20 Aug 92 23:56:09 CST
Organization: Inland Steel Company; East Chicago, IN

In article <1992Aug19.100738.103@datani.dk>, ht@datani.dk writes:
> Among other things they require a log of all incoming and outgoing mail -
> sender, receiver and subject - to be logged in case of worms, vira or 
> other nasty items coming through here.
> ...
> Is there a way of doing this without altering the code? I usually don't
> like to "meddle" in the innards of systems as complex as this (and 
> especially not when others are maintaining it and I have to apply my
> fix every release ;-))

The Mail Handler code currently does not do any logging. I've thought
about it a few times but never implemented anything.

If you have a Pascal compiler, you might look at MAIL_OUT_FILE in
UUCP_MAIL.PAS. This is the routine that actually writes the output files.

--- Tom
Tom Allebrandi             | Mail guru   - DECUS UUCP Development Team
Inland Steel Research Labs | NFS grunt   - CMU/Tek-IP
East Chicago, IN           | Chairperson - VMSnet Working Group, DECUS VAX SIG
219 399 6306               | Internet:  allebrandi@inland.com
DECUServe: allebrandi      | UUCP:      ...!uunet!inland!allebrandi
Newsgroups: vmsnet.uucp
Subject: Re: VAX to Ultrix uucp connection problems
From: jeh@cmkrnl.com
Date: 20 Aug 92 11:24:04 PDT
Distribution: usa
Organization: Kernel Mode Consulting, San Diego, CA

In article <1992Aug19.162557.640@totaltec.com>, mark@totaltec.com writes:
> I have a question for you. 
> I have a VAX running VMS V5.5 and UUCP 2.0 and I am trying to get it to
> communicate with a DECstation 5000 running Ultrix 4.2a. I set up the VAX
> to poll the DECstation. It logs in ok and negotiates properly but then
> I get error messages trying to open files on the VAX side?
> 
> It appears to get these message when the DECstation is trying to send 
> something to the VAX. UUCP on the VAX doesn't even see the work files
> for the DECstation on the VAX! Confused yet?

PLEASE, EVERYBODY:  WHEN POSTING A PROBLEM DESCRIPTION, INCLUDE:

	- the version of DECUS uucp
	- the version of VMS
	- output from uucp.log showing the problem

If possible, try to reproduce the problem with relevant debug bits enabled,
and include the output from the debug log.  For this problem, a debug mask
of 0177 (octal) would be helpful.  

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and 
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
From: ht@datani.dk
Newsgroups: vmsnet.uucp
Subject: Logging outgoing mail?
Date: 19 Aug 92 08:07:37 GMT
Organization: Datani A/S, Copenhagen, Denmark

The management at this site is getting secutity consious, not a bad thing
but it does give me some extra work.
Among other things they require a log of all incoming and outgoing mail -
sender, receiver and subject - to be logged in case of worms, vira or 
other nasty items coming through here.

I have found where to log the incoming mail (in uuxqt_dcl.com) but I
can't find anywhere where I can get 'hold' of the outgoing mail.
In uucp.log it just says that we want to send file D.xxxxxx to our
neighbouring site andthat is not good enough.

Is there a way of doing this without altering the code? I usually don't
like to "meddle" in the innards of systems as complex as this (and 
especially not when others are maintaining it and I have to apply my
fix every release ;-))
Has anybody done something like this before?
If not where in the code should I start looking?

---
Henrik Tougaard             E-mail: ht@datani.dk
Datani A/S, Software Consultants
Copenhagen, Denmark         Only my own opinions........
From: roseberry@taney.uscghq.uscg.mil
Newsgroups: vmsnet.uucp
Subject: UUCP_UUXQT_DCL_RMAIL_MX logical for MX
Date: 13 Aug 92 07:25:02 EST
Organization: United States Coast Guard


	I couldn't find out why MX wasn't working properly with UUCP until
	I went looking around and found there needs to be a logical name
	defined to make UUCP pass off to MX ---  UUCP_UUXQT_DCL_RMAIL_MX.
	In the previous versions you were instructed by the MX documenta-
	tion to make specific code changes to the UUCP command procedure.
	This is a much cleaner way to do things.

	Should I edit "CONTROL" to make this definition or where is it
	supposed to be made ?

	- Bert Roseberry
	  roseberry@taney.uscghq.uscg.mil
From: pan@prowest.propress.com
Newsgroups: vmsnet.uucp
Subject: pathalias V1.2 fails with "out of memory error"
Date: 12 Aug 92 11:38:43 GMT
Organization: Professional Press, West Coast Offices, Pasadena, CA

While I was on vacation (of course), pathalias started failing with and leaving
zero-block files in uucp_data:paths.  This started happening on two different
machines at the same time.

The pathalias.log looks like this:

...
"DISK_0:[UUCP.DATA.MAPSRC]U.USA-WY-1;20", line 1: parse error
"DISK_0:[UUCP.DATA.MAPSRC]U.ZAF-1;20", line 1: parse error
$2$dua0:[uucp.bin]pathalias.exe;4: out of memory (7864k allocated); notify the
authorities

Image accounting indicates that the image exit status was 10000004 (?), which
doesn't look like any exit status I can find, so that was no help.  I tried
simple stuff like increasing pagefile quota and wsextent, but that was no help
(not that I really thought it would).

Because it occured on two different machines, I suspect the map files, but
which ones?

Has anyone ever seen this error before? Can someone with source code give me a
clue as to why it occurs?

Thanks in advance.

Phil

_________________________________________________________________________
Philip A. Naecker                Consulting Software Engineer
Internet: pan@propress.com       1010 East Union Street, Suite 101
          uunet!prowest!pan      Pasadena, CA  91106-1756
Voice:    +1 818 577 4820        FAX: +1 818 577 0073

Also:     Technology Editor, DEC Professional Magazine
          VAX Professional Magazine Review Board Member
_________________________________________________________________________
From: allebrandi@inland.com (Tom Allebrandi)
Newsgroups: vmsnet.uucp
Subject: Re: UUCP 2.0 and ALLIN1
Date: 20 Aug 92 23:44:03 CST
Organization: Inland Steel Company; East Chicago, IN

In article <0095F496D05CC460.0000018D@nuconvex.com>, system@nuconvex.com writes:
> Now with 2.0 I am suddenly sending addresses
> like "nuconvex.com!allin1.dnet!mrgate.dnet!a1.dnet!simonpg".

How have you determined that you are sending addresses like this? There
is nothing in the code that should be causing this. The only place I
can think of that this is coming from is a rewrite rule. What do your
rules look like?

--- Tom
Tom Allebrandi             | Mail guru   - DECUS UUCP Development Team
Inland Steel Research Labs | NFS grunt   - CMU/Tek-IP
East Chicago, IN           | Chairperson - VMSnet Working Group, DECUS VAX SIG
219 399 6306               | Internet:  allebrandi@inland.com
DECUServe: allebrandi      | UUCP:      ...!uunet!inland!allebrandi
Newsgroups: vmsnet.uucp
Subject: Re: More info re: a problem with data overruns
From: jeh@cmkrnl.com
Date: 21 Aug 92 13:42:08 PDT
Organization: Kernel Mode Consulting, San Diego, CA

In article <1992Aug20.140611@mccall.com>, tp@mccall.com (Terry Poot) writes:
> I see this problem routinely on outgoing calls when my system comes up after a
> crash. I don't have any logs handy, unfortunately. It probably occurs while
> startup tasks are still running, so it is under heavy load, though I don't know
> what the IRP situation is. It's a temporary condition and seems to stop after a
> few minutes, presumably once the system has stabilized.
> 
>>In both cases, the most significant correlation I can find is that a VMS
>>backup
>>was running, the I/O request packet pool had expanded all the way to
>>IRPCOUNTV,
>>and (here's a new clue) the backup was waiting for another tape to be mounted.

When $QIO is called, if there are no pre-allocated IRPs available, one will be
allocated for you from the fragmentable pool.  So a shortage of IRPs will not
prevent you from doing I/Os (and therefore lead to typeahead buffer overruns in
the case of the terminal driver).  It'll just make the I/Os fractionally
slower. Since the overhead of allocating an IRP from the fragmentable pool is a
very tiny fraction of the total CPU time required to process a terminal read
$QIO, I hardly think that this matters. 

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and 
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
Newsgroups: vmsnet.uucp
Subject: uucp 2.0/NEWS crash question.
From: sbrant@npal.rn.com
Date: 12 Aug 92 00:12:18 EDT
Organization: PalNet -- Indianapolis, Indiana

HELP!

	I have just installed the new UUCP 2.0 and the NEWS program that came
	with it. 

	UUCP is working ok.  NEWS crashes whenever we do a forward
	command.  The NEWs program actually crashes, we get a register
	dump and takes us all the way out to dcl prompt.

	for example:  when reading a news item
	at the NEWS> prompt I type   forward sbrant

	and it dies.

	or type  forward user@xyzsys

	and again it dies.

	These commands used to work on our older vers of NEWS/UUCP.

	running vms 5.4-3 here.


	Any Ideas or suggestions?


	Thanks;

-- 

                                                     Steven B. Brant
________________________________________________________________________
       -->> sbrant@npal.rn.com <<--[ or ] -->> nstar!towers!npal!sbrant <<--
Newsgroups: vmsnet.uucp
Subject: Re: uuxqt won't start -- ILLEFC (answer and workaround)
From: jeh@cmkrnl.com
Date: 19 Aug 92 16:50:32 PDT
Organization: Kernel Mode Consulting, San Diego, CA

In article <0095F527FB4F5DE0.000000C0@nsrvan.vanc.wa.us>,
 Ethan VanMatre <sysevm@nsrvan.vanc.wa.us> writes:
> 	The uucp.log showns:
> 
> * Couldn't start uuxqt (%SYSTEM-F-ILLEFC, illegal event flag cluster) u:-

Whups.  Looks like there is a bug in start_uuxqt() (in sysdep.c).  It is using
LIB$GET_EF to get a local event flag but is neither saving the event flag
number nor freeing the flag.  If the uuxqt job dies more than about 30 times
within one run of uucico.c, we'll run out of local event flags, LIB$GET_EF
returns a -1 for the efn, and this error will appear. 

Everything should restart okay if you kill the uucico batch job and restart it.

If you have the source and the C compiler, declare the variable sjcefn as
static.  

I'll see if I can't figure out how to patch the .EXE ... it should be okay
to use efn 0 in this routine.  

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and 
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
Newsgroups: vmsnet.uucp
Subject: Re: vms-sunos login failures
From: jeh@cmkrnl.com
Date: 20 Aug 92 13:35:56 PDT
Organization: Kernel Mode Consulting, San Diego, CA

In article <1992Aug19.200729.260@mtechca.maintech.com>, carvalho@mtechca.maintech.com writes:
> Sorry if it's a FAQ...
>
> Trying to get sparc2 to uucp via dialup into 785 running decus uucp. The sparc
> dials thru a QBlazer, connect, reads the username and password prompt, which
> I've checked many times, the vax responds with a User Auth. Fail.
> help!
> --joe

Think about it.... this isn't a problem with decus uucp _per se_; if VMS is
reporting "user authorization failure" on a dialin call, you are talking to
LOGINOUT.  uucp hasn't started yet on the VAX (at least not as far as this
dialin is concerned; the uucico batch job that does outbound calls is not
involved AT ALL for inbound calls; in fact if you are only handling inbound
calls you don't need the outcall daemon at all).

Troubleshooting:

1.  Try to log in to the VAX, with the uucp username and password, via a
dialup connection:

If you still get "user authorization failure",
	check the UAF entry to see if the password is expired, or if the
	account is set to DISUSER, or to deny dialup access, or some such.

otherwise...

2.  If you can use the account via a "manual" login, but the Sun can't,
clearly the Sun isn't sending the right username and password, or else
the username and password are getting corrupted somewhere.  The best way
to troubleshoot this is to hang a serial line analyzer in the line
between the local modem and the VAX.

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
Xref: sparky vmsnet.uucp:649 news.software.anu-news:1276
From: brodie@fps.mcw.edu
Newsgroups: vmsnet.uucp,news.software.anu-news
Subject: Re: pathalias/pathproc parse error
Date: 17 Aug 92 00:15:33 CST
Organization: Medical College of Wisconsin,  Milwaukee, WI

In article <1992Aug14.085652.282@cutler>, john@cutler.com (John E. Babbitt Jr.) writes:
> I remember reading way back that pathalias/pathproc complained about a
> "parse error" on some of the maps.  I didn't bother to pay attention to it
> because I wasn't any collecting maps.  However, a friend of mine is 
> collecting, keeping his paths file up-to-date, and is having that problem. 

 .....
> Anyways, I traced the problem.  Here's the first few lines from one of the
> input map file:
> 
> file {u.usa.wa.1}
> # This map is maintained by David Schmidt (davids@isc-br.ISC-BR.COM).
> # Mail updates to uucpmap@rutgers.edu (rutgers!uucpmap).

> The "file {u.usa.wa.1}" is obviously causing problems.  Has someone come
> up with a fix for it?  Sure, my friend can upgrade, but doesn't feel too
> comfortable yet with news/uucp and has hardly the time to look at it. 

The relatively new "file" directive was introduced a while ago to
aid pathalias users in debugging problems with processing maps.
(i.e.,, if it's broke, where is the problem?)

kind of a catch-22, since the new directive isn't recognized by older
copies of pathalias!

Yes virginia, you have an older copy of pathalias.   Even if you don't
want to upgrade the UUCP software yet, you CAN pull off the new
pathalias and the problem will be fixed.

The new pathalias shipped with decus uucp V1.3.

--kent brodie, decus uucp distribution guy, and UUCP map coordinator for
  the moo state.
-- 
Kent C. Brodie - Sr. Systems & Network Manager	 InterNet:  brodie@fps.mcw.edu
Faculty Physicians & Surgeons			 uucpNet:   fps.mcw.edu!brodie
Medical College of Wisconsin			 MaBellNet: +1 414 266 5080

begin 700 sig.file
M+BYW:&%T(&1I9"!Y;W4@97AP96-T(&9O<B!A('1W;RUL:6YE('5U96YC;V1E
?9"!F:6QE+"!A(&-O;&]R('!I8W1U<F4_(" Z+2D@("UL
 
end
Newsgroups: vmsnet.uucp
Subject: Re: News v6.1 won't allow manager access
From: fenner@jazz.psu.edu (Bill Fenner)
Date: 13 Aug 92 15:43:15 EDT
Organization: Penn State University Mechanical Engineering

In article <1992Aug11.232239.5857@hayes.com> msieweke@hayes.com writes:
|After installing the new version of uucp and news, I am no longer able
|to execute news manager commands.  I had defined the NEWSMANAGER rights
|ID, and it was granted to my userid and to NEWSMGR.  However, news v6.1
|does not recognize either userid as a news manager.  Both userids have
|SYSPRV privilege also.

The problem is that the new NEWS switched to using  JPI to get the rights
list, and it's broken under certain versions of VMS (We're running 5.3-1
and it doesn't work here).

Retrieve the source, and in NEWSSITE.H add:

#define ORIGINAL_no_priv

and recompile.

(ANU 6.1 beta 1 has been released.  One of the additions is to automatically
set the name of newsgroups created with properly formed newgroup messages,
which is quite nice, so if you're going to be fetching it anyway, you might
as well fetch b1 instead of a4.)

  Bill
--
Bill Fenner	fenner@jazz.psu.edu	..psuvax1!hogbbs!wcfpc!wcf
		wcf@hogbbs.scol.pa.us   (+1 814 238-9633 v.32bis)
Newsgroups: vmsnet.uucp
Subject: VAX to Ultrix uucp connection problems
From: mark@totaltec.com
Date: 19 Aug 92 16:25:56 EST
Distribution: usa
Organization: Total Tec Systems, Inc.

Hello networld,

I have a question for you.
I have a VAX running VMS V5.5 and UUCP 2.0 and I am trying to get it to
communicate with a DECstation 5000 running Ultrix 4.2a. I set up the VAX
to poll the DECstation. It logs in ok and negotiates properly but then
I get error messages trying to open files on the VAX side?

It appears to get these message when the DECstation is trying to send 
something to the VAX. UUCP on the VAX doesn't even see the work files
for the DECstation on the VAX! Confused yet?

E-Mail me at mark@totaltec.com with suggestions.
Thanks in advance
Mark Remeta
From: tp@mccall.com (Terry Poot)
Newsgroups: vmsnet.uucp
Subject: Re: More info re: a problem with data overruns
Date: 20 Aug 92 20:06:11 GMT
Reply-To: tp@mccall.com (Terry Poot)
Organization: The McCall Pattern Co., Manhattan, KS, USA
Nntp-Posting-User: tp


[just catching up on this group, sorry to reply to such a stale thread.]

Here's another data point in case it helps anyone. ANALYZE/IMAGE says:

                image name: "UUCICO"
                image file identification: "simpact-1.3b"

In article <0095EE9C63E74EE0.000002D8@sycraft.com>, Ken Richardson >In article
<1992Aug10.093427.14260@infocomm.com>, mark@infocomm.com (Mark
>Pizzolato) writes:
>
>> This is generally what happens on a V.32 connection (WITHOUT any error
>> control) that is being torn down.  I don't understand the exact signal
>> processing issues that are going on here, but most V.32 modems end up
>sending
>> a LARGE burst of essientially garbage that I've seen ocaisionally overflow
>my
>> typeahead buffers which are currently set at 5000.
>
>I've seen this happen, and wondered why it didn't happen consistently, but I
>hadn't correlated that it was only on connections *without* error control. 
>But
>that *has* to be right.  It's nice to know why.  :-)

I see this problem routinely on outgoing calls when my system comes up after a
crash. I don't have any logs handy, unfortunately. It probably occurs while
startup tasks are still running, so it is under heavy load, though I don't know
what the IRP situation is. It's a temporary condition and seems to stop after a
few minutes, presumably once the system has stabilized.

>In both cases, the most significant correlation I can find is that a VMS
>backup
>was running, the I/O request packet pool had expanded all the way to
>IRPCOUNTV,
>and (here's a new clue) the backup was waiting for another tape to be mounted.

Not in my case. Of course some other (temporary) occurrance may have accounted
for the same conditions (no IRP's, or whatever the problem is), since the system
would have been busy rebuilding disks, starting layered products, etc.
--
Terry Poot <tp@mccall.com>                   The McCall Pattern Company
(uucp: ...!rutgers!depot!mccall!tp)          615 McCall Road
(800)255-2762, in KS (913)776-4041           Manhattan, KS 66502, USA
Newsgroups: vmsnet.uucp
Subject: vmsnet
From: system%niu.hepnet@lbl.gov
Date: Fri, 14 Aug 92 11:41:32 PDT
Reply-To: synful+vmsnet@DRYCAS.CLUB.CC.CMU.EDU
Organization: The Internet
Return-Path: <synful+vmsnet-errors@DRYCAS.CLUB.CC.CMU.EDU>
Errors-To: synful+vmsnet-errors@DRYCAS.CLUB.CC.CMU.EDU
X-St-Vmsmail-To: LBL::"vmsnet@drycas.club.cc.cmu.edu"
X-St-Vmsmail-Cc: SYSTEM

Hello
        I hope you are the right people to talk to.
        I am a system manager at the physics dept of Northern
Illinois University and was interested in getting on some of
the VMSnet news groups.  We currently receive Info-Vax and
is was from one of those mailings that I found your address.
        Do you know how to get on?
        We currently receive our mailings through Lawrence-
Berkley Labs but will shortly have direct internet access
through "Illinois-Net".
        Although I am interested in getting on a number
of the groups I wanted to post a question to
 .networks.tcp-ip.cmu-tek
                 .misc
                 .ucx
as quickly as possible (yesterday if you know what I mean)
        Any help you can give would be appreciated

Thanks for your time,
Robert Morphis
NIU::SYSTEM               (HEPNET)
system%NIU.HEPNET@LBL.GOV (internet)