HDTenEightyP/NetNews huggingface dataset:
From: tp@mccall.com (Terry Poot)
Newsgroups: vmsnet.misc
Subject: Re: How to boot VMS from a failed AUDIT writingRE
Date: 19 Aug 92 23:50:25 GMT
 <1992Aug11.123003.247@winkle.bhpese.oz.au> <1992Aug18.094524@mccall.com> <1992Aug19.082759.1@zodiac.rutgers.edu>
Reply-To: tp@mccall.com (Terry Poot)
Organization: The McCall Pattern Co., Manhattan, KS, USA
Nntp-Posting-User: tp


In article <1992Aug19.082759.1@zodiac.rutgers.edu>, leichter@zodiac.rutgers.edu
writes:
>Terry Poot complains that the default configuration of the audit server makes
>the system unbootable if the audit log fills.
>
>This is really due to the DoD!  ...

Thanks for the explanation. I'll grant that it has to start up in an
out-of-the-box system. But DEC could have made it easier and more obvious to get
rid of it for us non DOD types.

In article <78018@ut-emx.uucp>, D.Nash@utexas.edu (Donald L. Nash) writes:
>>A much more effective command which will prevent the problem from
>>reoccuring is set audit/server=stop, preferably in the system startup
>>procedure.
>
>I found out how to keep the audit server from ever starting up in the
>first place.  In the SYSMAN STARTUP database STARTUP$STARTUP_VMS, there
>is a file called VMS$CONFIG-050_AUDIT_SERVER.COM.  Disable this file (on
>all nodes, if you're in a cluster), and the audit server will never
>start.  

That's pretty good, but...

>You just need
>to remember to do it every time you upgrade VMS (oops, I mean OpenVMS :-).

That isn't good at all. My method "set audit/server=exit" is permanent, if less
clean (I get audit server starting and stopping messages on each node).

DEC could have followed their existing precedents, by providing a logical name
that could be set in systartup_v5 (I could even live with it sysecurity) by
putting a commented out definition of that logical name with a comment block in
the template file that they ship. Since it'd only be looked at at system startup
time, it certainly wouldn't be a security hole.

When you set up a new system (or do an upgrade), you go through the templates as
a matter of course. If it were there, many more people would see it and read the
comments and realize that there this was something they needed to think about.
The comments could direct them to the docs. For examples, look at the current
systarup_v5.template (I'm on 5.5) and notice the logicals DECW$IGNORE_DECNET and
DECW$IGNORE_DECWINDOWS. 

I know I certainly would have seen it there, and if the warning next to it were
sufficiently clear, I'd have done something about it. You don't even have to be
clear if you are ominous enough. Something like "if the auditserver starts, it
can take your system down in ways difficult to repair, so you'd better read up
on it in the security manual." would scare me enough to send me to the doc set!
--
Terry Poot <tp@mccall.com>                   The McCall Pattern Company
(uucp: ...!rutgers!depot!mccall!tp)          615 McCall Road
(800)255-2762, in KS (913)776-4041           Manhattan, KS 66502, USA
From: fairfield@slacvx.slac.stanford.edu
Newsgroups: vmsnet.misc
Subject: Re: New Mail won't die!
Date: 14 Aug 92 17:55:45 GMT
Organization: Stanford Linear Accelerator Center

In article <bs6m_l_.mendi@netcom.com>, mendi@netcom.com (Greg Mendizabal) writes:
> Recently I set up a batch job to remind me of important events (via 
> VMS MAIL) and then resubmit itself.  Yes, you can see the GLARING error
> that I made -- I had not changed the trigger time and so the process went
> berserk and sent me 1638 mail messages before it crashed.  Well, in a 
> rush I deleted the mail out of my directory without reading it.
> 
> Now, everytime I logon I have 1638 new mail messages.  I cannot eradicate
> this "flag".  I've tried deleting my mail directory, the "mail" itself 
> (ie send myself new mail and then do a del/all within mail).  I've even
> killed my UAF entry and regenerated......only to find 1638 mail messages
> waiting!!!

    Gee, couldn't you have used a BIGGER HAMMER??  (Sorry, just couldn't
resist... ;-)                     ^^^^^^^^^^^^^

> So, where is this flag bit set and kept????  We have another account with
> the same problem (only 2 msgs however).
> 
> This is driving me nuts!  ;-)

    Just start up MAIL, READ any and all new mail messages.  When you
are _sure_ there are NO NEW MAIL messages left to read (I don't mean you
have to delete them, you just need to have read them), then type READ/NEW
and exit:

	$MAIL
	MAIL> READ
	MAIL> READ
               .
               .
               .
	MAIL> READ
	%MAIL-E-NOMOREMSG, no more messages

	MAIL> READ/NEW
	%MAIL-W-NONEWMAIL, no new messages

	MAIL> EXIT

The new mail count has now been reset to zero...

		Cheers, Ken
-- 
 Dr. Kenneth H. Fairfield    |  Internet: Fairfield@Slacvx.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: vmsnet.employment
From: hatamian@gandalf.rutgers.edu (ShAhin)
Newsgroups: vmsnet.employment
Subject: MS-Biomed Seeking Employment
Date: 19 Aug 92 18:17:30 GMT
Distribution: usa
Organization: Rutgers Univ., New Brunswick, N.J.



Hello,

A friend has asked me to post this for her. Please respond directly to her
or via email to me for a complete resume.
____________________________________________________________________________

Hi,

I am graduating in December '92 from NJIT with a MS in Biomedical Engineering.
I am currently employed by a well-known hospital products manufacturing
company as a Product Development Engineer. I am conducting my thesis research
concurrently at this company.
please feel free to contact me for a resume and/or to discuss my qualifications
further.

Thank you for your time.

Please call Elli at (201)644-9174

____________________________________________________________________________
From: ccoprbm@prism.gatech.EDU (bruce mccullough)
Newsgroups: vmsnet.employment
Subject: Re: Environmental/Civil Engineer
Date: 14 Aug 92 06:47:36 GMT
Organization: Georgia Institute of Technology

In article <1992Aug13.175229.1@csvaxd.csuohio.edu> venkatesh@csvaxd.csuohio.edu writes:
>
>                                     RAO V. SANTAPUR
>                                  2901 Euclid Ave # 724
One post to the wrong group is bad enough
BUT
several to the wrong group.
Certainly don't get interviews like that!

    
-- 
Bruce Mccullough-Tech Assistant   | "The sharpest sword cannot cut itself".
Office of Information Technology  | "Look into the book of mirrors and find 
Georgia Institute of Technology   | all the knowledge you will ever need to  
Internet: ccoprbm@prism.gatech.edu| know". -    The Teacher
Newsgroups: vmsnet.vms-posix
Subject: Re: name of VMS product has changed...
From: tp@mccall.com (Terry Poot)
Date: Wed, 19 Aug 1992 15:38:07 CST
Reply-To: tp@mccall.com (Terry Poot)
 <1992Aug18.223322.25145@src.honeywell.com> <1992Aug19.030903.3648@spcvxb.spc.edu> <1992Aug19.155548.8873@decuk.uvo.dec.com>
Organization: The McCall Pattern Co., Manhattan, KS, USA
Nntp-Posting-User: tp


In article <1992Aug19.155548.8873@decuk.uvo.dec.com>, corne@jc3100.enet.dec.com
(John Corne) writes:
>>I just tried flipping into Posix and doing a "man tar" on an idle 8650. It
>>took 15 seconds to get the first line of output, and the screen then updated
>>at a rate of about 1 line per second.

man is probably the worst case scenario, since it actually runs VMS help under
the hood. 

>Have you tried to uncompress the help library?  

It ran so slow that I checked to make sure I hadn't forgotten to decompress the
help library after an installation (I hadn't). It takes about 10 seconds to
start on a VS3100/76 with a decompressed help library.

[Sign of things to come? On a VMS system with POSIX installed, type (from VMS)
"Help VMS". Guess what you get! :-)]
--
Terry Poot <tp@mccall.com>                   The McCall Pattern Company
(uucp: ...!rutgers!depot!mccall!tp)          615 McCall Road
(800)255-2762, in KS (913)776-4041           Manhattan, KS 66502, USA
Newsgroups: vmsnet.vms-posix
From: pack@acd.acd.ucar.edu (Daniel Packman)
Subject: UCX bind to Multinet NFS
Keywords:  Can it be done?
Organization: Ntl Center for Atmospheric Research, Atmospheric Chemistry
Date: Thu, 13 Aug 1992 16:04:11 GMT

I tried a UCX bind to a specific NFS pseudo device.
From posix, I cd to the newly mounted directory and see no
files (and get no error messages).  This is Multinet 3.0H

--
Dan Packman     NCAR                             INTERNET: pack@ncar.UCAR.EDU
(303) 497-1427  P.O. Box 3000
                Boulder, CO  80307-3000        NSI/DECNET: 9583::PACK
Newsgroups: vmsnet.vms-posix
Subject: Re: posix for vms
From: tp@mccall.com (Terry Poot)
Date: Fri, 14 Aug 1992 08:18:37 CST
Reply-To: tp@mccall.com (Terry Poot)
Distribution: world
Organization: The McCall Pattern Co., Manhattan, KS, USA
Nntp-Posting-User: tp


In article <1992Aug13.121043.851@galaxy.gov.bc.ca>, ewilts@galaxy.gov.bc.ca (Ed
Wilts) writes:
>The Posix license is included.  You need media and documentation.  I do not
>know if the media has made it to CD yet since my DEC support person personally
>uploaded a copy for me a while back.

The media and docs are both on CD, in CONDIST and the OLD respectively.
--
Terry Poot <tp@mccall.com>                   The McCall Pattern Company
(uucp: ...!rutgers!depot!mccall!tp)          615 McCall Road
(800)255-2762, in KS (913)776-4041           Manhattan, KS 66502, USA
Newsgroups: vmsnet.vms-posix
From: kish@iasdvc.honeywell.com ()
Subject: Re: name of VMS product has changed...
Reply-To: kish@iasdvc.honeywell.com ()
Organization: HONEYWELL_IAC
Date: Tue, 18 Aug 1992 22:33:22 GMT


>[Followups to vmsnet.vms-posix]
|>
|>They could start by implementing the things that they said in a decus session
|>that they were going to implement. They went to a lot of trouble to set up a
|>satellite link to Italy so the developer could tell us what was in VMS Posix.
|>One of them was unix-style light-weight processes (complete with a cute drawing
|>likening a unix process to a sparrow and a VMS process to a vulture). I can
|>understand them wanting to get things out the door, but DEC hasn't acknowleged
|>anywhere I've seen that the performance stinks, and they haven't said they are
|>going to do anything about it. They are talking about Posix 1.1 as if it were
|>out, and it isn't, and they still haven't said whether it fixes any performance
|>problems (obviously, since they haven't acknowleged any performance problems).
|>
I saw a press release which has 1.1 in release the end of this month
( Insert your own humous comment  here).....

I did do some checking on a few of the performance issues....
"Compute bound process run slow" 
 I ran a c version of the whestone benchmark and it ran at a apparent rate
  of .5 of the VMS copy. As it turns out it was the fact that POSIX
  does dynamic links to the RTL. In this case I was calling a bunch
  of functions which each had to be linked on call ( at least the first time).
   This distorted the numbers to give the idea that compute bound process
    run slow.  Actally it turns out the intuitive answer is correct they run
    at the process speed.

I did some similar testing for "FORKED" things which did not look as bad
as native VMS immages but still no where close to ULTRIX.  Which to be honest
was really all I expected. 

|>Has anyone else noticed that lately all the marketting hype and even published
|>benchmarks are for software versions that aren't out yet? I've been reading
|>about Rdb 4.1 for a long time, I think since last year. It isn't out yet either,
|>but DEC has already published TPS numbers to convince everyone how great it is.
|>Slimy marketting.
|>--

We have 4.1 check your mail box! :) It just hit our door.

I dont know about  |>Slimy marketting or just a long process between field test
and shipping.  We do nearly as bad here shipping VAX software so perhaps
I am more aligned to the shipping side. Still I agree we could all do better.
Remeber DECSET for VMS announced for shipping Middle of LAST year and still
not at the gate! AGHHHHHHHHHHH
Newsgroups: vmsnet.vms-posix
Subject: Re: name of VMS product has changed...
From: tp@mccall.com (Terry Poot)
Date: Wed, 19 Aug 1992 15:34:01 CST
Reply-To: tp@mccall.com (Terry Poot)
Organization: The McCall Pattern Co., Manhattan, KS, USA
Nntp-Posting-User: tp


In article <1992Aug18.182842.3645@spcvxb.spc.edu>, terry@spcvxb.spc.edu (Terry
Kennedy, Operations Mgr.) writes:
>  Just think how much they're saving by not having to mail out urgent
>reminders
>to "do not install Rdb 4.1" "do not install Rdb 4.1A", etc.

I must have missed the "do not install Posix 1.0" letter. :-)

>  Seriously, there is a growing quality problem with DEC's software, and sup-
>porting the same product across N platforms (VAX/VMS, Alpha/VMS, VAX/Ultrix,
>RISC/Ultrix, ANY/OSF) is only going to make it worse.

Do you suppose that hyping it to the marketplace 6 months before it is ready
might be putting pressure on developers to get it out early, rather than taking
the time to make it work? As far as multi-platform support, it will certainly
take more resources, but often times a bug will be uncovered on one platform
that was latent on another. I'm not sure it intrinsically affects quality,
except to the extent that it increases the pressure to skip the testing, because
the developers are spread thinner. (So what does DEC do? Lay people off, of
course.)
--
Terry Poot <tp@mccall.com>                   The McCall Pattern Company
(uucp: ...!rutgers!depot!mccall!tp)          615 McCall Road
(800)255-2762, in KS (913)776-4041           Manhattan, KS 66502, USA
From: tp@mccall.com (Terry Poot)
Newsgroups: vmsnet.vms-posix
Subject: Re: intralanguage binding with VMS-POSIX (Fortran)
Date: 12 Aug 92 20:02:58 GMT
Reply-To: tp@mccall.com (Terry Poot)
Organization: The McCall Pattern Co., Manhattan, KS, USA
Nntp-Posting-User: tp


In article <1992Aug10.171214.1@mscf.med.upenn.edu>, buhle@mscf.med.upenn.edu
writes:
>POSIX stands for Portable Operating System Interface, which was started a
>group
>called /usr/planning (which evolved into USENIX?). 

They were called /usr/group, and are now called uniforum. Usenix is older and
separate, and is, I believe, still called Usenix.

Thanks for the informative post!
--
Terry Poot <tp@mccall.com>                   The McCall Pattern Company
(uucp: ...!rutgers!depot!mccall!tp)          615 McCall Road
(800)255-2762, in KS (913)776-4041           Manhattan, KS 66502, USA
From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
Newsgroups: vmsnet.vms-posix
Subject: Re: name of VMS product has changed...
Date: 19 Aug 92 07:09:03 GMT
Organization: St. Peter's College, US

In article <1992Aug18.223322.25145@src.honeywell.com>, kish@iasdvc.honeywell.com writes:
>  I ran a c version of the whestone benchmark and it ran at a apparent rate
>   of .5 of the VMS copy. As it turns out it was the fact that POSIX
>   does dynamic links to the RTL. In this case I was calling a bunch
>   of functions which each had to be linked on call ( at least the first time).
>    This distorted the numbers to give the idea that compute bound process
>     run slow.  Actally it turns out the intuitive answer is correct they run
>     at the process speed.
> 
> I did some similar testing for "FORKED" things which did not look as bad
> as native VMS immages but still no where close to ULTRIX.  Which to be honest
> was really all I expected. 

  I just tried flipping into Posix and doing a "man tar" on an idle 8650. It
took 15 seconds to get the first line of output, and the screen then updated
at a rate of about 1 line per second.

  I think this VMS Posix stuff needs more work 8-)

	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
Newsgroups: vmsnet.vms-posix
From: corne@jc3100.enet.dec.com (John Corne)
Subject: Re: name of VMS product has changed...
Reply-To: corne@jc3100.enet.dec.com (John Corne)
Organization: Digital Equipment Co. Ltd.
Date: Wed, 19 Aug 1992 15:55:48 GMT


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

>I just tried flipping into Posix and doing a "man tar" on an idle 8650. It
>took 15 seconds to get the first line of output, and the screen then updated
>at a rate of about 1 line per second.

Have you tried to uncompress the help library?  Takes up more space,
but is quicker to start printing.  (This doesn't help much with the
delays per line though, which is a side effect of the way man uses help to
do its work).  I can't say I like the way man works from within the POSIX shell,
either.
---------------------------------------------------------------------------
John Corne ( Jc )
All views are my own unless expicitly stated otherwise.
Newsgroups: vmsnet.vms-posix
Subject: Re: name of VMS product has changed...
From: tp@mccall.com (Terry Poot)
Date: Thu, 20 Aug 1992 09:08:13 CST
Reply-To: tp@mccall.com (Terry Poot)
 <1992Aug18.182842.3645@spcvxb.spc.edu> <1992Aug19.153401@mccall.com> <1992Aug20.011559.3656@spcvxb.spc.edu>
Organization: The McCall Pattern Co., Manhattan, KS, USA
Nntp-Posting-User: tp


In article <1992Aug20.011559.3656@spcvxb.spc.edu>, terry@spcvxb.spc.edu (Terry
Kennedy, Operations Mgr.) writes:
>  I'll close with a comment on timely SPR answers. 

They answer them? That's news. They've never answered mine. I don't know how
many I've ever sent in, but I certainly know there's at least one, and it's
never been answered. (It's at least 3 years old now, a documentation error in
the Linker manual. It's wrong in a very obscure case that I can no longer
remember having to do with shareable images and clustering and link options.)

>I filed a SPR against
>VMS V4.1, complaining that it didn't operated the TSV05 in high speed mode.
>I got the usual "fixed in a future release". I forgot about it. Years (many)
>went by. Well, guess what! It's fixed. In VMS V5.4-1. Amazing turnaround. It
>was a missing register save.

How about qsort in VAX C? They've even fixed that one, they just won't release
the fix to us. (Digital has it now, but they won't share.) A flag isn't being
initialized. Not a major big deal, but many VMS upgrades have gone out, and the
fix hasn't been in any of them. (Disclaimer: I haven't looked at 5.5-1 yet, but
I've given up on them _ever_ actually shipping the fix.)
--
Terry Poot <tp@mccall.com>                   The McCall Pattern Company
(uucp: ...!rutgers!depot!mccall!tp)          615 McCall Road
(800)255-2762, in KS (913)776-4041           Manhattan, KS 66502, USA
From: tp@mccall.com (Terry Poot)
Newsgroups: vmsnet.vms-posix
Subject: Re: Device names in Posix
Date: 12 Aug 92 18:56:15 GMT
Reply-To: tp@mccall.com (Terry Poot)
Organization: The McCall Pattern Co., Manhattan, KS, USA
Nntp-Posting-User: tp


In article <1992Aug7.163152.804@galaxy.gov.bc.ca>, ewilts@galaxy.gov.bc.ca (Ed
Wilts) writes:
>UCX BIND DISK2 "/disk2"
>UCX BIND BCSC$DISK2 "/bcsc$disk2"

I'm not sure which of 2 possible questions you are asking, so:

I don't use UCX BIND, I use POSIX 'mount'. It works fine for me using a logical
name for the device name, for instance:

psx> mount 'x1:' /x1
psx> mount
...
MIS1$DKA500: on /x1

>
>where BCSC$DISK2 is a logical name pointing to DISK2
>
>This gives me the error message:
>BINDERROR, Error processing BIND or UNBIND request
>DEVMOUNT, device is already mounted

If you want to provide 2 directories mapped to the same device, how about
symbolically linking one of them to the other? BIND one of them, and then within
Posix use ln -s to link the additional device name to the one you bound.0

>
>The problem is that we multiple logical names pointing to the same physical
>device.  For example, we may have another group ENV$DISK1 that also points to
>DISK2.  The user's default may be something like
>BCSC$DISK2:[BCSC.USERS.EWILTS]

Is that the only reason you want to do this? Why do you need it. Consider the
following:

MIS1$ sh def
  PSRC:[MISC]
MIS1$ sh log psrc
   "PSRC" = "X1:[PUBLIC.]" (LNM$SYSTEM_TABLE)
MIS1$ posix
psx> pwd
/x1/public/misc
psx>

(The output of mount showing /x1 is above.) Note that in this case my default
was to a directory using a rooted logical, and it still got it right. It appears
to:

1) Translate the current default down to a physical device and directory string
2) Scan the mount table for that device, and use that as the first element of 
   the path.
3) Attach the directory spec, suitably converted.

I've never seen it miss if the disk is actually mounted to posix. Did you do a
POSIX 'mount' after the UCX BIND? The docs say that if you use UCX BIND you have
to do a mount (no parameters) in POSIX for POSIX to recognize the newly bound
device. Could that be your problem?
--
Terry Poot <tp@mccall.com>                   The McCall Pattern Company
(uucp: ...!rutgers!depot!mccall!tp)          615 McCall Road
(800)255-2762, in KS (913)776-4041           Manhattan, KS 66502, USA
Newsgroups: vmsnet.vms-posix
From: rankin@eql.caltech.edu (Pat Rankin)
Subject: `man' output
News-Software: VAX/VMS VNEWS 1.41    
Organization: California Institute of Technology
Date: Wed, 19 Aug 1992 22:12:00 GMT

[previous subject line: "Re: name of VMS product has changed..."]
In article <1992Aug19.030903.3648@spcvxb.spc.edu>, terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) writes...
>   I just tried flipping into Posix and doing a "man tar" on an idle 8650. It
> took 15 seconds to get the first line of output, and the screen then updated
> at a rate of about 1 line per second.

     You are encountering two substantial problems with the initial VMS
POSIX implementation here.
 (1) `man' is implemented as `dcl help vms_posix | more' or some permutation
thereof.  The terminal output from "normal" VMS then has to be translated
into POSIX terminal output; this conversion slows things down considerably,
particularly if you've invoked POSIX from the DCL prompt instead of as the
native CLI, because then you probably get a double whammy of converting the
POSIX output back to regular VMS tty output.  Logging in with /CLI=POSIX$CLI
makes a difference, and regular POSIX output in that environment is not slow.
 (2) the help library entry for VMS_POSIX is a huge monolithic entry that
yields slow processing from the librarian.  My suggestion (to a V1.1 beta
tester, for forwarding to the developers as field test feedback...) was to
move the POSIX details into a separate library and eliminate one or two
levels of keys needed to reach the topics of interest;  access should be
noticeably faster.  Only the POSIX invocation details need to be in the
regular help library, and they should be listed under the command name
"POSIX" instead of the product name "VMS_POSIX".

     Some of the `man' text which is in two-column format is pretty awful.
The columns are so narrow that they require excessive continuation lines
to cover anything.  (See `$ help VMS_POSIX Shell_commands stty Operands'
for example.)

		Pat Rankin, rankin@eql.caltech.edu
Newsgroups: vmsnet.vms-posix
Subject: Re: name of VMS product has changed...
From: tp@mccall.com (Terry Poot)
Date: Wed, 19 Aug 1992 15:30:53 CST
Reply-To: tp@mccall.com (Terry Poot)
Organization: The McCall Pattern Co., Manhattan, KS, USA
Nntp-Posting-User: tp


In article <1992Aug18.223322.25145@src.honeywell.com>, kish@iasdvc.honeywell.com
() writes:
>We have 4.1 check your mail box! :) It just hit our door.

So if I'm real lucky, it'll be on the September CONDIST. 

>I dont know about  |>Slimy marketting or just a long process between field
>test
>and shipping.  

They should insert the same time interval between field test and marketting. I
miss the good old days when DEC's hype releases ended with the phrase "available
now".
--
Terry Poot <tp@mccall.com>                   The McCall Pattern Company
(uucp: ...!rutgers!depot!mccall!tp)          615 McCall Road
(800)255-2762, in KS (913)776-4041           Manhattan, KS 66502, USA