HDTenEightyP/NetNews huggingface dataset:
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: HELP!!! Security problem for gurus.
Date: 3 Jan 1993 09:33:12 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 <1992Dec30.205836.3909@ncsa.uiuc.edu>, jsue@ncsa.uiuc.edu (Jeffrey L. Sue) writes:
=Good information... where is this documented?  That was the point of the
=original flame:  that others don't take the time to look it up in the
=documentation.  Again, you are correct that I don't know what I'm talking
=about here, which is why the question was raised, don't you think?  Questions
=are otherwise known as queries, and often used (at least by me) to find out
=information not known.  Remember, I did look through the documentation and
=this info was *not* easily found.

It's not (as best I know) directly documented.  However, the $ASCTIM and
$BINTIM system services are documented in the System Services Reference Manual
(though the on-line HELP information is sufficient).  Nowhere in this thread
have I even suggested that it was a matter of someone not taking the time to
look this up (other than by reading info-vax/comp.os.vms).  I pointed out that
you had to pick a time in the past in order to be safe.  I'd've thought that
most people using VMS would've been able to take that hint, the external file
names, the dates displayed by the MAIL utility, and the on-line help for the
system time services, and figure it out themselves (except, of course, for what
the high-order word of the low-order longword was there for).

=>=Gee... some of us have *real* jobs, some of which doesn't even apply to VMS.
=>=Actually, I know quite a bit of how VMS works, however little things like
=>=how MAIL determines what "bignumber" to use is of little value to me.
=>
=>I see.  You just couldn't be troubled to pay attention this issue last came up
=>(a couple of weeks ago) and was discussed in detail?
=
=Alas, scanning for information on Internet (or elsewhere) is not what I
=get paid for most - it's results for my customers.  If I don't get to
=the news services for a few days a bunch of messages get marked as read
=due to the lack of time... and I still never catch up.

But COMP.OS.VMS is a good way to learn enough about VMS to be able to provide
better results for your customers.  With a halfway decent news reader, you
ought to be able to find the threads that might be of interest to you
relatively quickly.
--------------------------------------------------------------------------------
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: SHOW/UNIBUS (was: What is XPDRIVER for?
Date: 3 Jan 1993 10:11:10 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 <1992Dec30.100239.1043@cmkrnl.com>, jeh@cmkrnl.com writes:
>> Using this command can crash your system.  
>
>Calling all readers:  Has ANYONE out there ever seen this actually happen?  
>If so, what devices were on the bus?

I've had it happen ONCE.  On a VAXstation-II, running VWS.  Of course, even
looking at that system cross-eyed seemed likely to crash it.
--------------------------------------------------------------------------------
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: olin@vger.cheme.cornell.edu (Steve Thompson)
Subject: Re: How to prevent the DEC login screen on VMS workstation?
Reply-To: olin@vger.cheme.cornell.edu
Organization: Chemical Engineering, Cornell University, NY
Date: Wed, 30 Dec 1992 11:46:10 GMT

In article <2347@sousa.tay.dec.com>, anderson@funyet.enet.dec.com (Paul Anderson) writes:
>You can eliminate the big "digital" logo by defining the logical name
>DECW$LOGIN_BACKGROUND to be the name of a command procedure that will display
>an image on the background behind the login box.
>
>For example, DEFINE /SYSTEM DECW$LOGIN_BACKGROUND "SYS$MANAGER:BACKGROUND.COM"
>
>BACKGROUND.COM could contain an XV command, for example.  If it does nothing
>useful, I would imagine you would get a plain background but the big logo would
>still be gone.

Pray tell me how to define DECW$DISPLAY when you're at an X-terminal and
not a workstation. I had heard that the translation of SYS$ERROR held
the display device, but this seems not to be the case (VMS 5.5-1).

Steve

---------------------------------------------------------------------------
Steve Thompson, System Mangler   Internet: thompson@cheme.cornell.edu
School of Chemical Engineering   Bitnet:   thompson@crnlchme
Olin Hall, Cornell University    Phone:    (607) 255 5573
Ithaca NY 14853
---------------------------------------------------------------------------
Newsgroups: comp.os.vms
Subject: Re: VMS 5.5-2 queueing!
From: kacovert@miavx1.acs.muohio.edu (Kent Covert)
Date: 1 Jan 93 08:00:02 -0500
Organization: Miami University Academic Computer Service"

In article <1992Dec30.095423.1@afit.af.mil>, dburkhol@afit.af.mil writes:
> We have just upgraded VMS from v5.4 to a5.5-2.
> We have not upgraded our queues as of yet due to comments from users
> at DECUS concerning DECs new queueing mechanism.
> Please post or mail any comments (good or bad) concerning DECs new
> queueing mechanism.
> Doug

We upgraded from 5.4-3 to A5.5-2 and then to 5.5-2 with very few problems.  The
only problem we saw was with DQS 1.2.  Queues that used the DQS$PRTSYM print
symbiont kept stalling, but DEC has a patch to fix this.

-- 
                                     Kent Covert, Software Coordinator
                                     Miami Computing and Information Services
                                     Miami University, Oxford, OH
                                     kacovert@miavx1.acs.muohio.edu  (internet)
                                     kacovert@miavx1                 (bitnet)
Newsgroups: comp.os.vms
From: winalski@adserv.enet.dec.com (Paul S. Winalski)
Subject: Re: cdd and c
Reply-To: winalski@adserv.enet.dec.com (Paul S. Winalski)
Organization: Digital Equipment Corporation, Nashua NH
Date: Tue, 22 Dec 1992 00:41:44 GMT


In article <9212212036.AA25675@top.magnus.acs.ohio-state.edu>,
Ung-Ho Yi <ungyi@magnus.acs.ohio-state.edu> writes:
|>
|>i am currently trying to include a string field from
|>cdd to my c program.
|>the string field in cdd was created for cobol, so when i tried to
|>include the field to my c program, i am one character short.

You've run into a fundamental problem here with the ways that the two languages
(COBOL and C) handle strings.  The string manipulation functions in C deal
with NUL-terminated strings.  COBOL does not.  There are two ways that you
can reconcile this difference:

1) In your C program, process the string without requiring the NUL terminator.
   This means avoiding functions such as strlen(), strcpy(), and the %s
   formatting directive in printf(), all of which assume that a string is
   NUL-terminated.

2) Define the field in your CDD record to be one character bigger than it
   has to be (this is the CDD equivalent of saying char x[7] when you want x
   to hold a string with 6 characters in it).  Then just ignore the last
   character position in your COBOL code.

It depends on your application which of these solutions is easier to implement.
For example, if the field represents existing data in, say, disk file records,
you have no choice--the format is dictated by the data on disk and your C code
will just have to avoid using the functions that depend on a NUL terminator.
On the other hand, if you are designing the whole application now, you can
make the string field one bigger than it has to be, to accomodate C's NUL
character.

--PSW
From: dfilip@colornet.com
Newsgroups: comp.os.vms
Subject: Re: Flaming and Such
Keywords: flaming
Date: 2 Jan 93 15:58:04 GMT
Distribution: world
Summary: flam'in flamers
Organization: ColorNet Information Systems

Has anyone done any stats in this newsgroup as to :

	- articles related in some way to computers or VMS
	- original flames
	- flames to people who have flamed
	- flames to people who have flamed people who have flamed
	- flames to people who have flamed people who have flamed people
	  who have flamed ...

	etc.

My guess is that if people would ignore the original flame, that 90% of all
flame traffic would be eliminated.

Oops ! Is this a flame ?!

Regards,

Dave.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=   David E. Filip                UUCP   : dfilip@colornet.com              =
=   ColorNet Information Systems  CIS    : 76430,3111                       =
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=    If David Cutler had been a heavy drug user in the 60's, he probably    =
=                    would have written Unix instead ...                    =
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
Newsgroups: comp.os.vms
Subject: Re: C-Kermit
Date: 22 Dec 92 08:25:31 GMT
Organization: St. Peter's College, US

In article <9212220212.AA04730@ucbvax.Berkeley.EDU>, MORRIS@PATRICK-PIMS.AF.MIL ("Jay Morris") writes:
> Ok, I've seen references to C-Kermit which is supposed to be much better than
> Kermit-32, but I can't find it.  I've searched by archie, i've looked on
> WATSUN, but I can't find it.  Evidently, I'm not looking for the right filename
> .  
> Someone want to point me in the right direction?

watsun.cc.columbia.edu:kermit/b/ck*

	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: comp.os.vms
From: zrepachol@cc.curtin.edu.au
Subject: Semantics of append of files.
Organization: Curtin University of Technology
Date: Mon, 28 Dec 1992 15:44:34 GMT

In article <1992Dec27.100810.300@rlgsc.com>, gezelter@rlgsc.com writes:
> In article <1hjmn7INN34t@gap.caltech.edu>, carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
>> In article <1992Dec26.100030.299@rlgsc.com>, gezelter@rlgsc.com writes:
...
> Carl,
>  
> I would be interested in hearing exactly what type of file that 
> you had that problem of partial blocks with. I have been using 
> this solution in a range of applications for about 15 years on 
> both RSX and VMS and have never encountered the behavior that you 
> describe.
>  

Your example is a little bogus, as it only uses 1 block. The problem Carl
refers to is a implementation detail to imcrease data integrity on an append.

Remember that the data will look like:
...[record-size]lastrecord in file....[-1]0000000... to the end of the block.

The end of file pointer should enable us to locate the [-1] record length
( no more data in this block ) word, but, where is the begining of the record?
We will have to move part of it *AT LEAST* into a buffer so we can append to it,
but we don't know how much. So we would have to block *ALL* access to the file
while we start the append. In fact, we may have several records in our buffer,
but how are we to know, unless we read ALL the file first...

The other way is to start the append at the begining of the next block, and
stay away from the previous record. This would allow us to reliably interlock
record access by locking a)the non-existant last-plus-one record in the previous
block, and b) the record we are about to append, updating EOF, and deq'ing the
record locks.

This is the origin of the puzzeling "I copyed 400 blocks of data from a bunch
of files into one, and I've lost 40 blocks..." plea for help. The copy is a
RECORD operation, and drops the empty space on the floor.

~Paul
From: powers@ELROS.STG.TRW.COM
Newsgroups: comp.os.vms
Subject: RE:  Butthead
Date: 29 Dec 92 01:33:21 GMT
Distribution: world
Organization: The Internet

Ehud writes, on this lively topic:

>        CAN WE END THIS STUPID THREAD?

Oh why?  There are some of us who are off for the holidays, otherwise bored
as heck, and enjoying the whole thing immensely.  I know, some other people
are actually working, but bored people have their rights too.

Besides, a flame war or two might serve an educational purpose.  Like an
earlier poster, I detest the phrase "I don't subscribe to this list, so...."
If it costs a buck a message to receive the stuff then so state!

As to Sabry, well, I think I recall that he said early on that he is marooned
without the benefit of access to any VMS manuals.  His boss just came out of
the blue and stuck him with the VAX cold, with no manuals, no support, and in
general no nothing.  That might be worth a note before he is overly picked on.

    Lester Powers
    powers@elros.stg.trw.com
    (whose company, in its infinite wisdom, has turned off our nameservers
    for the holidays, so inbound E-mail isn't likely to work)
From: dan@ttisms.com
Newsgroups: comp.os.vms
Subject: Re: How do I use more memory?
Date: 28 Dec 92 21:40:46 PDT
Organization: Touch Technologies Inc., San Diego CA

> and boosted up my user authorizations to:
>    WSdef:          150     
>    WSquo:       163840    
>    WSextent:    163840
>    Pgflquo:     163840
> 
> Any advice would be greatly appreciated.

Hi,

What EXACTLY does a

  $ MONITOR PAGE

screen show you.

Also, after running your application that page faults, but before
logging off, do a:

  $ show process/account

This will show the PEAK WS and PEAK VIRTUAL counts and will make it
prety clear what the problem probably is.

Dan E.
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: Butthead
Date: 23 Dec 1992 00:45:26 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 <1992Dec22.211550.19290@bmw.mayo.edu>, bergerson@cvdv79.mayo.edu (Chad D. Bergerson) writes:
>It's a shame that some people have to be know-it-all jerks.  Anyone who flames
>or ridicules someone for asking a question is just insecure with what they know
>and are trying to make themselves look better.  Come on know-it-alls, didn't any
>of you ever have to ask for help before???

Yes, I did.  I did, however, take the trouble of subscribing to the group
before asking questions of the group.  I also took the time to look at threads
that appeared related to what I was doing, rather than assuming that the way to
do things was to learn as little as possible about the operating system and
continually ask questions to which I could've learned the answers by invoking
the HELP utility.

I was flamed in response to some of my early questions, in which I didn't
provide nearly enough information for someone to help me.  That's as opposed to
a number of people who've been posting in the last few months who:
	1)  Can't seem to learn to use the HELP command;
	2)  Ask questions of the group without bothering to subscribe;
	3)  Ignore answers;
	4)  Ignore related threads (well, of course they do, since they can't
	    be troubled to subscribe to the group);
	5)  Consistently fail to provide enough information for their questions
	    to be answered.  For example, how do you answer a "question" of the
	    form:  "Comment on this" where "this" is the output of the command
	    "SHOW DEV/FULL SYS$SYSDEVICE"?  Now, if the device were in mount
	    verification, of had allocation inhibited because of an error on
	    the bitmap, the "question" might almost be reasonable.  But when the
	    disk is apparently healthy, what are we to assume is being asked?

>No question is dumb and I would extend the same courtesies to someone with a 
>quetion that I would want when I have one.

I beg to differ.  A question that's asked several times, verbatim, without the
person asking the question troubling himself to read the answers he's received
*IS* dumb.
--------------------------------------------------------------------------------
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: bena@yoyo.cc.monash.edu.au (Ben Aveling)
Subject: DECW$TRANSPORT_COMMON not up to date ?
Organization: Monash University General Access Unix
X-Newsreader: TIN [version 1.1 PL8]
Date: Wed, 30 Dec 1992 10:34:57 GMT

Hi all, 

Technical question this one.  (-: Sorry :-)

For those on VMS 5.4 the correct minor ID of DECW$TRANSPORT_COMMON
is 00000D.  Thats what it is on the Vax Station at work
and that's what DEC say it should be, I asked.  However, having 
sent out some beta software I have had two people in different parts
of the world complain that their software don't run, and the problem
has been traced to DECW$TRANSPORT_COMMON having the wrong minor ID
of 00000C. ie. their DECW$TRANSPORT_COMMON is still at VMS 5.3

Does this sound familiar to anyone ?  If so, could you please E-mail
me and I'll post a summary to the Net.  If not, could I trouble
1 or 2 people who are on 5.4 to ANALYZE/IMAGE DECW$TRANSPORT_COMMON
and let me know what their minor ID is.  ( I think it's about the 5th
line, but I'm not at work now, so I can't check for sure. )

I hope this is clear, please let me know if it's not. One of the
customers was in the US, the other in Japan.  I'm in Australia.  What I
really need to know is is this mistake (which is what I assume it is)
common.

        Thanks in anticipation,

        Ben A :-)
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: EVE vs. TPU
Date: 23 Dec 1992 00:34:19 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 <22DEC199209223462@vax2.concordia.ca>, davek@vax2.concordia.ca (DAVID KURZMAN) writes:
>I keep on reading about TPU vs. EVE as editors.  Is TPU the default editor 
>on VMS.  What is the difference between EVE and TPU?  If someone can give 
>me a short description of the two editors I would appreciate it.  If this 
>is a FAQ, please forgive me as I am not sure where I can get the FAQ list 
>from.  I promise that I will read it once it is reposted.

TPU is the Text Processing Utility.  It is, basically, a programming language
in which to write editors, including lots of primitives that are real handy for
doing that sort of thing.  EVE, the Extensible VAX Editor, is an editor written
in TPU, and is the editor you get, by default, when you issue the command:
	$ EDIT/TPU
I say "by default" because it's possible to write your own editor, or modify
EVE (that's what the Extensible means), and save a section file.  Thereafter,
if you use the /SECTION qualifier on your EDIT command of define the logical
TPU$SECTION to point to your own section file, you're using your own editor
rather than EVE.
--------------------------------------------------------------------------------
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: tihor@acf3.NYU.EDU (Stephen Tihor)
Newsgroups: comp.os.vms
Subject: Re: VAX c
Date: 29 Dec 92 05:39:00 GMT
Organization: New York University

You could - of course - use RMS calls.  Thats documented.
Newsgroups: comp.os.vms
From: nowacki@porsche.net.com ( Michael Nowacki I.T. Database Contractor)
Subject: Re: cdd, c, and rdb 4.1
Organization: Network Equipment Technologies, Redwood City
Date: Wed, 23 Dec 1992 19:31:13 GMT

In article <9212231344.AA20322@top.magnus.acs.ohio-state.edu> Ung-Ho Yi <ungyi@magnus.acs.ohio-state.edu> writes:
>thank you to people who have responded to my c and cdd question.
>
>some one asked what the DEC said about my problem.
>i only spoke with one technical support person, and he said i
>should create another record for C language, which is the same advice
>i got from most of you.

one alternative would be to declare an integer in cdd that is the length
of the data element, so that routines that need to declare buffers for
the field in question can do the equivalent of

char[sizeof(CDD_INT) + 1] buffer_fld;

then you would have to have the 'c' source code ( a header file) declare
all the 'c' versions of data. you have to have 2 different mechanisms to
provide the same field in different languages. this option allows one field
and 1 size descriptor, rather than 2 distinct field definitions suporting
the same domain. just an alternative, they both are a nuisance.

>I would also like to respond to the rdb v4.1 because we just went 
>through with much difficulty.
>
>first was segmented string.  i am not sure about the exact problem,
>but here it goes.  our application program first stores 3
> bytes as segmented string,
>then later on the program adds more data on to the segmented string.
>this has always worked with rdb v4.0, but on rdb v4.1 it corrupted
>our database.  the DEC engineers had manually remove the bad pages.
>
>second problem was with selecting rows.  i heard this has to do with the
>optimization of the rdb....  some how, when we select rows and
>sort by some order, the query becomes very slow, much much slower then
>when we were using rdb v4.0.  so, we had to change some of our application
>programs again.

this news group is a great place to share the gory details of the querys 
involved and the indexes on the tables.
Did DEC concede that theses are bugs and not side effects of the architectural
changes in 4.1?
Newsgroups: comp.os.vms
From: odonovan@inmos.co.uk (Brian O'Donovan)
Subject: Re: Unable to delete file
Reply-To: odonovan@inmos.co.uk (Brian O'Donovan aka 'o-Dzin Tridral)
Organization: INMOS Limited, Bristol, UK.
Date: Thu, 24 Dec 1992 10:03:02 GMT

In article <009658B3.F3FE06A0.30649@VAX1.Bemidji.MSUS.EDU> ts117@VAX1.BEMIDJI.MSUS.EDU (TANDI SUNARTO) writes:
>Hi, everybody !
>
>I couldn't delete a file in my directory, eventhough I have set the
>protection of owner to RWED, yet I keep reeiving insufficient privelege
>or file protection violation message.
>
>What should I do ?
>
>Tandi.
>TS117@VAX1.BEMIDJI.MSUS.EDU


Do a DIR/SEC on the file, this will show you any ACLs as well as the UIC-based
protection.  You might have an ACL on the file which is denying you access.
Happens to me all the time...  If you have, then look at set file/acl.

If all you want to do is delete the file, try

SET FILE filename /ACL=(ID=*,ACC=R+W+E+D+C)

and then try deleting it.

If this does no good, then maybe post some more info, e.g. the output of
DIR/SEC.

  Cheers,

    'o-Dzin / Brian (isodonovan@isnet.inmos.co.uk) still no .sig!