HDTenEightyP/NetNews huggingface dataset:
From: rice@ttd.teradyne.com
Subject: Re: HELP: how to stop and prevent break in?
Organization: Teradyne Inc., Telecommunications Division
Date: Sun, 15 Nov 92 03:54:38 GMT

In article <1dubr4INNd9g@gap.caltech.edu>, carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
> In article <69356@cup.portal.com>, Chris_F_Chiesa@cup.portal.com writes:
>>I believe you are merely seeing the file's ownership information expressed
>>as a Group and Member -- [GROUP,MEMBER] -- rather than as an Identifier --
>>[IDENT] .  And I further believe that this is caused by the absence of an
>>Identifier for the file's owner, in the system UAF.
> 
> What he's seeing is both the Group and the Member being expressed as
> identifiers.  The system manager has apparently entered a group identifier
> in SYS$SYSTEM:RIGHTSLIST.DAT. This is done with a command like:
> 	$ MCR AUTHORIZE ADD/ID/VAL=UIC=[group,*] identifier

It's not uncommon to see files with the owner field expressed in [ggg,mmm]
format when the original owner has been removed from sysuaf, and the UIC now
no longer exists. Not uncommon in an academic environment with a quarterly 
high turnover in accounts. 

What can also cause alot of confusion is when UICs are re-used. 'Leftover' 
files can turn up with 'un-privileged' ownership in areas that require
privilege to create files. Causes great consternation in new inexperienced 
system administrators.

----

   John Rice        K9IJ     |  "Did I say that ?" I must have, but It was
                             |   MY opinion only, no one else's...Especially
                             |   Not my Employer's....
   rice@ttd.teradyne.com     |   Purveyor of Miracles,Magic and Sleight-of-hand
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: Help!  Lost savesets on a mag tape.
Date: 19 Nov 1992 13:43:54 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 <19NOV199200404281@robot.nuceng.ufl.edu>, sysop@robot.nuceng.ufl.edu (Shawn A. Clifford) writes:
>I had a few important save sets BACKUP'd to TK50, and like an idiot, I was
>messing around with ALLOCate, INITialize, and MOUNT... and I zapped the
>header info on the tape.
>
>I'm sure the data is still there, but how can I retrieve those savesets?
>Is there anyway to remark the tape correctly?  I do know the names of the
>savesets, and it is mainly the very first saveset on the tape that I need.

You're almost certainly out of luck.  When you reinitialized the tape, you very
probably corrupted the first block of data.  When the drive tries to read the
tape, it will probably get a parity error.  You can't skip past a parity error
on a TK50.

On the off chance you DON'T get a parity error, you can use something like DUMP
to skip past the double-eof, then use BACKUP to restore from the rest of the
savesets on the tape.
--------------------------------------------------------------------------------
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.
Xref: sparky comp.os.vms:18031 comp.windows.x:19204
From: Chris_F_Chiesa@cup.portal.com
Newsgroups: comp.os.vms,comp.windows.x
Subject: Q: Grayscale X terminal makes/models?
Date: Mon, 16 Nov 92 14:15:34 PST
Organization: The Portal System (TM)

Hello all...

  I've been assigned to gather information on grayscale graphical displays
capable of displaying photographic or near-photographic raster images.  I
have determined the following criteria, in no particular order of priority:

	cost - as low as possible given adequate ratings in the other areas

	display depth - minimum of four bitplanes, maximum of eight

	transport - preferably VMS "LAT" over Ethernet thinwire, but we
		    could also deal with TCP/IP if we had to

	speed/performance - I have no clear idea what the standard bench-
		    marks are; we want it to be fast while remaining afford-
		    able

	reliability - able to deliver a long life in the face of possibly
		    around-the-clock use and abuse	

I would like to hear from people who can comment on the various makes and
models of grayscale X terminals and possibly evaluate them on these points.
Raves/pans and war stories are acceptable too, if they illustrate points to
be (a)ware of!  Feel free also to suggest more appropriate forums for this
discussion (I've posted to comp.os.vms and comp.windows; couldn't get to
comp.unix because it's moderated), or bring up additional points of compar-
ison that I may have overlooked.

  I am a regular reader of comp.os.vms, but have not thus far picked up 
comp.windows.x.  I'll try to catch the latter starting today, but it's not
really my field, at least not yet. :-)   If you post a response to this mes-
sage in comp.windows.x, may I ask you to also e-mail if you can?  I'll repay
the favor by answering YOUR questions if I can, when they appear in a group
I DO know more about!

  Thanks in advance,

     Chris Chiesa
      Chris_F_Chiesa@cup.portal.com
From: rj@cadre.com (Rob deFriesse)
Newsgroups: comp.os.vms
Subject: Re: Fixing SYSTEM-W-HEADERFULL error
Date: 16 Nov 92 12:21:36 GMT
Article-I.D.: fripp.1992Nov16.122136.26119
Reply-To: rj@cadre.com
Organization: Cadre Technologies Inc.

adam@irvine.com (Adam Beneschan) writes:

: We think the problem is that the system is trying to enlarge the
: INDEXF.SYS file and can't.

That's it exacly.  Here's what you do:

1. Back up the disk to tape or another disk.

2. Determine the maximum number of files you will ever need on the disk.

3. Inititalize the disk with _BOTH_ /maximum_files= _AND_ /headers= set to
    the figure determined in step two.  If you don't use /headers=, it won't
    work.

4. Restore the contents of the disk.  Use /noinitialize if you're doing an
    image restore.
--

  Rob deFriesse                                          Mail:    rj@cadre.com
  Cadre Technologies Inc.                                Phone: (401) 351-5950
  222 Richmond St.                                       Fax:   (401) 351-7380
  Providence, RI  02903

  My opinions are my own and do not represent the position of Cadre in any way.
Newsgroups: comp.os.vms
From: hcc@sunvax.sun.ac.za
Subject: Audit server file corruption
Organization: University of Stellenbosch
Date: Mon, 23 Nov 1992 13:41:09 GMT

Good day all netters

We're experiencing a problem with our audit servers.

Our environment:
  5 VAXen clustered over CI, two HSC50s, one system disk, running VMS V5.5-1
    1 x VAX 780
    2 x VAX 8650
    1 x VAX 6320
    1 x VAX 6510
  SECURITY_AUDIT.AUDIT$JOURNAL file in SYS$MANAGER shared by AUDIT_SERVER
  processes on each node of the cluster.

AUDIT_SERVER is started up by default by VMS, also stopped by VMS with
system shutdown.

In our SYSTARTUP_V5.COM, we do a
  $ set audit/disable=acl
when the command procesure starts, and a
  $ set audit/enable=acl
when the command procedure completes.  This is to limit security messages,
since SYSTARTUP_V5.COM accesses many sensitive files on which we have
security ACEs.

We have experienced corruption of the SECURITY_AUDIT.AUDIT$JOURNAL file
a few times in the last months, and have finally linked the last corruption
with one of our VAXen crashing (the VAX 780).  The records are valid in the 
SECURITY_AUDIT.AUDIT$JOURNAL file right upto the time the SYSINIT record was
made in the ACCOUNTNG.DAT file (on rebooting of the VAX 780 after the crash).
It would appear as if the SECURITY_AUDIT.AUDIT$JOURNAL file was corrupted
when the crashed system rejoined the cluster.

What is really going on?  Is this a known bug?  Are we overlooking something
by disabling and enabling the ACL alarms?

We'd appreciate any info, pointers, hints and/or ideas and will summarize to
the net if there is any interest.

Thanks in advance

J.A.Nel
HCC

HCC@SUNVAX.SUN.AC.ZA
From: LABELLES@ZENO.MSCD.EDU (Stephen LaBelle - MSCD)
Newsgroups: comp.os.vms
Subject: Re: File format change by BACKUP?
Date: 16 Nov 92 20:09:02 GMT
Organization: The Internet

In article <1992Nov12.122046.484@hhcs.gov.au>, sharmp@hhcs.gov.au writes:

> We have just had a situation where the backup command has done a funny on us.
> The situation was a backup to tape was being done of a number of indexed RMS
> files.  The operator was prompted for another tape, and had to abort due to
> problems with the tape mount.
>
> When the files are recovered from tape, the last file on the tape prior to the
> operator abort is in sequential format.  I was fairly sure that backup 
> restored files in the same format as they were put on tape.  Is it possible 
> for the file to be still opened when the operator aborted and for this to 
> result in a different file format?  The recovery command used was just
>       backup/log/select=(filenames)

Here is what probally happened. The file in question was continued on the next
tape reel. When your operator had to abort the restore due to the tape mount
problem, the file restore was incomplete. For that reason what was restored
incorrectly became a sequentil file.

This has happened to me before, the file must be 100% completely restored
before all its attributes are set correctly by RMS.

						Steve

##############################################################################
# Stephen LaBelle                        # Internet : labelles@zeno.mscd.edu #
# Systems Programmer                     #            labelles@clem.mscd.edu #
# Metropolitan State College of Denver   #####################################
# Denver, Colorado  USA                  # Bitnet   : LABELLES@MSCD.BITNET   #
##############################################################################
# DISCLAIMER: The opinions expressed are mine and in no way, shape or form   #
# neccessarily reflect those of Metropolitan State College of Denver.        #
##############################################################################
From: brydon@asl.slb.com (Harvey Brydon (918)250-4312)
Newsgroups: comp.os.vms
Subject: Re: Bound volume sets: are they a bad idea?
Date: 16 Nov 92 13:51:04 GMT
Reply-To: brydon@dsn.SINet.slb.com
Organization: Schlumberger/Anadrill Sugar Land, TX

In article <1992Nov10.124211.6220@slcs.slb.com>, brydon@asl.slb.com (Harvey
Brydon (918)250-4312) writes:
>Also, keep in mind that
>you are taking 2 'large' volumes and making them into one.  This effectively
>increases the size of the cluster factor.  If it is 4 on one of these disks,
>it will be 8 on the volume set ...

Robert Gezelter, Jerry, Carl and a couple of others took me to task on this
(but not (yet?) Ehud).  Two errors on my part.  (1) In a volume set, each
volume has its own bitmap.sys, so a bound volume set does not double the
cluster size. (2) Even in a volume set or stripe set, everybody else says that
even though the cluster size can be larger than unity, read/write requests can
be made for a number of blocks smaller than the cluster size. Sorry for the
errors.  I hang my head in shame.

Obscure biblical quote:  "GO TO, let us go down, and there confound their
language, that they may not understand one another's speech  - Genesis 11:7

Disclaimer: I have never been on Prozac.
_______________________________________________________________
Harvey Brydon         | Internet:   brydon@dsn.SINet.slb.com
Dowell Schlumberger   | P.O.T.S.:   (918)250-4312
    I thought I was wrong once, but I was mistaken.
Newsgroups: comp.os.vms,comp.sys.vms
From: thomas@ritcsh.csh.rit.edu (Run Around Platy)
Subject: Grep for VMS
Summary: Anyone see it lately?
Originator: thomas@nick.csh.rit.edu
Keywords: help, please
Organization: Computer Science House @ RIT
Date: Tue, 17 Nov 1992 18:33:40 GMT

I know I remember seeing a post about it somewhere.  Does anyone out
there know where I can find grep for VMS?  When I first saw it, I
disregarded it because I never used VMS.  Now I got a job which
requires me to (ugh!) use VMS.  I'm doing some developmental work, now
and grep would be quite handy.  Can anyone help me out?

Thanks in advance.

-thom
-- 
Thom Craver             |  "It is the duty of men to love
thomas@nick.csh.rit.edu |   even those who injure them."
trc6398@ritvax.rit.edu	|               - Marcus Aurelius
From: TEWKSBURY@BUDSGA.BU.EDU (Chip Tewksbury)
Newsgroups: comp.os.vms
Subject: Re: Bound volume sets: are they a bad idea?
Date: 19 Nov 92 20:19:07 GMT
Organization: BOSTON UNIVERSITY, OFFICE OF INFORMATION TECHNOLOGY
X-News-Reader: VMS NEWS 1.24

In <1egbrqINNiqd@post.its.mcw.edu> kcb@post.its.mcw.edu writes:

> singer@rhodes.aero.org wrote:
> 
> : >>As far as I can reason it out, the pro is some degree of load balancing 
> : >>between the disks, and no management hassles sorting out what to put where.
> : >>The con is a halved MTBF on the bound set. Backup shouldn't be a problem, 
> : >>both together will fit on one DAT.
> 
> Wrong.   Volume binding does NOT do much load balancing at all.  At the
> very least, you have absolutely no control over it.   My best example
> is our own shop....   we have humungous MUMPS.DAT files (on the
> order of several million blocks large), and we used to have bound
> sets.    Most of the time, the first (n-1) disks were totally idle,
> while the last disk in the set got absolutely pounded.   Your
> mileage will vary, of course.
>...

    Kent, Your response is partially correct.  Volume sets automatically
    create new files on the volume in the set which has the most free space,
    unless the creation is done with explicit placement.  If a system's file
    sizes are relatively small and comparable, then excellent load balancing
    at the file level will be realized from a volume set.  Striping won't
    add much, if anything, to the load balancing performance if you have
    smaller files of comparable size.

    But as you said about your sight, if you primarily have "humungous"
    files then the greatest benefit comes from striping.

    "Your mileage will vary, of course."  And each site needs to identify
    their system's file population  (and propagation) before jumping on the 
    single physical volume, multi-volume volume set, or multi-volume stripe
    set bandwagon.
    			Chip Tewksbury.
From: oberman@ptavv.llnl.gov
Newsgroups: comp.os.vms
Subject: Re: Experiences with exabyte jukeboxes, anyone?
Date: 19 Nov 92 22:02:07 GMT

In article <43@isis.win.net>, sean@isis.win.net (Sean Gonzalez) writes:
> 
>         Does anyone have any experiences with exabyte (8mm) jukeboxes? 
>         We are currently considering using a MicroTechnologies Inc.
>         (MTI) jukebox and would appreciate any comments which might save
>         us headaches in the future.  Also, if you have successfully used
>         some other vendor's jukebox, please do share your experiences. 

I have no experiance with the Exabyte unit, but I have been very pleased with
another unit we are using. It is the ACL-600 StackLoader from Automated
Cartridge Libraries, Inc. of Longmont, CO, (303)651-1224.

he unit is very inexpensive (under $2K) and very simple in design. It relies
almost exclusvely on gravity with the single exception of pulling the tape out
of the drive. It can work with either an Exabyte 8200 or 8500.

It's not the prettiest thing I've ever seen, but its not bad looking either.
When I first saw it I was afraid it would never work. Too cheap looking. But
after closer examination I was very impressed by the simplicity of the design.
I've alway found gravity to be pretty reliable, myself.

The unit has been completely reliable for the 2 months I have been using it
except one time I stuck my big fingers into it and jammed it. Clearing it was
no problem. Installing our 8200 was no problem. Jut pull teh drive outof the
old shoebox and drop it into the ACL-600. Plug in SCSI and power cables and it
was done.

Capacity of the input hopper is 7 tapes and the output bin is 6. This is a
stack loader, not a jukebox. Tapes go in the top and come out the bottom.

This is a report of my personal observations. Your mileage may vary! Neither
the University of California, the US Dept. of Energy, nor LLNL endorse or
recommend this unit. Nor do they know anything about this message.

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: koberman@llnl.gov		(510) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
From: helen@pulua.hcc.hawaii.edu (Helen Rapozo)
Newsgroups: comp.os.vms
Subject: Re: Problem Deleting Users from Different Disks
Date: 15 Nov 92 19:56:33 GMT
Organization: Honolulu Community College

In article <01GQZRJYX7YA8WYHCU@LAGUNA.EPCC.EDU> ARTG@LAGUNA.EPCC.EDU writes:
>
>Background:  We have two DEC VAX 4200's clustered together
>             running VMS 5.4-2.
>
>I have a problem and I can't seem to find the answer.  We have 
>users on several disks and I am writing a procedure to delete
>them when their accounts are no longer needed on our system.  
>However, I can't seem to find a way to determine if the user
>is on DISK2, DISK3, or DISK4.  Is that any way of using one DCL
>procedure to determine which disk the user is on?  I'd also like to have
>this procedure delete that user from the appropriate disk.
>I really don't want to have 3 seperate delete procedures, one for 
>each of the disks.
**************
If you are using the AUTHORIZE utility to remove the user, you can
also use it find their login directory.

To do this use the 'LIST/FULL username' in the AUTHORIZE utility, 
this will create a file SYSUAF.LIS in the current directory you
are working in.  If you use DCL to open and then read the SYSUAF.LIS
you should come across the login directory spec (with device), you
might need some DCL lexicals like extract to this since there
is another piece of information that goes with the line.



Honolulu Community College            cs_rapozo@hccadb.hcc.hawaii.edu
874 Dillingham Blvd.                  helen@pulua.hcc.hawaii.edu
Honolulu, HI 96817                    rapozo@uhunix.uhcc.hawaii.edu
Ph#: (808) 845-9202
Xref: sparky comp.os.vms:17999 comp.sys.dec:5976 comp.lang.c:16568
From: shoop@horton.farsef.com (Dan Shoop)
Newsgroups: comp.os.vms,comp.sys.dec,sub.os.vms,comp.lang.c
Subject: Re: How to generate VMS-bookreader-doc's ???
Date: Sun, 15 Nov 92 14:06:14 EST
Distribution: world
Organization: FARSEF -- The Far Side Expeditionary Force

sca@gese.ge14.mdadv.gv.at (Petzi Schweda) writes:

> 
> We're currently having c-written programs generating our docu's
> under VMS as TXT, HLP, and PS. 
> Anybody an idea how to get bookreader-docs ???
> ... without using VAX-DOCUMENT ????
> 

DECwrite also produces Bookreader files.

Beware the Bookreader Trolls.

-dhan



FARSEF | The                                  Dan Shoop
       | Far Side                             shoop@horton.farsef.com
       | Expeditionary                        ATTnet:          201.612.0895
       | Force                                PagerNet: 800.225.0256 #92664
                                              Snail:   127 E Prospect 07463

                Give your child mental blocks for Christmas.
Newsgroups: comp.os.vms
From: fairfield@slacvx.slac.stanford.edu
Subject: Re: Help needed printing file using system routine
Organization: Stanford Linear Accelerator Center
Date: Fri, 20 Nov 1992 21:17:46 GMT

In article <19967.2b0cd0ee@ul.ie>, 9118187@ul.ie writes:
> 
> I'm looking for the system routine that queues a file to a printer.
> I want to print the file without using LIB$SPAWN.

    SYS$SNDJBC
-- 
 Dr. Kenneth H. Fairfield    |  Internet: Fairfield@Slac.Stanford.Edu
 SLAC, P.O.Box 4349, MS 98   |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
 Stanford, CA   94309        |  BITNET    Fairfield@Slacvx
 ----------------------------------------------------------------------------
 These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
Newsgroups: comp.os.vms
From: rubin@procon.jhuapl.edu (Don Rubin)
Subject: Re: Wierd BACKUP change in VMS 5.5-2
Organization: Johns Hopkins Univ APL
Date: Thu, 19 Nov 92 17:53:23 GMT



!If memory serves, you've *NEVER* been able to mount a tape that was allocated
!to the parent of the current process.  VMS v4.0 made some changes in the way
!tape mounting was done that allowed the tape to be shared among processes in a
!job.  If I recall correctly, that version of VMS had a bug that caused the
!MOUNT to also allocate the tape (or maybe it changed the ownership of a tape
!allocated by the subprocess to ownership by the parent; it's been a long time
!since 4.0 and my memory's a bit fuzzy).  Thus if one mounted a tape from a
!subprocess, then dismounted it, a subsequent attempt to mount it would fail.

I was the original poster. The problem occured in moving from VMS 5.5-1 to
5.5-2. Despite the above comments, on our system, the sharing of a mounted
tape did work. That is, if in the main process I mount a tape (from code
using sys$mount) then SPAWN BACKUP in a sub-process (using smg$create_subprocess),
it would work fine. This stopped working in vms 5.5-2 (at our site). DEC
support has referred this to engineering.

--
Don Rubin
Johns Hopkins Univ APL
rubin@procon.jhuapl.edu
From: drlee@SOMNET.SANDIA.GOV (Donald R Lee)
Newsgroups: comp.os.vms
Subject: Looking for a new Job
Date: 16 Nov 92 20:04:55 GMT
Organization: The Internet

Dear info vax readers.
 I am looking for a new position in the computer arena   
my current contract with Sandia Labs is expiring at the end of the month.
Attached you will find a copy of my resume for all to look at.
Please contact me at my home at (505)831-8012 or my address on my resume.
Thanks to ALL....!!!!
~r /news/drlee/drlee.txt

DRLEE@SANDIA.GOV Albuquerque NM (505)844-9678


.
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: logical table search lists
Date: 22 Nov 1992 16:22:24 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 <1992Nov21.225612.1@skcla.monsanto.com>, steffens@skcla.monsanto.com writes:
=I would like to add a logical name table to the set of tables that are
=automatically searched whenever a logical is used in a command.  Specifically,
=I want the members of several VMS groups to add the group logical name table to
=their search list; e.g. I need the members of groups 160, 165, 170 175 to
=include the logicals in group 150 in their search list.  But the people in
=groups 160 - 175 also need the rest of the search list unaffected.
=
=It seems like I should be able to redefine FILE_DEV or some such logical which
=defined the list of tables to be searched?

You want to define LNM$FILE_DEV in the table LNM$PROCESS_DIRECTORY (if the
change is to be for only specific users) or in the table LNM$SYSTEM_DIRECTORY
(not recommended) if the change is to be system-wide.
--------------------------------------------------------------------------------
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.