HDTenEightyP/NetNews huggingface dataset:
From: larry@eco.twg.com (Lawrence B. Henry III)
Subject: Re: flushing in VAXC and DECC
Reply-To: larry@eco.twg.com
Organization: The Wollongong Group (East Coast Operations)
Date: Sun, 27 Dec 92 05:50:31 GMT


In article <6813@npri6.npri.com>, murphy@npri6.npri.com (David P.
Murphy) writes:
|>Path: eco.twg.com!uunet!psinntp!npri6!murphy
|>From: murphy@npri6.npri.com (David P. Murphy)
|>Newsgroups: comp.os.vms
|>Subject: Re: flushing in VAXC and DECC
|>Message-ID: <6813@npri6.npri.com>
|>Date: 27 Dec 92 04:14:14 GMT
|>References: <1992Dec26.211521.4768@spcvxb.spc.edu>
|>Distribution: world
|>Organization: NPRI, Alexandria VA
|>Lines: 23
|>
|>
|> >At the risk of adding some useful information to this discussion
|>8-), I
|> >think they were talking about the VAX C fsync() function. This is a
|>worker
|> >function used in the VAXCRTL to flush RMS buffers. It does exactly
|>what you
|> >want. Since it is used by the RTL, it is unlikely to change in
|>future re-
|> >leases of VAX C. On the other hand, it may not be present in DEC C
|>(the up-
|> >coming ANSI-compliant C compiler for VMS from DEC). DEC C may not
|>even need
|> >this as fflush() may work as you hope there. Ehud, want to check
|>this on
|> >your Alpha?
|> >
|> >terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
|>
|>wow, useful information!  lemme add some: the fsync() function is
|>indeed
|>available under alpha, in the DECC$SHR image, and it even does
|>something.
|>unfortunately, i don't have time right now to test if it is still
|>necessary.
|>
|>ok
|>dpm
|>-- 
|>murphy@npri6.npri.com 602 Cameron St. Alexandria, VA 22314 (703)
|>683-9090
|>
|>              When every one is dead the Great Game is finished.  Not
|>before.
|>                              --- Hurree Babu, "Kim"
|>

Not to be one to continue scrary precidents.. [ I for one read this group
for the grin factor associated with the flames posted by marginally informed
individuals posing as gurus.. directed towards people they feel are unworthy..
;-) its almost like watching the UN in action..] but I figure in the spirit
of Christmas and all.. if we are really going to post "real", "live" 
information...I can add that it is even documented in the online help on 
AXP machines.. (see below)


CC

  Run-time_functions

    fsync

       Flushes data all the way to the disk.

       Syntax:

            #include <stdio.h>

            int fsync(int file_descriptor);


CC Run-time_functions Subtopic?

              
-Larry.

PS. Don't take this serious unless you are one of those people out there posing
as a guru.. :-)
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: openVMS or UNIX.
Date: 23 Dec 1992 12:00:34 GMT
Organization: HST Wide Field/Planetary Camera
Distribution: world
Reply-To: carl@SOL1.GPS.CALTECH.EDU
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <1992Dec23.005104.8248@brt.deakin.edu.au>, dougcc@brt.deakin.edu.au (Douglas Miller) writes:
>In article <16DEC199219130792@spades.aces.com>, gavron@spades.aces.com
>(Ehud Gavron 602-570-2000 x. 2546) writes:
>
>> #Are Open propriatry operating systems goin to become the future of computing?
>>      ^^^^^^^^^^^^^^^
>> 	In addition to doing research, you should do a definition
>> 	check.  Open and proprietary are contradictory terms.
>
>Of course they are not.  Virtually all "open" computing is also
>"proprietary".

You've got a point there.  Perhaps you should wear a hat to hide it.  An "open"
system means that all the interfaces are well-publicised so that others can
write code that uses the interfaces.  Once you've done that, it's nonsense to
talk about the interface as "proprietary."

>An "open system" is one that minimises vendor lock-in (to
>the extent that is appropriate to whoever is building the system). 

I.e., the interface is available (free of charce) to anybody and his brother.

>"Proprietary" basicaly covers any product you pay money for.

E.g. LAT, where you had to reverse-engineer the interface in order to use it. 
OPEN means that the owner of the interface publishes details of the interface.

>There is no
>contradiction;

BULLSHIT!  A proprietary interface typically is never published;  it's
considered a trade secret.  An OPEN interface is published in detail.

>virtually all "open systems" are built largely or
>exclusively from proprietary products,

Yes, most of the implementations of open systems are proprietary.  However, the
INTERFACE is *NOT* proprietary.  As an analogy, ANSI C is *NOT* proprietary. 
It's an "open" standard.  However, you can bet your life that just about any
implementation of the standard *WILL* be proprietary.

>with vendor lock-in minimised by
>selecting products that conform to appropriate de-jure or de-facto
>standards.

Perhaps you'd benefit from an undergraduate couse in (shudder) philosophy,
which might teach you to pay more close attention to what you're nattering
about.
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: C pointer question
Date: 27 Dec 1992 09:22:16 GMT
Organization: HST Wide Field/Planetary Camera
Distribution: world
Reply-To: carl@SOL1.GPS.CALTECH.EDU
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <1992Dec26.225943.4312@netcom.com>, despair@netcom.com (Scott Hanson) writes:
>In article <24DEC199213510084@spades.aces.com> gavron@ACES.COM writes:
>[unnecessary but amusing attack deleted]
>Well I have solved most of the problems I was having.  A portion of the
>strangeness was caused not by putting the strange float switch on the
>compiler (which dec support asked about) but having a logical including
>the library.  Somehow that made 1/5 of my pointers act strangely.  Further
>problems were the result of VMS storing data on the other side of code
>(compared to Unix and Dos) I had a 1 byte mistake that caused no apparent
>trouble on the other two platforms but made the vax choke.  Now I know
>a couple of things to keep in mind when I am working on a vax.  That is
>what I had asked for, and still would appreciate.

Er, Scott?  I know I'm asking a lot more of you than many participants in this
newsgroup would be willing to give, but consider:
	1)  If you made a mistake, even if it was based on trying to take
	    advantage of undocumented and unsupported "features" of C compilers
	    on other systems, then other people might do the same thing;
	2)  You still haven't told us exactly what it is you did wrong;
	3)  If you detail your mistake, a memory of it will enter the
	    collective memory of this newsgroup (though sometimes I get the
	    feeling that there are only about half a dozen of us who remember
	    such things);
	4)  Nobody else *REALLY* wants to make your mistake.
Now, after pondering the above, could you be persuaded to let us all know just
what you did that caused the problem?  I for one would really like to know, and
IMNSHO, you'd be doing us all a service if you'd detail this particular pitfall.

I mean the following only in a positive way:  Remember: No effort is useless. 
It can always serve as a bad example.

If you can let us in on a mistake in using VAX C, you really would be helping
all of us (even though there are some dickheads out there who think that a
problem is only important if THEY are experiencing it right now).
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: VAX c
Date: 28 Dec 1992 16:28:20 GMT
Organization: HST Wide Field/Planetary Camera
Distribution: world
Reply-To: carl@SOL1.GPS.CALTECH.EDU
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <1992Dec27.100810.300@rlgsc.com>, gezelter@rlgsc.com writes:
>>>When the time expires, close the file. Then re-open it in append 
>>>mode. This will ensure that all of your buffers are flushed out 
>>>to the disk.
>> 
>> I tried that once.  Maybe it had to do with the way the file dealt with
>> records, but what I ended up with with was a file that had *ONE* record per
>> block.  Not what one would want.

>I would be interested in hearing exactly what type of file that 
>you had that problem of partial blocks with. I have been using 
>this solution in a range of applications for about 15 years on 
>both RSX and VMS and have never encountered the behavior that you 
>describe.

I last tried the close/reopen of the output file several versions of VMS ago,
and am no longer able (under VMS v5.4-2) to reproduce the problem.  Please
note:  The problem was associated with doing this via the VAX C RTL, so may
have been an RTL bug.
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.os.vms
Subject: Re: Butthead
Date: 25 Dec 92 23:16:28 GMT
Organization: Enea Data AB

Carl J Lydick (carl@SOL1.GPS.CALTECH.EDU) writes:
>I will, however, flame anybody who:
>
>	1)  Gets a detailed error message from VMS, then decides to ignore it
>	    when he posts his question to INFO-VMS/COMP.OS.VMS (questions of
>	    the form, "My program crashed, and spat out a whole screenful of
>	    stuff;  why did it crash [and, of course, the querant doesn't think
>	    that it's worth including ANY of that `Whole screenful of stuff'])

But, Carl, you know some people simply can't read error messages. For
them it's just useless garbage telling them that the program crashed.
They're are so shocked by this indecent behaviour of the computer -
not accepting their fantastic program, that would never accept that
the stupid machine are telling them what error they are committing.

When I was a student, I used to teach my younger mates Pascal and other 
programming subjects. On the Univac computer the university had when
I started teaching, the common error of having a semi-colon before ELSE 
was flagged by setting a 6 under the ELSE, and then at the end of the 
listing 6 was explained to mean "Illegal symbol". You can hardly blame 
a beginner for not understanding that intuitively. Then we got the VAX.
And to my delight, I discovered that the error message on VMS was bright 
and clear: "; ELSE is not not valid Pascal". But what do you think happened? 
Sure, the young student points at the error message and asks, "what does 
that mean?".

So people are not including error messages are consistent. For them its
utter garbage, why should they include it?

But I agree with Carl. Not that I really condone his and Ehud's
aggressive flaming, but I definitely share their sentiment against
people who properly can't explain what their problem, or simply are
too lazy to read what is printed before them on their screen or in 
their manuals. These people are simply wasting other people's times, 
and that is not good behaviour in my book.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
Jag gav en k{ck tjeck en check.
From: ewilts@galaxy.gov.bc.ca (Ed Wilts)
Newsgroups: comp.os.vms
Subject: Re: Time functions in VMS comparing and returning the difference
Date: 22 Dec 92 05:19:57 GMT
Organization: BC Systems Corporation

In article <921221000127.20407c7f@WSC.COLORADO.EDU>, STU011649835@WSC.COLORADO.EDU : The Macintosh Lab Manager : VIE Systems  writes:
> 	My problem is figuring out how to compare 2 time values and find the
> difference. I do not have access to the manuals ( if I did I would not know
> where to start). The online help dosen't provide much help. If you
> (anyone) have any sample programs, or anything else that might be of help,
> PLEASE send..... Fortran, Pascal, Basic, C and DCl are all ok, but prefer
> DCL programs. Thank you all.

Quite a while back I posted the sources TIME to vmsnet.sources.  One of the
archive sites should have this available.  It will allow you to easily compare
2 times and return a delta-time.

-- 
Ed Wilts, BC Systems, 4000 Seymour Place, Victoria, B.C., Canada, V8X 4S8
EWilts@Galaxy.Gov.BC.CA     Office:  (604) 389-3430   Fax: (604) 389-3412
From: BOB@AENEAS.IMS.DISA.MIL ("Bob George")
Newsgroups: comp.os.vms
Subject: re: VMS Source code...
Date: 23 Dec 92 15:42:00 GMT
Organization: The Internet

Subj:	RE: Request for sources

#>Can someone E-Mail me the sources to VMS?

#While you're at it, could someone E-transfer me a couple hundred thousand $?

Sure,

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

Sorry - had to do it!!!  It's a few $ short, but email me if you want 
extra's.   I'll make more.

#(^: Merry  Christmas!

Merry Christmas (and happy new...)
                                                               :\/\/\/:
                                    bob                        :______:
                                                               : (o)(o)
+----------------------------------------------------------+  c:   ___:
| Bob George     Internet : BOB@AENEAS.IMS.DISA.MIL        |   :     _)
| Disclaimer:    Opinions expressed are mine and mine only.|   : ,___:
+----------------------------------------------------------+   : __ /
                                                               /____\
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: Want a batch job scheduler
Date: 21 Dec 1992 08:19:40 GMT
Organization: HST Wide Field/Planetary Camera
Distribution: world
Reply-To: carl@SOL1.GPS.CALTECH.EDU
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <1992Dec21.063823.7334@netcom.com>, ltran@netcom.com (Linh C Tran) writes:
>Help,
>
>I am looking for a freeware  software to manage batch jobs/queues.  Can U tell
>where to FTP ?

FTP to your own system, and retrieve the file SYS$SYSTEM:JOBCTL.EXE.

>Thanx in advance...And Merry Xmas

Now, if you'd be so kind (I realize from all the flames I've gotten that it's
an act of kindness rather than simple common sense for some idiot to tell us
what he really wants, so I put this politely) as to tell us what it is that you
really want, maybe you'll get some useful answers.
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.
From: march@ohstpy.mps.ohio-state.edu
Newsgroups: comp.os.vms
Subject: Re: Mount verification timed out 
Date: 29 Dec 92 12:35:40 EST
Organization: The Ohio State University, Department of Physics

In article <1992Dec29.152302.1716@das.harvard.edu>, chen@speed.uucp (Lilei Chen) writes:
> In our VAX/VMS-cluster a bunch of disks are cross mounted.  Somtimes when
> a node goes down, its disks are marked mount verification timed out.  I
> haven't found a way to get those disks remounted without rebooting the
> nodes.  I am wondering if someone on the net has a solution for that problem.
> Thanks.
> 
> Jim  (xue@cfaft5.harvard.edu)

There is a command file in SYS$EXAMPLES: called MSCPMOUNT.COM that you can
modify and use to mount your CLUSTER mounted disks.  This procedure can run as
a detatched process that checks every 15 minutes for disks that need to be 
mounted and for disks that are marked as mount verification timed out.  When a 
disk becomes available it will be dismounted (if marked as mount verification 
timed out) and then will be mounted clusterwide.  You can invoke MSCPMOUNT.COM
in your SYSTARTUP_V5.COM file.  MSCPMOUNT will produce a log file that you
might want to purge periodically.

Don Marchlenski
The Ohio State University
Department of Physics
Van de Graaff Lab
(march@ohstpy.mps.ohio-state.edu)
Newsgroups: comp.os.vms
From: glippert@dale.cts.com (George Lippert)
Subject: Re: VAX c
Organization: Titan Linkabit Corporation
X-Newsreader: TIN [version 1.1 PL6]
Date: Fri, 25 Dec 1992 09:30:11 GMT

Ehud Gavron 602-570-2000 x. 2546 (gavron@spades.aces.com) wrote:
> In article <1992Dec24.173709.16437@mailer.cc.fsu.edu>, cliff@evax9.eng.fsu.edu writes...
> >Is there a way to get VAX C to flush the VMS file buffers? 
>
> 	fflush(stream)

Not according to DEC Support.  After trying this, and having it clearly not
work, DEC Support confirmed that fflush() only flushes to the RMS buffers -
NOT to the actual device.

So how do I make sure that the buffer gets onto disk? (in my case), I asked.
They told me that there is an "unsupported and undocumented" function that I
could call.  Thanks, but no thanks, I said.

--
George A. Lippert           work:          glippert@dale.cts.com
Titan Satellite Systems     home: zucchini!glippert@dale.cts.com (NeXTmail ok)
San Diego, CA                                            
------------------------------------------------------------------------------
From: SABRY@SHEBIN.EG (Sabry Kotob El-Ganzory)
Newsgroups: comp.os.vms
Subject: SUBSRIBE INFO-VAX
Date: 21 Dec 92 13:09:00 GMT
Organization: The Internet

"SUBSCRIBE INFO-VAX" SABRY KOTOB
From: 00mjstum@leo.bsuvc.bsu.edu (Matthew J. Stum)
Newsgroups: comp.os.vms
Subject: MAIL problem (NOT newmail count :)
Date: 30 Dec 92 17:29:48 GMT
Organization: Widget Enterprises


Hey, I have a MAIL question, and it doesn't involve the NEWMAIL count.. :-)

Anyway, it's nothing tragic, but I've been wondering for a long time now
why we end up with a lot of MAIL.LIS files in our [SYSLOST] directories.
Here's my assumption based on what little detective work I've been
motivated to do:  The MAIL.LIS files are temporary files used when PRINTing
from MAIL... however, for some reason the MAIL.LIS file doesn't get deleted
properly.  More like a SET FILE/REMOVE thing.

The problem arises that we have quotas enabled on our user disks and it
wreaks havoc with a user if (s)he prints a lot from MAIL.

Is this normal?  Or do we have something set up strangely?  Is there
another way around it besides routinely cleaning the [SYSLOST] directories
of MAIL.LIS files?

Hmmm... now that I think of it, I don't use PRINT/DELETE a whole lot... is
this something connected with the queueing system and not MAIL?  I don't
see anything about PRINT in the docs that would nail it down one way or
another.

Thanx...

-- 
Matt Stum                    Gwydion ap Myrddin       Ball State University
00mjstum@leo.bsuvc.bsu.edu   Shire of Afonlyn, MK     Muncie, IN  USA
Xref: sparky comp.os.vms:20108 comp.sys.dec:6654
From: gwi@icf.hrb.com (Gregory W. Isett)
Newsgroups: comp.os.vms,comp.sys.dec
Subject: DEClaser 1152 attached to Sparcstation?
Date: 30 Dec 92 16:31:11 EST
Organization: HRB Systems, Inc.

We recently purchased a DEClaser 1152 PostScript printer.  We're trying to
hook it up to a Sun Sparcstation via a serial connection.  When we send a file
to it, the display on the printer says "Processing", but no output is produced.

DEC only supports it under Ultrix.  They use and proprietary input and output
filter to lpr to make it work (which they will probably sell to use for many
$$)

Has anyone gottten this to work under SunOS?

-------------------------------------------------------------------------------
Greg Isett				Internet: gwi@icf.hrb.com
HRB Systems				FAX	: (814)234-7720
300 Science Park Road			Voice	: (814)238-4311
State College, Pa. USA 16804-0060
-------------------------------------------------------------------------------
From: gloesener@ISTVAX.IST.LU
Newsgroups: comp.os.vms
Subject: Disable proxies with LPD under UCX 2.0
Date: 21 Dec 92 09:23:51 GMT
Organization: The Internet


Hi,

I've installed UCX 2.0 last week and tried the LPD for use with a SUN station.
Every time when the SUN wants to print UCX complains about a missing proxy
for the user which want to print. Now I want to setup LPD to be accessible
for any user on that machine. I've tried to eliminate the PROXY flag from
the service with 'SET SERVICE LPD/FLAGS=NOPROXY' after enabling the LPD,
the flag had disappeared but it is still complaining about missing proxies.
Can anybody help me here ?

                                                Thank you very much

                                                 Gasty Gloesener

-GG-
From: FZC@CU.NIH.GOV ("Can't we stop, hurting each other")
Newsgroups: comp.os.vms
Subject: [TDR] Who'll Stop the Flames?
Date: 29 Dec 92 06:29:35 GMT
Reply-To: TDARCOS@MCIMAIL.COM
Distribution: world
Organization: The Internet

I would like to see the flaming on Info-Vax to stop.
Additional information will be posted later.


Newsgroups: comp.os.vms
From: welchb@woods.ulowell.edu
Subject: Re: Using SEARCH on HELP...
Organization: University of Lowell
Date: Mon, 28 Dec 1992 16:43:41 GMT

I asked the same question a few months ago, and obtained here a
terrific LIBSEARCH utility.  As suggested, I made it more specific by
defining the command APROPOS; it sometimes gives you more output that
you really bargained for, but its search automatically runs through the
help library; no need to extract, search, delete separately.
Also, APROPOS works like the unix command, only better IMHO.
-- 
Brendan Welch, UMass/Lowell, W1LPG,  welchb@woods.ulowell.edu