HDTenEightyP/NetNews huggingface dataset:
From: SYSTEM_JB@UNODE2.NSWC.NAVY.MIL ("SYSTEM SUPPORT")
Newsgroups: comp.os.vms
Subject: Another reply for:  SECURITY PROBLEM FOR GURUS
Date: 5 Jan 93 21:58:00 GMT
Distribution: world
Organization: The Internet

!From:       <UNODE2::WINS%"agate!spool.mu.edu!enterpoop.mit.edu!eru.mt.luth.se!l
!Date:       02-JAN-1993 20:15
!Subject:    Re: HELP!!! Security problem for gurus.
! 
!In article <1992Dec10.095514.1337@galaxy.gov.bc.ca> ewilts@galaxy.gov.bc.ca (Ed Wilts) writes:
!>In article <B1FB21FFA27F004AEF@imimnvx.irfmn.mnegri.it>, PSI%ITAPAC.22800002::PITCLS::ADRIANO@imimnvx.irfmn.mnegri.it (Adriano Santoni) writes:
!>> 
!>> 	I need to avoid certain people to scan a directory of mine. This
!>> 	could seem a very trivial issue, if it was not for the following:
!>> 
!>> 	o  Some users of mine have (and need to retain) *ALL* privileges
!>As long as they are privileged, there is absolutely nothing you can do to stop
!>them from accessing your data.  If they so chose, they could even use your
!>userid to do it.
!>
!>If you can't trust them with the privileges, don't give them out.  Simple as
!>that.
!
!Oh, yes, there is something he can do. Use SE-VMS, the secure version of
!VMS. But then the machine will probably be unusable, unadministrable and
!slow. But secure.

What about UPGRADE, DOWNGRADE (specific to SE-VMS) and BYPASS privileges???  
If you have all privileges you are GOD to that system.  Of course SE-VMS does
make your system almost as usless as UN*X, but at least with security.   o-)

------------------------------------------------------------------------------

   "Why don't Pygmys eat clowns??   Because they taste funny"


Jon Baker
Naval Surface Warfare Center
Code N23A
Dahlgren, VA 22448
703-663-8705
From: leichter@lrw.com (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: re:  Re: Question about RMS and MSCP-pair
Date: 6 Jan 93 11:30:25 GMT
Organization: The Internet


	[I wrote:]
	> By the time you get a "forced error", the data is gone.  The forced
	> error indicator is set on the REPLACEMENT block, not the original
	> one, and I don't believe the corrupted data, such as it was, is even
	> copied into the block.

	It's implementation-specific, according to the MSCP architecture spec.
	There is no reasonable reason to copy the data in the case of an
	uncorrectable error. However, some of the controller-based BBR
	implementations use a common code path with the correctable error /
	revector code and have a flag to say whether or not the forced error
	flag should be set. These implementations do in fact preserve the
	data, although it is certainly not the _correct_ data.

Well, it's good to know my memory on this subject isn't COMPLETELY wrong!

	BTW, the "forced error flag" is set by computing the CRC

I assume you mean ECC here.

								 of the new
	block and writing it out complemented. Just a useless tidbit of trivia
	(unless you are going to physically talk to a drive with a controller
	of your own design 8-).

This I didn't know.  Interesting hack - with an interesting side-effect:  If
a replacement block with the "forced error flag" set gets hit by an error, it
will no long appear to have the "forced error flag" set - it'll just appear
wrong.  Worse, there will be some class of hits which will look as if they are
correctable errors, assuming the complemented ECC is the REAL ECC.  In that
case, a "forced error" block my spontaneously "correct itself" - but the data
in it will be completely bogus.  Presumably this will happen once on all the
disks in the world within the next 10,000 years, or something like that - but
it does tell you that you don't really want to keep files with forced errors
in them around for long periods of time.  If a forced error shows up in your
backup runs - do something about the file.
							-- Jerry
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: Creating subprocess with $CREPRC; preservation of symbols/logicals
Date: 9 Jan 1993 23:12:55 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 <C0I3xM.84F@acsu.buffalo.edu>, masmummy@ubvmsb.cc.buffalo.edu writes:
>I have a program that needs the use of $CREPRC to create a subprocess.
>I think LIB$SPAWN is great, but I cannot alter quotas with it.
>
>My problem lies in preserving symbols and/or logicals.
>Is there any way (with normal privileges) that I can pass information to
>this subprocess (I need to give it a stream about 80 characters long), without
>resorting to files, mailboxes, and such?

You *COULD* specify some 80-character string for error argument to $CREPRC,
then use $TRNLNM to translate SYS$ERROR.

>It appears to me (I am not an expert)
>that LIB$SPAWN copies the symbol and logical tables over by default.  Can I
>do that with $CREPRC, too?

No.  You'd have to create a mailbox, then have the subprocess read the mailbox
and use the information so obtained to set up logical names and symbols.
--------------------------------------------------------------------------------
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: ELEHUMBORG@ORBSEN.UCG.IE (It's more fun to compute)
Newsgroups: comp.os.vms
Subject: 'ASSUME' macro in VAXC?
Date: 11 Jan 93 13:25:00 GMT
Organization: The Internet


Does anybody know any way of implementing compile-time checking in VAXC 
similar to the ASSUME macro defined in LIB.MLB (or is it STARLET?)?

What I want to check for specifically is that the size of a certain struct
is equal to 512 bytes and if not, print a warning message.

Say:
check sizeof(struct foo) "Error: foo is the wrong size"

I don't really mind how kludgy the solution would have to be, as long as
it works.

Thanks,


Kenn Humborg
elehumborg@orbsen.ucg.ie
"I program my home computer,
 Beam myself into the future" - Kraftwerk, 1981

Newsgroups: comp.os.vms
From: tihor@acf3.NYU.EDU (Stephen Tihor)
Subject: Re: Date incorrect after reboot
Organization: New York University
Date: Wed, 6 Jan 1993 17:01:00 GMT

(a) not everyone shutsdown their system betweeen jan1 and april 1.
(b) sometimes machines crash, eg go down without running SHUTDOWN.
(c) SHUTDOWN only does a set time on the node being shutdown, in a cluster
you want to do the set time on all nodes within the cluster before any 1
goes down.
Newsgroups: comp.os.vms
From: ecf_stbo@jhuvms.hcf.jhu.edu (Remember Grimalkin)
Subject: RE:  Getting rid of SMB_SECURITY once and for all ?
News-Software: VAX/VMS VNEWS 1.41    
Organization: The Johns Hopkins University - HCF
Date: Mon, 4 Jan 1993 15:55:00 GMT

In article <1992Dec30.041846.5354@decuac.dec.com>, murphy@ufp.dco.dec.com writes...
>The "default" X Window System security scheme on UNIX systems is host-based
>only; anyone logged in to your workstation has access to the display.
>On VMS, the authorization information includes the username of the user.
>Thus, there aren't the same security risks - unless you're sharing your
>password :-)

You neglected to mention that since TCP/IP doesn't pass this information,
the 'only' VMS security scheme boils down to the 'default' unix scheme when
using TCP/IP as the transport. Hopefully something better will be provided
in this century. Until then, people should remember that if you permit a remote
tcp/ip host to access your display, anyone on that host can grab your
keystrokes, including passwords, etc... without you even noticing.



Tom O'Toole - ecf_stbo@jhuvms.hcf.jhu.edu - JHUVMS system programmer 
Homewood Computing Facilities, Johns Hopkins University, Balto. Md. 21218 
>Here comes a jet ski.
>weuh weeuhh weeuhh weeuhh WEEUHH WEEUHH WEEUHH WEEUHH weeuhh weeuhh weeuhh weuh
From: per@front.se
Newsgroups: comp.os.vms
Subject: How to raw() the terminal
Date: 5 Jan 93 16:13:28 MET
Distribution: world
Organization: Front Capital Systems AB, Sweden

The VMS C Run-time library comes with a curses package, which suggests
to me that it would be possible to implement a portable terminal forms
package. However, to do input of, say, function keys in a portable
way, you need to call raw().

Now, the VMS implementation of raw() does not work as it should. It
should make getch() return immediately with a single character.
Instead, it waits until five (5) characters have been typed, or after
ten (10) seconds after a character has been typed. Weird!

So, has anybody seen a kosher version of raw() and noraw() for VMS?

Or, what is the canonical way to do input of both command lines and
function keys in a portable way while using curses?

Per Lindberg (per@front.se)         !      __!__
Front Capital Systems, Box 5727,    !  _____(_)_____  Ceci n'est pas une Piper
11487 Stockholm, Sweden. 8-6611510  !     !  !  !
From: pyron@skndiv.dseg.ti.com (Dillon Pyron)
Newsgroups: comp.os.vms
Subject: Image activator hates me
Date: 7 Jan 93 17:13:36 GMT
Reply-To: pyron@skndiv.dseg.ti.com
Organization: TI/DSEG VAX Support


When trying to run a number of images or commands, I will occasionally and
unpredictably get the following error:

%IMGACT-F-NONAME, the image name is a required parameter

This has occured with typ/p, dir/sec, mm and others that I can't remember.  The
weird thing is that the command, image, whatever runs on the second try.  I'm
running V5.4.  I can't find this particular message in my OLD.

I called DEC CSC, and the guy I talked to suggested a memory problem.  Now I'm
looking for input from the pros :-)
--
Dillon Pyron                      | The opinions expressed are those of the
TI/DSEG Lewisville VAX Support    | sender unless otherwise stated.
(214)462-3556 (when I'm here)     |
(214)492-4656 (when I'm home)     |"Pacts with the devil are not legally
pyron@skndiv.dseg.ti.com          |binding!"
PADI DM-54909                     |-Friar Tuck   _Robin Hood:The Hooded Man_
Newsgroups: comp.os.vms
From: nowacki@porsche.net.com ( Michael Nowacki I.T. Database Contractor)
Subject: Re: The VAX Vacuum
Organization: Network Equipment Technologies, Redwood City
Date: Wed, 6 Jan 1993 00:31:04 GMT

In article <1993Jan5.181239.6299@nntpd2.cxo.dec.com> winalski@adserv.enet.dec.com (Paul S. Winalski) writes:
>
>In article <9301040153.AA20250@ucbvax.Berkeley.EDU>,
>FZC@CU.NIH.GOV ("Paul Robinson, Contractor") writes:
>|>
>|>Until last year, in the U.S. a trademark/servicemark is owned
>|>ONLY by the first party to USE it in a particular country.  This
>|>meant that legally, if DEC had used VAX in the U.S. before that
>|>other company used the term for its vacuum cleaners in the U.S.,
>|>it could prevent that company from selling vacuums under that
>|>name in the U.S.  It does not matter that someone was selling
>|>under that name earlier in the U.K.; only the first user in a
>|>particular country has first rights to the mark.
>
>However, US trademark law also allows the same word or phrase to be used as a
>trademark as long as the marks are used in distinct markets and the proverbial
>legal "reasonable person" has no difficulty distinguishing between the two uses.
>The VAX vacuum cleaners and VAX computer systems are in such distinct markets
>and so there is no problem.  If DEC ever decides to manufacture household
>cleaning equipment, though, we'll have to choose a different name for it.

This is exactly what happend to Apple Computer last year: release of music 
editing software invoked an earlier agreement with Yoko Ono, executor of the
estate of John Lennon, whereby Apple Computer could use the trademark "Apple"
as long as they don't get into the music business. I think it cost Apple
a few million bucks.
Newsgroups: comp.os.vms
From: lionel@quark.enet.dec.com (Steve Lionel)
Subject: Re: re: Re: Passing parameters to detached processes.
Reply-To: lionel@quark.enet.dec.com (Steve Lionel)
Organization: Digital Equipment Corporation, Nashua NH
Date: Mon, 4 Jan 1993 18:23:54 GMT


In article <1993Jan4.170428.1518@pony.Ingres.COM>, mikes@Ingres.COM 
(Mike Schilling) writes:
|>From article <1i8q3mINNdbj@gap.caltech.edu>, by carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick):
|>> In article <31DEC199209423681@author.gsfc.nasa.gov>, rkoehler@author.gsfc.nasa.gov (Bob Koehler) writes:
|>>>In article <9212301623.AA19674@uu3.psi.com>, leichter@lrw.com (Jerry Leichter) writes...
|>>>> 
|>>>> 
|>>>>Note that running LOGINOUT to map the CLI in this way is itself undocumented
|>>>>and unsupported....
|>> 
|>> Where?  
|>Where what?  Which where?  Who's on first?
|>Are you really asking where it's undocumented?  (Like Woody Allen's joke about
|>the atheist and the agnostic who couldn't decide which religion not to bring
|>their kids up in.)  
|>
|>>And could you please specify things explicitly enough that we'd have
|>> a chance of knowing what you're talking about?  The post to which I'm replying
|>> is the sort of thing that those who object to my flames should *REALLY* be
|>> complaining about.
|>
|>It was entirely clear in this post what Jerry was warning about, the 
|>old trick of
|>
|>	$ RUN/DETACH SYS$SYSTEM:LOGINOUT/INPUT=something.COM
|>
|>to get a detached process which runs a CLI.  To inject a little content into
|>this flamefest, can anyone:
|>
|>1. Verify that this technique is unsupported.
|>2. Suggest a supported way to acomplish the same thing.
|>(The only thing that comes to mind is submitting a batch job.  This will
|>work fine with a suitably configured batch queue, but programs don't
|>always run on systems the developer manages.)
|>3. Comment on the probability of such code breaking in the future.
|>

There actually is documentation of the use of LOGINOUT with RUN/DETACH; in
the VMS V5.0 manual set, it's on page DCL-392 of the DCL Dictionary in the
description of the /AUTHORIZE qualifier to RUN.  It says:

	When the image to be executed is the system login image 
	(LOGINOUT.EXE), ...

This implies to me that it is a supported use to specify LOGINOUT.EXE as
the image name.  However, I say this on my own behalf and not as an
employee of Digital.  Still, I am not aware of any intention to declare this
usage as "unsupported" and am also unaware of any new feature coming in V6.0
that would replace this (and I think I would know if there were.)
--

Steve Lionel                    lionel@quark.enet.dec.com
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: Date incorrect after reboot
Date: 9 Jan 1993 13:31: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 <1993Jan7.090347.14794@fys.ruu.nl>, hooft@fys.ruu.nl (Rob Hooft) writes:
>In <1993Jan6.092134.22@sfpp.com> longo@sfpp.com (Bob Longo) writes:
>
>>Yeah... My VAX systems NEVER crash, so why bother?    ;-)
>
>>Seriously - you are correct that SHUTDOWN.COM does the SET TIME, but systems
>>do occasionally crash, lose power, etc.  Issuing the SET TIME shortly after
>>midnight after the new year change covers you in case of such a disaster.
>
>Just make sure you have a cluster: good LAVC practice is to
>synchronize the clocks every once in a while: I think SET TIME/CLUSTER
>will also take care of the problem?
>
>And: NO: Our VAX systems NEVER crash. Uptimes upto 600 days, causing an
>overflow in the CPU time of the NULL process (Yes: VMS 4.7).

Odd that nobody's explained this behavior.  VAXen have TOY clocks.  TOY stands
for Time Of Year.  Upon boot, the system combines the year information from
SYSBOOT.EXE (I *THINK* that's the right image) with the data in the TOY clock
to get the current time.  If SYSBOOT hasn't been updated since last year, this
combination gives the obvious erroneous result.
--------------------------------------------------------------------------------
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: Help of execution queues...
Date: 9 Jan 1993 22:46:22 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 <9C005C273F5F0041D8@EGFRCUVX>, SABRY@SHEBIN.EG (Sabry Kotob El-Ganzory) writes:
>SERVER, this is not known to me but it is Processes files in the queue using a
>specially created symbiont. Symbionts for server exection queues are
>user-written....ok.
>finally, I obtain on Student workbook of VMS System management 1. EY-9766E-SG-00
>   001.
>My question is: Have anyone information of SERVER output execution queues and
>I want example of how to create this SERVER or Symbionts because not covered in
>this course????

There are two ways of creating your own symbiont:
	1)  By using the SMB$ utility routines to write an entire symbiont from
	    scratch; or
	2)  By using the PSM$ utility routines to modify the standard VMS print
	    symbiont;
Please see the Utility Routines s manual for details.
--------------------------------------------------------------------------------
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: clifton@rose.brandeis.edu (James Clifton)
Subject: vms tail utility?
Keywords: tail
Organization: Brandeis University
Date: Fri, 8 Jan 1993 18:40:26 GMT

Does anyone know of a VMS version of the UNIX program 'tail'?

Please send replies to clifton@auriga.rose.brandeis.edu

Thanks, 
Jim Clifton
From: BILL@HARTWICK.EDU (SYSTEM MANAGER)
Newsgroups: comp.os.vms
Subject: High Speed Tape backup
Date: 6 Jan 93 14:34:57 GMT
Distribution: world
Organization: The Internet

Greetings...
What can anyone tell me about Tape backup. I have a VAX 6410 and 
a MicroVax 3100. The 6410 serves 4 1.2 gig RA90's. The daily
or weekly backup of users files is not that Big a problem.
The problem is 6-10 hours of down time for a Standalone backup.
I do the standalone backup once or twice between September and
May  ( this is the Academic Year). Over the summer it's done
at least 4. As you can mostly likely guess the users do complain
about the down time. 

	Now I do not have a SCSI interface for the 6410. 

All ideas are welcome.
Thanks
BILL@hartwick.edu

Newsgroups: comp.os.vms
From: buijs@uxopof.cern.ch ()
Subject: Crash of VAXstation 3176 every 11 minutes.
Keywords: VAXstation booting
Reply-To: buijs@uxopof.cern.ch ()
Organization: CERN - European Laboratory for Particle Physics
Date: Wed, 6 Jan 1993 11:44:38 GMT


Some time ago I remember having seen an explanation for the phenomenon when a
VAX station crashes every 11 minutes, but I forgot the reason.

Now it is happening to one of my stations. Occasionally it hangs iso crashing.
Does anyone remember what could be the cause of this problem?
Newsgroups: comp.os.vms
From: mark@infocomm.com
Newsgroups: comp.os.vms
Subject: Re: MFTU
Date: 5 Jan 93 14:35:43 PST
Distribution: world
Organization: INFO COMM - Computer Consulting, Redwood City, Ca

In article <01GT5K13EESY000MF5@SCI.WFEB.EDU>, MACRIDES@SCI.WFEB.EDU (Foteos Macrides) writes:
> In article <01GT5F5TI3RK00007S@SCI.WFEB.EDU>, Arne Vajhxj <ARNE@KOPC.HHS.DK> writes:
>>> on an old DECUS-tape I found a programm called MFTU. It converts VMS-files
>>  into
>>> ASCII text (suitable for electronic mail exchange) and vice versa, preserving
>>> the original VMS file structure.
> [...]
>> Anyway - I think a better method is to use ZIP (the new version do preserve
>> VMS file attributes) to compress the file and use UUENCODE or VMS_SHARE to
>> encode the zip-archive for mailing.
>>  
>>                                                           Arne
>>  
>> Arne Vajhxj                             local DECNET:  KO::ARNE
>> Computer Department                     PSI:           PSI%23831001304030::ARNE
>> Business School of Southern Denmark     Internet:      ARNE@KO.HHS.DK
> 
> 	I learned this a few weeks ago by asking on vmsnet.sources.d, and
> thought it might be helpful to those who read Arne's message.
> 
> 	Although the current version of VMS_SHARE can encode binary (e.g., ZIP)
> files, if you MFTU the ZIP archive, the subsequent VMS_SHARE set is *much*
> smaller than if you do the VMS_SHAREing directly on the archive.

Beware when using VMS_SHARE to encode binary data.  SERIOUS amounts of
CPU time are consumed BOTH in the encoding and decoding.  

I did the original work on adding the file attribute preservation support
to VMS_SHARE and my goals at that time were to follow along with the basic
premise of a "shar" file - that it be self sufficient, i.e it does not
require any "extra" software be resident on the machine that is doing the
unpacking.  The original problem was to be able to pass executable files.

If BOTH you and the receiving end of the transfer have access to MFTU to
encode the file then prepacking with MFTU is certainly a preferable
method.  You will also then be able to move any arbitrary binary file
instead of the limited set that VMS_SHARE will handle.  VMS_SHARE is
basically limited by the underlying TPU implementation and hence will only
deal with sequential files that have reasonable record length.  MFTU will
encode any file and preserve all of its file structure attributes.

>=========================================================================
> Foteos Macrides           Worcester Foundation for Experimental Biology
> MACRIDES@SCI.WFEB.EDU     222 Maple Avenue, Shrewsbury, MA 01545
>=========================================================================

--
Mark Pizzolato - INFO COMM Computer Consulting, Redwood City, Ca
PHONE:	(415)369-9366	UUCP:  decwrl!infopiz!mark or uunet!lupine!infopiz!mark
DOMAIN:	mark@infocomm.com
From: CLINTON@CSMCMVAX.BITNET
Newsgroups: comp.os.vms
Subject: joining a 4500 and a 4600 into a cluster running 5.4-2
Date: 4 Jan 93 19:14:00 GMT
Distribution: world
Organization: The Internet

When attempting to join a vax4500 into our cluster, we get an "unknown or
unsupported processor" error.  The rest of the cluster runs VMS 5.4-2.

I've been told that the 4500 needs VMS 5.5-2 to recognize its RF73 drives, but
why will it not boot as an LAVC node?

Clinton

Newsgroups: comp.os.vms