HDTenEightyP/NetNews huggingface dataset:
From: weissborn@dfwdsr.SINet.SLB.COM
Newsgroups: comp.os.vms
Subject: RE: REALLY  MIXED INTERCONNECT CLUSTER STUMPER
Date: 16 Apr 92 01:37:55 GMT
Organization: The Internet

Welllll, I am almost ashamed to admit that I finally discovered the problem to
my query about why my satellite-nodes would not boot.

It seems that the 4300's original MSCP_SERVE_ALL param had been set to 2 in 
sysgen but was set to 1 in MODPARAMS.DAT.  So, when the 5.5 upgrade completed
and the system was rebooted it was trying to serve the HSC-40's disks, which
included the system disk.  Apparently, the satellites did not like this for
booting purposes.

Finally deduced the problem by attempting a conversational boot and seeing, in 
the blink of an eye, that it was trying to access the 4300.

Thanks for all those who responded, however.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Bill Weissborn                              
Schlumberger Well Services
Data Services Region -- System Support Staff Engineer
12770 Coit Rd.  Suite 200                   weissborn%dfwvx1@hub.sinet.slb.com
Dallas, Tx.   75251                 or try: weissborn%ntchcs@hub.sinet.slb.com
(214) 980-7924

"I got to play baseball...I got a chance to hit..."   Ted Williams
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
From: jeh@cmkrnl.com
Newsgroups: comp.os.vms
Subject: Re: VIRTUALPAGECNT -- Memory Management Issue
Date: 7 Apr 92 22:20:20 GMT
Distribution: usa
Organization: Kernel Mode Consulting, San Diego CA

In article <1992Apr6.164705.20266@e2big.mko.dec.com>, winalski@tle.enet.dec.com (Paul S. Winalski) writes:
> 
> In article <1992Apr5.142101.403@cmkrnl.com>, jeh@cmkrnl.com writes:
> |>
> |>There seems to be an assumption here that the linker has to co-exist in virtual
> |>address space with the program to be linked.  This isn't the case.  
> 
> Actually, it is the case.  The Linker builds the image in its (the Linker's)
> virtual address space.  To link an image, the Linker must have enough
> virtual address space available to hold all of the statically-allocated
> virtual memory of the image being linked, plus enough room for the Linker
> itself, its data structures, and VMS process overhead (RMS, CLI, and whatnot).

But not including the program's dynamically-allocated storage, nor the
virtual address space needed by shareable images which the image being linked
references.  This makes the v.a.s. required by the linker to map the image
*considerably* smaller than the image itself.  No? 

But, yes, I had assumed that the linker did most of its work on disk... I 
sit corrected.  

> However, when an image is run, the Linker doesn't have to (and won't) be
> there.
> 
> --PSW

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
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: comp.os.vms
From: mchenry@BAEPV2.NCSU.EDU (MCHENRY@BAE.NCSU.EDU)
Subject: Problems with MOTIF DECwindows
Reply-To: mchenry@BAEPV2.NCSU.EDU (MCHENRY@BAE.NCSU.EDU)
Organization: North Carolina State University
Date: Thu, 16 Apr 1992 19:57:47 GMT



16-APR-1992 15:46:12.46
 

Hello:

Since "upgrading" from standard DECwindows to MOTIF Decwindows we've
had some problems which we can find no answer. The biggest problem is
with VMS SAS. When bringing up SAS, windows at first appear to
be normal size then they get chopped so that the width is almost 
unusable. Resizing and/or moving the window does not help. One 
user says that if you "play around" with it enough you get size
the windows where you can use them. That obviously is not an acceptable
solution. This problem appears to affect all VMS SAS users whether they
are using X-terms,workstations or PCs. All of these users were running
VMS SAS without any problems on Standard DECwindows before we made
the change. Does this sound familiar to anyone?

We are running VMS 5.4-3 on a 5 node local area cluster and have
MOTIF DECwindows V1.0A .

                                                   Thanks in Advance

                                                   Kevin McHenry
                                                   NCSU BAE
                                                   mchenry@bae.ncsu.edu
From: WEISE@bscf.uga.edu (MICHAEL WEISE)
Newsgroups: comp.os.vms
Subject: VPA dies periodically.  Anyone know why?
Date: 16 Apr 92 14:03:59 GMT
Organization: University of Georgia, USA
X-News-Reader: VMS NEWS 1.20


	We initially installed VPA (VAX Performance Advisor) about 9 month ago
and it worked without a hitch intil we upgraded from VMS 5.4-2 to -3 on our
LAVc.  (VPA was re-installed after the upgrade.)  Now, it starts and runs fine
but it then dies after any random amount of time.  This happens to the
processes running on both a VAX6210 and a VAXstation 3100 Model 30.

	Has anyone had similar problems?  Better still, has anyone who's had the
problem know why it happens and how to fix it?  Such info would not only
benefit our Facility but our local VMS support people and the manager of
another system as well.

	Thanks in advance,

		MJW

   _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
 / Michael J. Weise, Ph.D.    \  Univ.of Ga. BioScience Computing Facility \
(   weise@bscf.uga.edu         \   Dept.of Genetics  UGa, Athens  GA  30602 )
 \ _ _ _'Tis_only_me_speak'n._ _\_ _ _ _ _ _ _ (404) 542-1409_ _ _ _ _ _ _ /
From: MAHAN@GRUBNIK.TGV.COM
Newsgroups: comp.os.vms
Subject: Re: DECwindows screen blanker
Date: 6 Apr 92 20:27:22 GMT
Organization: The Internet

In article <1992Apr6.112057.31@wums.wustl.edu> you write:
#
#How does one unblank the screen after the screen saver has blanked it? As
#I interpret the FM, XResetScreenSaver should do the trick, but it doesn't
#work for me. Neither does XForceScreenSaver or XSetScreenSaver. What am I
#missing? I am running VMS V5.4 DECwindows on a VAXstation 2000.
#

Have you tried XForceScreenSaver(dpy, ScreenSaverReset).  If the screen
saver is active it should cause the screen saver to quit (just as if you
had moved the mouse or hit a key).  Also try XResetScreenSaver(dpy).

Patrick L. Mahan

--- TGV Window Washer ------------------------------- Mahan@TGV.COM ---------

Waking a person unnecessarily should not be considered  - Lazarus Long
a capital crime.  For a first offense, that is            From the Notebooks of
							  Lazarus Long
--
Patrick L. Mahan

--- TGV Window Washer ------------------------------- Mahan@TGV.COM ---------

Waking a person unnecessarily should not be considered  - Lazarus Long
a capital crime.  For a first offense, that is            From the Notebooks of
							  Lazarus Long
Newsgroups: comp.os.vms
From: rod@rod.cc.iastate.edu (R Eldridge, VMS FOREVER)
Subject: Re: UCX 1.3/VMS 5.5 quota problem?
Reply-To: rod@rod.cc.iastate.edu
Organization: Iowa State University, Ames, Iowa
Date: Wed, 8 Apr 1992 19:05:42 GMT

In article <7APR199215020732@mivax.mc.duke.edu>, mark@mivax.mc.duke.edu (MARK) writes:
>
>[ ...text deleted... ]
>
>I am now seeing the following message on the operator's console when a 
>network user attempts to login to the VAX using TELNET:
>
>Message from user INTERnet on VAX
>INTERnet ACP Remote TTY Request Aborted Status = "SYSTEM-F_EXQUOTA"
>
>[ ...text deleted... ]
>
>I am interested in figuring out what quota is being exceeded and what process
>is exceeding it - the user TELNETing in or the host system UCX software?
>
>[ ...text deleted... ]
>Thanks.

The quotas that are exceeded are UCX internal quotas. Initially, UCX
sets TCP_QUOTA=4096 and UDP_QUOTA=9000. To start off, change these to:

	$ UCX SET COMMUNICATION/TCP_QUOTA=8192
	$ UCX SET COMMUNICATION/UDP_QUOTA=18000

If you continue to see the "SYSTEM-F-EXQUOTA" message on the console,
continue to increate TCP_QUOTA by multiples of 4096 and UDP_QUOTA by
multiples of 9000.

The other errors that your users might get, are "INSUFFICIENT DYNAMIC MEMORY"
while trying to TELNET or FTP out or "INSUFFICIENT RESOURCES" [not the
exact error message, but I can't remember it exactly, since I don't get
these errors anymore] while trying to TELNET or FTP in. To correct these
errors, change these UCX values:

	$ UCX SET COMMUNICATION/LARGE=MAX=330
	$ UCX SET COMMUNICATION/SMALL=MAX=990

Execute the command "UCX SHOW COMMUNICATION/MEMORY" and check that
"Large Waits", "Large Drops", "Small Waits" and "Small Drops" are all
zero. If they are not zero, increase the appropriate UCX value as above.

Then, in all cases that you have changed any UCX value, after some time
has pasted, check whether the SYSGEN values of SPR, IPR and LPR need to
be increased by using the command: "SHOW MEMORY/POOL/FULL". The "Current
Total Size" should be equal to or less than the "Initial Size" for each
of theses. Also check to see if "Nonpaged Dynamic Memory" needs to be
increased (i.e. "Current Size" should be equal to or less then "Initial
SIze"). If any of the SYSGEN values need to be increased, edit
SYS$SYSTEM:MODPARAMS.DAT, run AUTOGEN and reboot.

The last thing you need to check is the RUN SYS$SYSTEM:UCX$INETACP.EXE
/BUFFER_LIMIT qualifier in the SYS$MANAGER:UCX$INET_STARTUP.COM. See this
file for instructions on calculating a new value.

When you get to the correct values for your system, remember to include
these changes in SYS$MANGER:UCX$INET_SET_INTERFACES.COM so that the next
time UCX starts, these values will be set. All the UCX values mentioned
above are dynamic, so you don't need to restart UCX after you have
changed these values.


rod eldridge             gvrod@isuvax.bitnet -or-
iowa state university    gvrod@isuvax.iastate.edu
(515) 294-7498           fax: (515) 294-7498
From: MAHAN@GRUBNIK.TGV.COM
Newsgroups: comp.os.vms
Subject: Re: DISPLAYing SUN olwm on VAXstation 3100 running CMU/tek...help!
Date: 14 Apr 92 20:55:10 GMT
Distribution: world
Organization: The Internet

In article <1992Apr11.195812.27718@slcs.slb.com> you write:
#
#Seems to me it should be
#decw$server_transports == "DECNET,LOCAL,CMU"
#
#TCPIP is the name reserved by DEC for the UCX product, even though the CMU
#software speaks TCP/IP.
#

TCPIP is not reserved by DEC.  The name used in the DECW$SERVER_TRANSPORTS
is used to locate the image

	SYS$SHARE:DECW$TRANSPORT_<transport_name>.EXE

This allows anyone (as of VMS 5.3) to write their own transport for DECwindows.
The idea is that if you write TCP/IP transport for DECwindows then you should
call it TCPIP not something else.

--
Patrick L. Mahan

--- TGV Window Washer ------------------------------- Mahan@TGV.COM ---------

Waking a person unnecessarily should not be considered  - Lazarus Long
a capital crime.  For a first offense, that is            From the Notebooks of
							  Lazarus Long
From: SYSMGR@IPG.PH.KCL.AC.UK
Newsgroups: comp.os.vms
Subject: re: How to make a disk unbootable
Date: 14 Apr 92 11:26:50 GMT
Distribution: world
Organization: The Internet

>>  Problem  : Had VMS 5.3 running on DUA3. Built VMS 5.5 on DUB5. Now when
>>             I do a "b" to boot I always boot from DUA3. I want to keep
>>             DUA3 around for a while so I can't take it offline.
>>
>>  Question : How do I make DUA3 "unbootable"? I spent all morning with
>>             TFM and could only find out how to make it bootable.
>>
>
> The simple answer is, you can't unless you delete/rename the system
> directories. The Boot ROM in the MVII searches for a bootable system on
> removable disk devices, then non-removable, then tape, then PROM. It always
> searches in ascending controller/unit order so will find a bootable DUA3 before
> it finds DUB5.
>
> You can force a boot from DUB5 by typing "B DUB5" and the console prompt
> (">>>")  but any automatic reboot will go to DUA3 unless you delete/rename the
> directories DUA3:[000000]SYS0.DIR and DUA3:[000000]SYSEXE.DIR. This, of course,
> renders it *totally* unbootable. You can't then do "B DUA3".
                ^No!
Almost correct but very misleading. If you rename DUA3:[000000]SYS0.DIR
to (say) SYSD.DIR, the disk remains bootable but you have to explicitly tell
the system to boot from SYSD and not the default SYS0. That is done by
passing the system root digit in R5 most significant nibble to SYSBOOT. 
On a microVAX-II it's either one or the other of the following 
(can't remember which)

>>> B/D0000000 DUA3          or         B/R5=D0000000 DUA3

If you simply type >>> B the 'sniffer' will look for SYS0 and find it on DUA5
as required. 

		Nigel Arnot

		NRA%ipg.ph.kcl.ac.uk@nsfnet-relay.ac.uk   (internet)
		NRA%uk.ac.kcl.ph.ipg@ukacrl.bitnet        (bitnet)
		NRA%ipg.ph.kcl.ac.uk@cunyvm.cuny.edu
		etc...
From: harvey@indyvax.iupui.edu
Newsgroups: comp.os.vms
Subject: Re: SUMMARY:How to SET FORWARD to multiple users
Date: 10 Apr 92 13:17:26 -0500

In article <1992Apr9.165641.4030@news.arc.nasa.gov>, mcmahon@tgv.com (John 'Fast-Eddie' McMahon) writes:
>
> In article <1992Apr8.122955.1@gz.alcbel.be>, tsd72@gz.alcbel.be (Werner Lemaire) writes:
> #	How to SET FORWARD to multiple users in VMSmail?
> #
> #1. You can use the command
> #	SET FORWARD IN%"""user1@place1,user2@place2"""
> #   The addressees have to be in internet format and the triple quotes are
> #   necessary.
>
> This works fine if you are running the PMDF mail package.  Vanilla VMSmail does
> not have this capability, and does not understand IN%

And if you are trying to setup a mailing list, there are better ways to use
PMDF to do this.  See the stuff on alias files and mailing lists in the PMDF
System Manager's Guide.
--
James Harvey
harvey@iupui.edu or harvey@indiana.edu
From: mullens@jamsun.ic.ornl.gov (James A. Mullens)
Newsgroups: comp.os.vms
Subject: C & shared file & fseek & !RMS
Keywords: C
Date: 13 Apr 92 17:55:04 GMT
Article-I.D.: ornl.1992Apr13.175504.10785
Organization: ORNL

Hi, this is a question for experienced users of file i/o under C.  

I need a file format and access mode which allows:
   1: seeks to any file position (actually, record) up to the end of file,
   2: sharing between a writer/reader process and a reader process.

The file will contain binary data with a fixed (record) size.

According to the VMS manuals:
   3: shared files must have a record format (footnote for creat
      function, table of optional file attributes),
   4: the VAX C RTL functions can only access sequential file
      organization (intro to C RTL, Chapter 1); I don't think this
      causes a problem for me, it only means the file must be a sequence
      of records (no unused records).

So I think I need a fopen (or open) which specifies:
   ctx = rec (force record-mode access to allow sharing; I assume the
         file will be sequential records),
   mrs = <my record size>,
   rat = <null> (i.e., don't specify a record attribute since data is binary),
   rfm = fix (fixed length record format),
   shr = get,put (all readers specify get,put and writer specifies get)

But, with *record format* files an fseek (fsetpos) must be to a location
returned by ftell (fgetpos); otherwise "unpredictable behavior" occurs
(description of ftell function).  What I'd like to avoid is keeping a ftell
(fgetpos) value for every record in my file.  I'd like to have a fseek
function which simply takes a record number instead of an ftell return value.
A relative or absolute record number would be OK.  This being impossible,
what are my alternatives (surely someone has done this...)?

I guess I should say I also want to avoid direct calls to the RMS functions,
but that's only because I want to keep the program simple for the eventual
maintainers of the code.  I could be persuaded to make their lives more
miserable (if that's possible...) by dropping in some RMS stuff, but I'm
fearful they'll put a curse on my children :-).

jim mullens
mullens@jamsun.ic.ornl.gov (128.219.64.31)
From: yoshi@nocusuhs.nnmc.navy.mil (D M Yoshikami)
Newsgroups: comp.os.vms
Subject: Re: INSTALL and "<>"s...
Date: 15 Apr 92 12:34:22 GMT
Organization: National Naval Medical Center

In article <6E81AB77E6FF20778C@MAX.U.WASHINGTON.EDU> DEREK@U.WASHINGTON.EDU writes:
>I would say not, as INSTALL *used* to use the square brackets.  It seems to
>me that this changed back in version 4 of VMS, but it might have been V5.0.
>Angle brackets have always been supported by RMS, I thought for backwards
>compatibility with the pre-VMS operating systems.
                        ^^^^^^^
If my memory serves me correctly, TOPS-20 used angles brackets regularly
and also had file version numbers.  Instead of using a ';', they just used
another '.' instead.  In fact, RMS will take what looks like a tops-20
filename, <directory>file.ext.1 for instance.  (I sometimes use the dot 
if I'm lazy with typing).  TOPS-20 also would not really delete files until
you either logged out or told it to flush (I forget the command) as you could
"undelete" files until they were "really" deleted.

> (Similary, one can
>reference directories named "[xxxyyy]", where xxx and yyy represent octal
>digits, as "[xxx,yyy]" excluding leading zeros.  Thus, "[0,0]" is the same
>as "[000000]".  (There might be cases where software doesn't deal with this
>correctly when found in a rooted device specification, though.)

This last bitty came from the old files-11 level 1 type format which RMS
grew up on -- namely an operating system called RSX-11M of which I spent many
hours programming on in my halcyon days.  Files-11 level 2 of course, we use
on VAX/VMS.

DY :-)

=-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
D M Yoshikami  :-) ;-) :-) | Internet: yoshikami@usuhsb.ucc.usuhs.nnmc.navy.mil
May the Forth be with you! | Bitnet  : yoshikami@usuhsb.bitnet
***  !!xob X*NU V METSYS T&TA eht ni renosirp dleh gnieb m`I  !pleH  !pleH  ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Newsgroups: comp.os.vms
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Subject: Re: How to pick up single keystrokes in DCL
Reply-To: carl@SOL1.GPS.CALTECH.EDU
Organization: HST Wide Field/Planetary Camera
Date: Wed, 15 Apr 1992 22:00:27 GMT

In article <9204150845.utk17067@INTEL9.intel.com>, AHARDISON@INTEL9.intel.com ("SUCCESS IS 99% PERSPERATION, 50% INSPIRATION") writes:
>Hello all!
>
>	I have a problem that I hope someone out there can solve, or atleast 
>point me in the right direction.  I need to know how to read single keystrokes 
>in the DCL script.  A friend of mine is writing a program that would be 
>greatly simplified if we knew this.  Thank you in advance

You can't do it via DCL.  You need to write a program that does that, then run
the program (unless, of course, the single keystroke is a line terminator :-).
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXes 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.
Newsgroups: comp.os.vms
From: goathunter@wkuvx1.bitnet
Newsgroups: comp.os.vms,vmsnet.sources.d
Subject: WKUVX1 pipe clogged *again*!  Patience requested....
Date: 10 Apr 92 12:34:04 GMT
Organization: Western Kentucky University, Bowling Green, KY

Once again, the WKUVX1 BITNET link is clogged.  There are some 250
files queued up waiting to go out; please be patient if you've ordered
something.  I suspect the queue will clear by Monday (I hope).

To reiterate, the Supervisor Series is available via anonymous ftp
from ftp.spc.edu in [.MACRO32.SAVESETS]SUPERVISOR.BCK_Z.

Also, it will be posted to vmsnet.sources before too long....

Thanks for your patience again....

Hunter
------
Hunter Goatley, VMS Systems Programmer, Western Kentucky University
goathunter@WKUVX1.BITNET, 502-745-5251
From: DWING@UH01.Colorado.EDU (Dan Wing)
Newsgroups: comp.os.vms
Subject: Re: How to tell DIALUP from DCL?
Date: 16 Apr 92 15:08:44 GMT
Organization: The Internet

Jason Haar, no return address, writes:

>Can you figure out whether an account has dialup access from the command-line
>(e.g. via lexicals)?

You need to define "has dialup access" better - do you mean "they are allowed
to dial into the computer" (as setup for that username in the SYSUAF), or 
that "they have dialed into the computer."

>The story is, we want to move our modems off our VAX onto a terminal server -
>but we want to still use the DIALUP access bit in the UAF to decide whether to
>let the user actually log in. What we'd do is get SYLOGIN to check to see if
>the terminal server is the modem one, and then see if the user has DIALUP
>access. I realise we could create an Identifier to do this with - but it would
>require extra work ;-))

This will tell you that they dialed into the computer:

F$GETDVI("SYS$COMMAND","TT_DIALUP")
 
you must setup your DECserver ports with DEFINE PORT nn DIALUP ENABLE

If you're really just trying to prevent users from dialing into your system,
the best way is to disable dialup access in the SYSUAF - they do get a pretty 
cryptic message, though.

The GETUAI program (mentioned by another poster) will tell you if the user
is allowed dialup access.

-Dan Wing, DWING@UH01.Colorado.EDU  (or WING_D@UCOLMCC.BITNET)
 Systems Programmer, University Hospital, Denver
Xref: sparky comp.os.vms:8116 vmsnet.sources.d:302 vmsnet.internals:685
From: goathunter@wkuvx1.bitnet
Newsgroups: comp.os.vms,vmsnet.sources.d,vmsnet.internals
Subject: Supervisor Series Installation Notes (sorry)
Date: 9 Apr 92 18:03:30 GMT
Article-I.D.: wkuvx1.1992Apr9.130330.1286
Organization: Western Kentucky University, Bowling Green, KY

A few gotchas about installing the Supervisor Series v5.1 (I *knew*
something would pop up):

  1.  The ADVISE command conflicts with VPA's ADVISE.  If you have
      VPA, *don't* add the ADVISE/OBSERVE commands to DCLTABLES.

      Notice that the default is NO for installing them in DCLTABLES.
      I recommend that you define foreign symbols for it.

  2.  The OBSERVE CLD file (OBSADV.CLD) has a type: the image name
      given is OBSERVE.EXE; it should be OBSERVER.EXE.  You can either
      rename the image to OBSERVE, or, better, modify the .CLD file
      (SUPSER_ROOT:[EXE]OBSADV.CLD) and re-SET COMMAND it to replace
      it in DCLTABLES.EXE.

  3.  The /QUIET option requires that SECURITY privilege be an
      *authorized* privilege, not just a default.  I didn't notice
      this until last night.  I will be changing it to either check
      for a default privilege or use an identifier for /QUIET.

  4.  When installing, do not use a concealed logical name for the
      device name.  I'd recommend just always using the *real* device
      name (DUA0:[SUPSER], for example).  Something like
      SYS$SYSROOT:[SUPSER] will cause the installation to fail.

Sorry for the hassles.  I'll be correcting all of these things in the
next release (either v5.2 or a sub-release of v5.1).

Hunter
------
Hunter Goatley, VMS Systems Programmer, Western Kentucky University
goathunter@WKUVX1.BITNET, 502-745-5251