HDTenEightyP/NetNews huggingface dataset:
From: ACSMARTIN@EKU.BITNET ("Bob Martin --> Acsmartin@eku.bitnet")
Newsgroups: comp.os.vms
Subject: SLIP connection(s)??
Date: 1 Jan 93 13:20:49 GMT
Organization: The Internet

Folks,

I'd like to create a SLIP connection to our VAX 6610 which runs VMS
5.5-1, PMDF 4.1, and MultiNet (I forget the version). We also have some
9600 baud modems with bis 32 & 42. We also have most of the internet
stuff in place with the exception of 1 piece of hardware that'll be
plugged in quite shortly; therefore we'll be an Internet & Bitnet site.

It may not be obvious, but I'd like to do this from home with a similar
modem as described above. Actually, I'd rather run some fiber from my
house to our ISN and buy an ethernet card, but thats a bit unrealistic.
:)

I had some info on SLIP connections a year or two ago and really don't
recall what I did with it. I'd appreciate a quick refresher or some
suggestions, whatever. BTW, I use Kermit 3.12 as my communications
program and DOS 5.0 as the OS on a 486.

Thanks,

-Bob Martin -- acsmartin@eku.bitnet
From: FZC@CU.NIH.GOV ("Always Something There to Remind Me")
Newsgroups: comp.os.vms
Subject: How To Subscribe to Info-Vax
Date: 23 Dec 92 02:53:37 GMT
Distribution: world
Organization: The Internet

As a note, if someone wants to subscribe to
Info-Vax, they must send a request to a server
such as LISTSERV.

You should not send a message to the Info-Vax list
directly, as all 750,000 readers get it, and you
{still} will not be subscribed to the list.

To be subscribed to the list, YOU PERSONALLY MUST
send a message directly to the server.  Send a message
to the following address:

  LISTSERV@PUCC.PRINCETON.EDU

Subject isn't important.  As the first line of the
message put in

SUBSCRIBE INFO-VAX Firstname Lastname

(Change 'Firstname' and 'Lastname' to yours, of course.)

The Princeton Listserv will forward the request onto
the nearest listserv that handles INFO-VAX.
From: cd382@cleveland.Freenet.Edu (Jim Walker)
Newsgroups: comp.os.vms
Subject: re: MAIL problem (NOT newmail count :)
Date: 1 Jan 1993 12:43:40 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: cd382@cleveland.Freenet.Edu (Jim Walker)
NNTP-Posting-Host: hela.ins.cwru.edu


In a previous article, nreadwin@micrognosis.co.uk (Neil Readwin) says:

>A couple of people have explained about the lost MAIL.LIS files being
>created for print jobs from MAIL ... does anyone know a reason why lost
>MAIL.TXT files get created? We get large numbers of these on our system
>disk. They are almost always zero length and all the ones I can find at
>the moment are owned by the MAIL$SERVER account (which is used for
>incoming DECnet mail access). Neil.
>-- 
> Phone: +44 71 815 5283  E-mail: nreadwin@micrognosis.co.uk
> Anything is a cause for sorrow that my mind or body has made
>
The MAIL_SERVER stores incomming messages in a scratch file before
delivery.  The file is called MAIL.TXT, and like MAIL.LIS is not
stored in a directory.  The file is supposed to be deleted when
it is no longer needed, but if MAIL_SERVER aborts sometimes it isn't.
You might check the NETSERVER.LOG files in MAIL$SERVER's login
directory for error messages.

Jim Walker
Glad it's not the newmail count.
Newsgroups: comp.os.vms
From: lionel@quark.enet.dec.com (Steve Lionel)
Subject: Re: Request for sources
Organization: Digital Equipment Corporation
Date: Mon, 28 Dec 1992 02:40:35 GMT


In article <23DEC199208315478@spades.aces.com>, gavron@spades.aces.com 
(Ehud Gavron 602-570-2000 x. 2546) writes...
>In article <9212230626.AA09743@ucbvax.Berkeley.EDU>, FZC@CU.NIH.GOV ("Kevin Mitnick") writes...
>#Can someone E-Mail me the sources to VMS?
># 
>#Thanks, Kevin
> 
>	Yes, you need to contact by email olson@star.enet.dec.com.
>	If he won't try palmer@star.enet.dec.com.
> 

Nah, first of all, it would be "olsen", not "olson", but it's a common
mistake.  Second, there may be a palmer on star, but it's not our
illustrious Prez.  But third, I thought Kevin already had the sources;
if he wants an update, he can subscribe to the service just like anyone
else. :-)

P.S.  Some of the readers here don't seem to have picked up that the
original posting was a joke.  But then again, people fell for the "kremvax"
posting...

Steve Lionel                    lionel@quark.enet.dec.com
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
Newsgroups: comp.os.vms,vmsnet.tpu
From: blanchad@rintintin.Colorado.EDU (BLANCHARD DAVID OWEN)
Subject: Re: Help on "simple" EVE/TPU procedure
Organization: University of Colorado, Boulder
Date: Tue, 22 Dec 1992 15:54:56 GMT

In article <1992Dec21.184230.14735@miavx1.acs.muohio.edu> kacovert@miavx1.acs.muohio.edu (Kent Covert) writes:
>
>Probably the easiest way to do this is to use the box commands within TPU.
...
>Then just highlight the column you wish to delete using select.  The 
>selection should be in bold rather than inverse video.  The selection 
>also looks like it's selecting lines, but trust me, it'll work (BTW, 
>why doesn't box selects highlight boxes rather than lines - this doesn't 
>make sense to me.)  Then issue the cut command.

One of the reasons I never updated to the built-in box commands was this
"feature".

I have been using EVEPlus for years - EVEPlus was issued soon after
TPU V1.  Many of the good features were incorporated into TPU V2.  The
original rectangular box features, IMHO, are better in EVEPlus than in
TPU V2.  In EVEPlus, the boxed are is in reverse video and ONLY the
box is highlighted.

David Blanchard
dob@nssl.erl.gov

-- 
+--------------------------------------------------------------------------+
| David O. Blanchard	Boulder, Colorado	dob@nssl.erl.gov           |
+--------------------------------------------------------------------------+
Newsgroups: comp.os.vms
From: rkoehler@author.gsfc.nasa.gov (BOB KOEHLER)
Subject: Re: Backup question
News-Software: VAX/VMS VNEWS 1.4-b1  
Organization: CSC System Sciences Division
Date: Tue, 29 Dec 1992 14:38:00 GMT

In article <29846@castle.ed.ac.uk>, ercn50@castle.ed.ac.uk (Lifesupport) writes...
>Hi All - Seasons Greetings !! - can someone/anyone help with the
>following ? - any HELP much appreciated ...
> 
>------------ forward message -------------------------------------------
>                 I have a situation whereby a user has identified a loss
>of data on a magtape (the magnetic tape should contain data going back
>quite some time but the savesets on the tape only go back a few months).
> 
>I can only assume that the tape had been initialised at some stage this
>is reinforced by the fact that the first saveset on the tape is not the
>start of a saveset.
> 
>What I think has happened is that a backup to tape requested mounting a
>second (relative) volume and by mistake the same volume was loaded hence
>causing the tape to be initialized and this would explain the fact that the
>first saveset on the tape is not the beginning of the saveset.
> 
>My question  is how can I recover data from the initialized tape ...
>------------  end forward message ----------------------------------------
> 
>Kenny Stevenon
>Edinburgh University Computing Service

  You need to verify that there is any old data on the tape, and then try to 
get it off.  Using QIO (IO$_READVBLK function code) you can scan the tape, 
ignoring logical end of volume error other than to expect the next block will 
not be readable.  If the data has not already been overwritten, it will be out
there beyond the current logical end of volume.
  FYI, it has been my recent experience that some tape interfaces do not 
return the logical end of volume error, but instead one must watch for the 
double end of file "manually".
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: re: re: Re: HELP!!! Security problem for gurus. [Directories]
Date: 3 Jan 1993 10:07:11 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 <9301021337.AA28427@uu3.psi.com>, leichter@lrw.com (Jerry Leichter) writes:
=Seriously, I have a copy of the ODS-II spec - after all, I *did* work for DEC
=for 12 years!  It's not a particularly secret spec; I know other people have
=copies, probably more recent ones than mine.

I believe the book is titled _VMS_File_System_Internals, or something like
that.  You can actually go out and buy it these days.

=The easiest way to do it would be to create directories with an access-mode
=restriction allowing access only from executive (or kernel) modes.  When you
=get down to the bottom level, the only way to access a file is through a
=channel, and channels have associated access levels.  The rule for access-mode
=restricted files would be that the mode of the channel must be at least as
=privileged as the mode of the file.  User-mode code can only create user-mode
=channels, so would not be able to get to a directory file directly.  This
=might be enforced by the driver, or I suppose the concept of access-mode
=restrictions might be extended to cover all devices, in which case it would
=be enforced by the I/O system in conjunction with the disk drivers.

But remember that you can still get at it if you've got LOG_IO or PHYS_IO priv
and a copy of _VMS_File_System_Internals.
--------------------------------------------------------------------------------
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: caf@omen.UUCP (Chuck Forsberg)
Subject: Re: Omen technology Zmodem for VMS - help need with Installation.
Organization: Omen Technology INC, Portland Rain Forest
Date: Mon, 21 Dec 1992 13:38:47 GMT
Keywords: zmodem,rz,sz,vms

In article <1992Dec14.184928.2102@dmu.ac.uk> mjh@dmu.ac.uk (Mike Howarth) writes:
>Please - I am haveing trouble installing a copy of the Omen technology
>rzsz9103.
>
>The system I have a problem with is a VAXStation 2000 (no laughing please -
>she's a very sensitive little system !!!! :-) ) running MicroVMS V4.4.
>
>I recently downloaded the rzsz9103.TLB and .INF files and followed the
>instructions, however, both rz and sz appear to be trying to find another
>port to that which they are run on (currently _TTA2:).  The programs both
>just sit until timeout and then complain that the device is not installed !!
>Maybe I am doing something silly, or there is a simple symbol to set but I
>can't see it in the documentation.

There may be problems with VMS 4.4.  VMS rz/sz was originally compiled on
VMS 4.7.  Currently it is compiled on 5. something with the no-shared-libs
flag to allow operation on 4.7.

Otherwise I can only suggest you carefully check the .DOC files for any
useful nuggets of information buried therein.


-- 
Chuck Forsberg WA7KGX          ...!tektronix!reed!omen!caf 
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
  Omen Technology Inc    "The High Reliability Software"
17505-V NW Sauvie IS RD   Portland OR 97231   503-621-3406
Newsgroups: comp.os.vms
From: mike@jammin.nosc.mil (mike pawka)
Subject: Re: Request for sources
Organization: NRaD
Date: Thu, 24 Dec 1992 17:10:49 GMT

In article <9212230626.AA09743@ucbvax.Berkeley.EDU>, FZC@CU.NIH.GOV ("Kevin Mitnick") writes:
|> Can someone E-Mail me the sources to VMS?
|> 
|> Thanks, Kevin
|> 
|> 

	Hey, I wonder if this is the guy from "Cyberpunk"?

                                      mike pawka   systems programmer 
                                      NRaD San Diego mike@jammin.nosc.mil
                                      cool runnings mon!
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: Writeback Cache and other trivia
Date: 25 Dec 1992 06:32:01 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.142910.8966@slcs.slb.com>, brydon@asl.slb.com (Harvey Brydon (918)250-4312) writes:
=In article <1h9lpjINN1c9@gap.caltech.edu>, in an incredibly polite manner,
=carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
=>In article <1992Dec22.220607.8221@news.acns.nwu.edu>,
=>jweiss@casbah.acns.nwu.edu (Jerry Weiss) writes:
=>=During a regular test of my backup procedures (ie: my system crashed and
=>=when it came back up a few things didn't work ;-( )
=>
=>[generally good stuff deleted...]
=>
=>=Any there other files in VMS (not counting 3rd party software) that
=>=require special attention?
=>
=>For vanilla VMS, at least through v5.4-2, JBCSYSQUE.DAT is the only special
=>file, if you're concerned mostly about rebooting and having everything work
=>right.  If your real security-conscious, there are a couple of other files
=>(OPERATOR.LOG, and at least one AUDIT file) that you've got to worry about.
=
=You left out the ACCOUNTNG.DAT files.  These are never backed up to
=incremental backups because they are typically opened at boot time and never
=closed.  Since they are continuously open, you can't do the usual stuff with
=the file header (anything with "SET FILE", "SET PROT", etc.)  but you can mark
=them as modified by renaming them to themselves.  Give this a try.  It is
=directly from the incremental backup command procedure I use:
=
=$ set proc /priv=(sysprv,bypass)
=$ rename /log sys$sysdevice:[sys*.sysmgr]accountng.dat; *.*;*
=$ if f$search("sys$system:jbcsysque.dat") .nes. "" then -
=  rename /log sys$system:jbcsysque.dat;* *.*;*
=$
=$ backup /ignore=interlock ...

Mea culpa.  I'd forgotten about OPERATOR.LOG.  But if you REALLY want to
include that file, and don't want to use /IGNORE=INTERLOCK, then:
	$ SET PROC/PRIV=OPER
	$ DEF SYS$COMMAND _OPA0:
	$ REP/ENA
	$ REP/LOG
	$ DEAS SYS$COMMAND
	$ BACKUP ....
is a better idea.  If you don't want OPCOM messages to appear on the console,
then do a REPLY/DISABLE after the REP/LOG.
--------------------------------------------------------------------------------
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.
Newsgroups: comp.os.vms
From: mdchaney@fractal.ucs.indiana.edu (M Darrin Chaney)
Subject: $add_holder is slow...
Organization: Indiana University, Bloomington
Date: Wed, 30 Dec 1992 17:30:07 GMT

We've got about 40,000 users on our cluster, which consists of various newer
VAXen (the smallest being a 6500, I think).  Anyway, we still keep a separate
rightslist and uaf on each of the six nodes (I don't run these machines, so
don't blame me).

Recently, I set about rebuilding the rightslist for the cluster, in order to
get each node in sync again, and make sure that everybody has only what they
need.  We have 5 different rights, of which everybody has at least one.  They
are:

     UCS  -   people who work at UCS
     STAFF  - staff members
     FACULTY -faculty members
     GRAD  -  grad students
     UGRAD  - undergraduate students

It is possible for people to have more than one, for instance STAFF and UGRAD.

Anyway, we had a spare 8820 sitting around (VMS 5.5-2), so I'm using it.  It
has 384MB of memory, and we set up a huge cache on it.  We also made the
account that we are using have high quotas:

Maxjobs:         0  Fillm:       100  Bytlm:        50000
Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0
Maxdetach:       0  BIOlm:        50  JTquota:       1024
Prclm:           2  DIOlm:        50  WSdef:         2048
Prio:            4  ASTlm:        24  WSquo:        32768
Queprio:         0  TQElm:        10  WSextent:     65535
CPU:        (none)  Enqlm:      2000  Pgflquo:      40000

Anyway, I copid the rest of the identifiers into the new rightslist, of which
there were only a few thousand.  Then, I used the cluster UAF to create the
username rights (using add/ident/user=* in authorize).  I made 5 files, each
containing in "rightslist" format the UIC of each person who needed that
right, and the right itself.  So, each line was like such:

right,uic,attr

attr is always 0.  The program loops through the file, reading each line and
using $add_holder to add the holder.  Here's the layout:

UCS - 500 holders
STAFF- 4000 holders
FACULTY- 3000 holders
GRAD- 8400 holders
UGRAD- 30000 holders

The amount of time it takes to add these increases rather dramatically.  The
first 50 (of any set) take maybe 10 seconds.  After around 1000, it takes 10
or 15 minutes to do 50.  I figure it's because of RMS keeping track of all
the duplicate keys.  I have everything except UGRAD added, with about 16,000
left.  At the current rate (50 every 20 minutes), it'll take another 4 days.
It will probably slow down even more, though, so the time will be longer.

Does anyone know a way to speed this up?  Pretty much anything is possible
with the machine that we are using.  Thanks in advance.

	Darrin
-- 

mdchaney@iubacs mdchaney@bronze.ucs.indiana.edu mdchaney@rose.ucs.indiana.edu

"I want- I need- to live, to see it all..."
From: tihor@acf3.NYU.EDU (Stephen Tihor)
Newsgroups: comp.os.vms
Subject: Re: Need VMS Gopher Client
Date: 25 Dec 92 19:57:00 GMT
Organization: New York University

the gopher client seems to be missing the link file.
The Xgopher client seems to need the DEC C RTL rather than the
VAXCRTL (eg the ansi C stuff.)
From: simons/G=Colin/I=CB/S=Sewell/O=H.A.Simons.Ltd/OU=CORP@mhs.attmail.com
Newsgroups: comp.os.vms
Subject: Re: Warning.  XWATCH/SPY causes crash.
Date: 21 Dec 92 16:09:02 GMT
Distribution: world
Organization: The Internet

There is a WATCH5 program that came from a year old DECUS tape
that seemed to work fine until DEC introduced FT terminals.
Watching these types of terminals always seemed to crash the system.
My investigations showed that FT terminals use an extended
class vector table (or was it port?) and not all of the table
was being copied/saved/replaced. Increasing that fixed the problem.

However SUPERVISOR has much better functionality so we use that
now.
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: re: VAX c
Date: 30 Dec 1992 11:44:52 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 <9212282111.AA11260@uu3.psi.com>, leichter@lrw.com (Jerry Leichter) writes:
>
>	Is there a way to get VAX C to flush the VMS file buffers? 
>
>	I've got a program that reads data in for the tta2: port and then
>	writes it to a file. The problem is that the data doesn't get written
>	to the file until the buffer is full, and that may not happen but once
>	every day or two.
>
>Try the fsync() function.  Usage:  fsync(int fd).  Returns EBADF if fd is not
>a valid file descriptor.  (Note that you need a file DESCRIPTOR, not a file
>POINTER (FILE *); use fileno() to get the file descriptor from a file
>pointer.)  When fsync() returns, all pending changes should be on the disk.
>(In VMS, this really means that an RMS $FLUSH was executed.)
>
>Note that if you are accessing a file using the standard I/O package (i.e.,
>through a file pointer) you must first do an fflush() to get the data out to
>the "Unix I/O" level.

Under VMS v5.4-2 you have to do this even if you're using the UNIXIO routines.
Of course, you don't normally then have a file pointer handy.  What you have to
do in that case is:
	int fd;
	FILE *fp, fdopen();
	fp = fdopen(fd, "a");
	fflush(fp);
	fsync(fd);
or, if you're only going to do this once, I suppose you could:
	int fd;
	FILE *fdopen();
	fflush(fdopen(fd, "a"));
	fsync(fd);
Gawd, how I *HATE* UNIX!
--------------------------------------------------------------------------------
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: SHOECRAFT@MC.MARICOPA.EDU (Steve Shoecraft)
Newsgroups: comp.os.vms
Subject: Re: ACP-QIO to read QUOTA.SYS
Date: 3 Jan 93 05:32:18 GMT
Distribution: world
Organization: The Internet


Dave,

Ooops!  I forgot to finish the sentence on descriptors!  Well, after looking 
at the include file(since I don't have the manuals for it :), the DSC$K_CLASS 
is the descriptor class of the descriptor you are passing, i.e. This is a 
string descriptor, or this is an array descriptor, etc.  I'm sure you can get 
a better description elsewhere, but as I said in the previous posting, in this 
instance, the information is not required.

- Steve
SHOECRAFT@MC.MARICOPA.EDU
From: titus@dallas.sil.org
Newsgroups: comp.os.vms
Subject: How do I save DECterm printer info?
Date: 30 Dec 92 12:07:05 CST
Organization: Summer Institute of Linguistics, Dallas Center

  Anybody out there (DEC folks perhaps?) know how to save
printer info into the DECW$TERMINAL.DAT file?  I have set up
my desired default printer info and then done a save, but
this info doesn't appear in the file.
  If someone knows how to save this info, please let me know
via e-mail.  If it is something others, too, want, I'll be
glad to post the info here.
  If this is an FAQ, please forgive my ignorance and point
me to the correct source of info.

  Thanks

               * * * * * * * * * * * * * * * * *
Mike Titus, Programmer                  /\   Summer Institute
SIL                                    /  \        of
7500 West Camp Wisdom Road            /SIL \   Linguistics
Dallas, Texas  75236-5699            --------
U.S.A.
Voice    : (214) 709-2400             * Internet <titus@dallas.sil.org>
Facsimile: (214) 709-3387             * UUCP     ...utafil!txsil!dalsil!titus
Ham radio (not on packet yet) KB4ABZ  *

"I can do everything through Him who gives me strength."

      Philippians 4:13 (NIV)
From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
Newsgroups: comp.os.vms
Subject: Re: VAX-C SHELL$FIX_TIME and SHELL$MATCH_WILD
Date: 31 Dec 92 03:42:25 GMT
Distribution: comp
Organization: St. Peter's College, US

In article <SHIBUYA.92Dec30184615@chute.bl.applicon.slb.com>, shibuya@bl.applicon.slb.com (Hiroto Shibuya) writes:
> I was trying to port Todd Aven's VMS/MAKE v3.4 to Alpha and got the
> following undefined symbols at the link time.
> 
> 	SHELL$FIX_TIME
> 	SHELL$MATCH_WILD
> 
> According to the link map on VAX, they are pulled out from VAXCRTL,
> but apparently do not exist on Alpha's CRTL.  I looked up VAX-C manual
> but didn't find any documents on these guys.  Could somebody provide
> me of the spec of these routines so I can write replacement?

  They're from the DEC/Shell package, an early attempt at Unix compatibility
under VMS. Unfortunately I don't have any documentation for these routines
here. However, people have posted the info to comp.os.vms/Info-VAX in the
past, so perhaps now that you know they're DEC/Shell routines, the info will
be reposted.

	Terry Kennedy		Operations Manager, Academic Computing
	terry@spcvxa.bitnet	St. Peter's College, Jersey City, NJ USA
	terry@spcvxa.spc.edu	+1 201 915 9381