HDTenEightyP/NetNews huggingface dataset:
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: VAX c
Date: 27 Dec 1992 07:49:17 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 <26DEC199216542325@spades.aces.com>, gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546) writes:
>Actually since you can easily get from FILE * to the FAB, and
>the FAB gives you FAB$L_RAB which gives you the RAB, you do
>have to 'go all the way back to the FAB.'

Ah, I get to flame Ehud!!!!!

Sorry, Ehud, but there's no such thing as FAB$L_RAB.  It's the other way
around:  There *IS* a RAB$L_FAB; think about it for a minute:  You can have
many streams (RABs) associated with a single FAB, but not vice versa.  So a
Record Access Block refers to a File Access Block, not the other way around.
Look at it in another way:  First you $OPEN (which requires only a FAB), then
you $CONNECT (which requires a RAB), so you don't need a RAB when you use a
FAB, but you *DO* need a FAB when you use a RAB.

>Undoubtedly the C compiler makes intimate use of this 'unsupported
>and undocumented' (unlikely to change at any time although no one
>will admit to it) featuere.

Certainly the C compiler uses RABs.  It's just the routine that tells you WHERE
the RAB associated with your stream is located that's undocumented and
unsupported.  I think it's a pretty major failing of the VAXCRTL that it
doesn't have a documented, supported (and disparaged) routine that does this.
--------------------------------------------------------------------------------
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: marshall@NEBULA.SSD.LMSC.LOCKHEED.COM (Bob Marshall)
Newsgroups: comp.os.vms
Subject: Re: Butthead
Date: 28 Dec 92 22:49:47 GMT
Reply-To: marshall@NEBULA.SSD.LMSC.LOCKHEED.COM
Organization: LMSC, Sunnyvale, California

In article <1992Dec28.190505.7144@chpc.utexas.edu>, michael@chpc.utexas.edu (Michael Lemke) writes:
>In article <1992Dec28.120521.5916@ais.com> bruce@ais.com (Bruce C. Wright) writes:
>>In article <01GSUDDQDUHE8WWCGW@kopc.hhs.dk>, ARNE@KOPC.HHS.DK (Arne Vajhxj) writes:
>>> 
>[...]
>>> 
>>> Besides lowering the blood-preasure for certain individuals then YOU
>>> WILL GET MORE AND BETTER ANSWERS if your posting includes:
>>> 
>>>   - a detailed description of the problem
>>>   - software names and versions
>>>   - exact error-messages and/or log-files
>>>   - a valid email-address
>>
>>These are good points, and I hope that everyone takes them to heart.
>
>You forgot the presumably most important one:
>
>     - the command(s) exactly as typed (including all qualifiers and stuff)

And, another one that often gets omitted and renders the question
unanswerable :

 - What are you expecting to happen? (or, more generally : Just what exactly
      are you trying to do?)

And, another one that is sometimes useful :

 - Has this ever worked for you before, and if so, what relevant changes
      occurred on your system since that time?

=============================================================================
Bob Marshall                     \\     "Women aren't as smart as they
Lockheed Missiles & Space Co.     \\     think they are; they think we
Sunnyvale, CA                      \\    men know a lot more than we
marshall@force.ssd.lmsc.lockheed.com\\   really do."
"I tell the truth 'cept when I lie"  \\     - Tim the Toolman
=============================================================================
From: 00mjstum@leo.bsuvc.bsu.edu (Matthew J. Stum)
Newsgroups: comp.os.vms
Subject: THE solution (was Re: NEWMAIL COUNT incorrect..)
Date: 23 Dec 92 14:15:05 GMT
Organization: Widget Enterprises

bandy@netnews.jhuapl.edu (Mike Bandy) writes:
> TARKA10@SNYBUFVA.BITNET (Mark Tarka) writes:
> 
>>Ehud Gavron had apparently solved a problem with phantom newmail counts.
>>I never saw the original traffic on the topic.  I'm a user here on
>>campus; during the login, I'm given the message that I have n mail
>>messages -- there is a residual of four, now five, which do not exist.
>>If I could get a solution to this problem, I could forward it to the
>>appropriate desk for action.  Thanks.
> 
> Neither did I, but I remember my old boss' 10 lines of DCL (copy this;
> mail that; delete other;...) to fix the problem.  I innocently asked him 
> why he didn't just do a READ/NEW from within mail.  He about went 
> through the ceiling!  I hope the portion of the thread I've missed
> was not a lengthy solution to a trivial problem.  However, I don't 
> remember whether the READ/NEW clears the count, or decrements it.

It clears the count to 0... but _ONLY_ if you have no new mail messages.
If you have real live new mail messages and your count is messed up, typing
READ/NEW will _not_ correct the count.

Ehud's "definitive" answer to the problem wasn't exactly comprehensive.  It
should read something like:

"Type READ/NEW, reading any new mail that you have, until you get
the "%MAIL-W-NONEWMAIL, no new messages" message."

Or, if you prefer, the answer from the Mail Utility manual, section 9 (System
Management and MAIL), page MAIL-15:

"If the number of new (unread) mail messages displayed on your screen is
inconsistent with the actual number of new messages, enter the READ/NEW
command when there is no new mail."
        ^^^^^^^^^^^^^^^^^^^^^^^^^

-- 
Matt Stum                    Gwydion ap Myrddin       Ball State University
00mjstum@leo.bsuvc.bsu.edu   Shire of Afonlyn, MK     Muncie, IN  USA
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: HELP!!! Security problem for gurus.
Date: 22 Dec 1992 05:19: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 <9212211720.AA15326@ucbvax.Berkeley.EDU>, simons/G=Colin/I=CB/S=Sewell/O=H.A.Simons.Ltd/OU=CORP@mhs.attmail.com writes:
>	Yup, ACL's won't protect you. Another priv that can get around ACL's
>is one that is given to operators and special backup accounts so they can read
>all files on a disk for backup purposes: READALL priv. What most of the people
>around here didn't know was that this priv also grants you implicit write access
>to all files!

Yup.  READALL is a terribly misnamed priv.  IHNSHO, DEC should've called the
priv BACKUP, since that's what it's for.  The priv was introduced (if I
understaned things correctly) as an alternative to BYPASS for accounts that
were supposed to be doing BACKUPs.  Of course, to do a useful BACKUP of a disk,
you need to be able to read every file on the disk.  Hence the name READALL. 
But wait!  There's more!  To do a BACKUP/RECORD, you ALSO need to be able to
modify the file header.  Given the way ODS-2 works (if you want details, either
buy the book or e-mail me for the 1978 description), this pretty much means
that you've got complete control (C access, in ACL-speak) of the file.  That's
what READALL originally gave you.  I understand they took away the control
access part in one version of VMS, but gave it back again when all the people
who'd set up their BACKUP procedures counting on the ability to record BACKUP
dates with just READALL priv complained.
--------------------------------------------------------------------------------
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: powers@ELROS.STG.TRW.COM
Newsgroups: comp.os.vms
Subject: RE: openVMS or UNIX
Date: 29 Dec 92 03:18:05 GMT
Distribution: world
Organization: The Internet

Mark Wood:
> Ah, another definition to add to the pile.  One reason that I try never to use
> the term "open system" is that it has no commonly-accepted definition

Sorry to add to the deeply stupid literature on this subject, but, well,
I entirely hate the way idiot marketing jargon is being used to convert the
computer business into a flea market for scams.  Now, if we could just agree
to treat this junk for what it is, the same stuff as the drugstore paper junk
mail we all have to throw in the trash every week....
From: 2020211@SAPHIR.ULAVAL.CA (Sylvain Chamberland)
Newsgroups: comp.os.vms
Subject: Re: Convert MSDOS or UNIX text format to VMS format
Date: 31 Dec 92 04:46:31 GMT
Reply-To: 2020211@SAPHIR.ULAVAL.CA
Organization: CTI, Universite Laval

In article <1hs8glINNnqs@gap.caltech.edu>, carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
>In article <1992Dec30.085139.3959@cerberus.ulaval.ca>, 2020211@SAPHIR.ULAVAL.CA (Sylvain Chamberland) writes:

>>Here's my problem: I don't have any archive utility on my system here so I went
>>to get a C source for "zip" by anonymous ftp. The source was written so it could
>>be portable, and I got the VMS supplementary files.
>>
>>But it appears the source is not in a VMS format, because the VAX EDIT editor
>>will not accept any of the *.c or *.h files as files containing many lines. It
>>appears to me a whole file is considered as being composed of one or a few
>>lines by the editor or the compiler. The VAX C compiler ("CC") won't compile
>>the source, it does not seem to recognize the format.
>
>Sounds like you copied the files using IMAGE or BINARY mode.  You need to copy
>text files in ASCII mode.  If that's not the problem, then there's probably a

Of COURSE!!!!    Hahahahahahahahahahahahahahaha!

NOW we know why I'm a biology student and not in computer science!  ;-)

Indeed, I always change the type to binary when ftp-ing, and I did not think
about it this time...

I went to get the files again in type ascii this time, and it WORKED!

THANKS for solving my problem!  Thanks also to Eberhart Adam, Bruce Wright,
Paul White, Jasper Rees, David Robinow and Russ Evans (and, of course, Carl
Lydick) who also answered by private e-mail and who all provided me with
valuable information about VMS...    (at this time)
(Sorry if it begins to look like the gala for the Oscars...  ;-)   )

I think I'll stay around this newsgroup... I could not believe my eyes
yesterday when I found a newsgroup for VMS, but receiving an answer the very
next day...   :)     

I think I'm even beginning to LIKE VMS!!!   :)

>--------------------------------------------------------------------------------
>Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Sylvain Chamberland
2020211@saphir.ulaval.ca
From: leichter@lrw.com (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: re: MAIL problem (NOT newmail count :)
Date: 31 Dec 92 13:21:12 GMT
Distribution: world
Organization: The Internet


	Hey, I have a MAIL question, and it doesn't involve the NEWMAIL
	count.. :-)

	Anyway, it's nothing tragic, but I've been wondering for a long time
	now why we end up with a lot of MAIL.LIS files in our [SYSLOST]
	directories.  Here's my assumption based on what little detective work
	I've been motivated to do:  The MAIL.LIS files are temporary files
	used when PRINTing from MAIL... however, for some reason the MAIL.LIS
	file doesn't get deleted properly.  More like a SET FILE/REMOVE thing.

When mail spools files for printing, it never enters them into a directory in
the first place - it's not a matter of SET FILE/REMOVE, since there is no
entry to remove!  If you did a SHOW QUE/FUL on such a file, you'd see a
display like the following:

  MAIL            LEICHTER       818       5  Printing
    Submitted 31-DEC-1992 09:07 /FLAG=ONE /FORM=PORTRAIT (stock=DEFAULT) 
    /PRIORITY=100 /NOTRAILER
    File: _TOPS$DUA0:[]MAIL.LIS; (printing) /DELETE

Note the lack of a directory name in the file specification.

	The problem arises that we have quotas enabled on our user disks and
	it wreaks havoc with a user if (s)he prints a lot from MAIL.

	Is this normal?  Or do we have something set up strangely?  Is there
	another way around it besides routinely cleaning the [SYSLOST]
	directories of MAIL.LIS files?

It's "normal" in the sense that the software isn't doing anything unusual;
but it's NOT normal in that these files should not be hanging around.  The
spooler should be deleting them after they are printed.

It's hard to know WHY these files aren't being deleted.  You might want to
take a closer look at them the next time you get a bunch.  Were they all
created at about the same time?  Did something happen on the system at about
that time (like a crash?)

Some experimentation with MAIL seems to indicated that it doesn't actually
create an output file until you exit (or type PRINT/PRINT or PRINT/NOW), so
the problem is not something like people typing PRINT, then CTRL/Y and STOP -
although I suppose they MIGHT be able to cause the problem by noticing that
MAIL was taking a long time to exit, realizing that was because of some
forgotten PRINT command, then saying "Oh, I didn't really what that printed!")

	Hmmm... now that I think of it, I don't use PRINT/DELETE a whole
	lot... is this something connected with the queueing system and not
	MAIL?  I don't see anything about PRINT in the docs that would nail it
	down one way or another.

The files that MAIL spools are always temporary copies, and are always marked
/DELETE.  Of course, a user COULD modify the queue entry, causing the file to
stick around.  If people are under the misapprehension that the /DELETE on
the queue entry means that the ORIGINAL MESSAGE will be deleted, they might
fall into this trap.  But somehow I doubt it.
							-- Jerry

Newsgroups: comp.os.vms
From: marshall@NEBULA.SSD.LMSC.LOCKHEED.COM (Bob Marshall)
Subject: Re: Butthead - maybe we could finish it here?
Reply-To: marshall@NEBULA.SSD.LMSC.LOCKHEED.COM
Organization: LMSC, Sunnyvale, California
Date: Thu, 24 Dec 92 02:12:10 GMT

In article <1h9td8INN1c9@gap.caltech.edu>, carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:

[...representative excerpts of Mr. Lydick's typical flames follow...]

>It appears to me that the ignoramuses who think that they should be able to
>have other people run their systems for them are a lot more insecure than those
>of us who actually help people with their problems with VMS
>
>Well, to tell you the truth, I'm no more willing to suffer fools gladly in
>persan than I am over the net, dickhead (I'm also not so fucked up that I'll
>put asterisks in a word so I can try to pretend I didn't really say it;  can
>you say "hypocrisy"?  I knew you could!
>
>You know, that's EXACTLY what I was thinking about the various shit-for-brains
>assholes who don't think they need to know anything about VMS to manage a VMS
>system.
>
>That's understandable.  You don't seem to be able to  understand anything.  Why
>should this particular instance be an exception?
>
>Well, jackass, I've done the same.  You seem to be a royal dickhead (not a
>d*ckhead).
>
>Take a look at some of my posts from tonight.  I don't flame people
>indiscriminately.  I *DO* flame people who take pride in their willful
>stupidity.  Yourself included.

Carl, the more you try to defend your behavior, the deeper the hole you
are digging yourself into. Haven't you noticed that no one is rushing to
your defense? Maybe you ought to take your own advice and "get a clue".

=============================================================================
Bob Marshall                     \\     "Women aren't as smart as they
Lockheed Missiles & Space Co.     \\     think they are; they think we
Sunnyvale, CA                      \\    men know a lot more than we
marshall@force.ssd.lmsc.lockheed.com\\   really do."
"I tell the truth 'cept when I lie"  \\     - Tim the Toolman
=============================================================================
From: DGITLIN@JEFLIN.TJU.EDU (David Gitlin: Systems Manager & Analyst Scott Library)
Newsgroups: comp.os.vms
Subject: (none)
Date: 31 Dec 92 14:49:00 GMT
Distribution: world
Organization: The Internet

ADD DAVID GITLIN
From: SABRY@SHEBIN.EG (Sabry Kotob El-Ganzory)
Newsgroups: comp.os.vms
Subject: Question of anal/disk/repair...
Date: 3 Jan 93 09:06:00 GMT
Distribution: world
Organization: The Internet

Hello all
Please, when I issue this a commands:-
$ anal/disk/repair dia0:
%VERIFY-W-LOSTHEADER,file(1464,47,1) MAIL.MAI;
          not found in a directory
%VERIFY-W-INCQUOTA, QUOTA.SYS indicates 53 blocks used,actual use 57 blocks
for [300,24]
-------------------------------------------------------------------------------
Of coruse, for the first message I go [SYSLOST] then there are file MAIL.MAI
And the following reading and delete.... IS it a right??
For the second message, I want from anyone explain this a message ..
Also, How access with these a message??
Many Thanks..............
Sabry
E-mail:sabry@shebin.eg
From: bear@nuc.anu.edu.au (Bernhard Fabricius)
Newsgroups: comp.os.vms
Subject: Getting rid of SMB_SECURITY once and for all ?
Date: 23 Dec 1992 01:24:25 GMT
Organization: Nuclear Physics, ANU
Distribution: world
Reply-To: BEAR@NUC.ANU.EDU.AU
NNTP-Posting-Host: 150.203.19.47


Hi there,

	I seem to spend most of my "consultancy" time telling people how
to let user ? on machine X.Y.Z.Q display on DECwindows/Motif displays, and
am rapidly coming 'round to the opinion that the Session Manager's "Security"
feature is the most useless invention since the Electric Nostril Hair Remover.

	Stopping short of using my BYPASS privilege to modify each and every
user's DECW$USER_DEFAULTS:DECW$SMB_SECURITY.DAT file to

sm.versionid:	3.0
sm.host_list:	* * *
sm.num_hosts:	1

(basically because there are too many users who re-direct DECW$USER_DEFAULTS
from SYS$LOGIN, so it would take too long!), I was wondering if there is a way
to tell the server not to check "Security" at all, ie let all connections in,
or possible have a list of "secure hosts" (like the nodes in our cluster, for
crying out loud!) which can always get in regardless of the contents of the
user's SMB_SECURITY file ?


Cheers

Bernhard
--------------------------------------------------------------------------------
Dr Bernhard Fabricius              |
Academic VAX/VMS Support           |  "I am a Bear of Very Little Brain,
Department of Nuclear Physics      |           and long words Bother me."
Australian National University     |
                                   |                           - A.A. Milne
InterNet: BEAR@NUC.ANU.EDU.AU      |
    POSTMASTER@NUC.ANU.EDU.AU      |
From: simons/G=Colin/I=CB/S=Sewell/O=H.A.Simons.Ltd/OU=CORP@mhs.attmail.com
Newsgroups: comp.os.vms
Subject: Re: Bypassing missing F11BXQP on startup ?
Date: 29 Dec 92 22:38:31 GMT
Distribution: world
Organization: The Internet

V. Phaniraj writes:
|In article <9212290827.AA18530@ucbvax.Berkeley.EDU> you write:
|>
[...]
|>
|>    so, bring down the satellites, boot the server, then bring up each
|>    satellite node. hope this helps.
|
|yup, did that. Unfortunatley the satellite was locked up in a place
|inaccessible to me over Xmas break, so the cluster hung for 3 days.
|Moral: do a cluster shutdown before doing a standalone backup.
|

    we have the same situation: workstations in other buildings, etc.
    but having the workstations accessible doesn't help anyway; they're
    hung waiting for the server to come back. our operators came up
    with a solution: pull the ethernet cable off the server before bringing
    it back up.  then plug the cable back in; the satellites
    will promptly crash and reboot. admittedly this is rather drastic,
    but sometimes drastic solutions are neccessary.

						c sewell
						h a simons ltd.
						vancouver, bc
Newsgroups: comp.os.vms
Subject: RDB v4.1 performance degradation
From: williamsca@hirama.hiram.edu (Curtis Williams)
Date: 21 Dec 92 15:57:17 -0500
Organization: Hiram College
Nntp-Posting-User: williamsca

Hiram has recently upgraded to v4.1 of RDB on VMS 5.5-1.  Since that time we
have noticed a severe degradation in pre-compile time and build database time
for very large databases, say 200+ columns.  We have consulted with Digital who
has said that they have experienced no change in performance with the new
version, but they are looking at our problem.  I'm curious if anyone else has
seen a similar loss of performance.

-------------------------------------------------------------------------------
                        *** STANDARD DISCLAIMER ***
-------------------------------------------------------------------------------
Curtis Williams, Programmer/Analyst        | "Work hard, rock hard, eat hard,
Hiram College                              |  sleep hard, grow big, wear
Hiram, OH 44234  USA                       |  glasses if you need 'em."
Voice: 216-569-5314   Fax:   216-569-5462  |     -- The Webb Wilder Credo
-------------------------------------------------------------------------------
HIRAM: williamsca         BITNET: williamsca@hiramb
                        INTERNET: williamsca@hirama.hiram.edu
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: Apending a file at the end of mail.
Date: 22 Dec 1992 05:45:02 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 <21DEC199210505504@spades.aces.com>, gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546) writes:
>In article <01GSK4HGLSY800036I@MSUS1.MSUS.EDU>, TS117%BSU.DECNET@MSUS1.BITNET (TANDI SUNARTO) writes...
>#Ehud,
># 
>#Since I am a new user on VAX system, could you please elaborate your
>#explanation on how to append a file at the end of mail, for example :
>#tell me how to create an initiliazation file, and other stuff.
>
>This is in the FAQ list, so you might want to pick that up for more

[rather clumsy {since it needs a subprocess} answer deleted]

If you don't tend to edit files called MAIL$xxxxxxxx_EDIT.TMP except when
you're sending MAIL, then, if you've got your editor set to TPU, put the
following into a file pointed to by the logical name TPU$COMMAND:
PROCEDURE SIGNATURE
	LOCAL OUTFILE, OLDPOS;
	ON_ERROR
		POSITION(OLDPOS);
	ENDON_ERROR;

	OUTFILE := GET_INFO(COMMAND_LINE, "OUTPUT_FILE");
	OLDPOS := MARK(NONE);
	IF (SUBSTR(OUTFILE, 1, 17) = "SYS$SCRATCH:MAIL_") AND
		(SUBSTR(OUTFILE, 26, 9) = "_SEND.TMP") AND
		(LENGTH(OUTFILE) = 34) THEN
		POSITION(BUFFER_END);
		READ_FILE("SYS$LOGIN:SIGNATURE.");
		POSITION(OLDPOS);
	ENDIF;
	POSITION(OLDPOS);
ENDPROCEDURE

SIGNATURE;
--------------------------------------------------------------------------------
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.