HDTenEightyP/NetNews huggingface dataset:
From: DMILLER%BSU.DECNET@MSUS1.BITNET ("Prof. David Miller")
Newsgroups: comp.os.vms
Subject: VAX NOTES Help-key
Date: 29 Dec 92 03:37:00 GMT
Distribution: world
Organization: The Internet

Hi Netters:

I just installed VAX NOTES with no apparent problems. But when I started
playing with it, I found one "gotcha" that I need some help with. YES! I read
the installation notes again, and the release notes several times - even the
"Quick Summary" just in case.

When I hit the HELP key (PF2 on VT 100s), I get into the editor (TPU?) ok, but
get the following unhelpful message at the bottom of the screen:

	Parameter 1's data type, INTEGER, unsupported

and no keypad picture. TPU continues to work and I can hit a keypad key and
get an explanation ok. I can exit the help facility and get back to NOTES
without difficulty.

I spent hours mucking around in HELP and finally got a picture - so I know the
capability is hanging around someplace. Suggestions greatly appreciated.

Dave.

DMILLER@VAX1.Bemidji.MSUS.EDU
Bemidji (Minn) State University
From: lionel@quark.enet.dec.com (Steve Lionel)
Newsgroups: comp.os.vms
Subject: Re: Passing parameters to detached processes.
Date: 29 Dec 92 16:02:59 GMT
Reply-To: lionel@quark.enet.dec.com (Steve Lionel)
Organization: Digital Equipment Corporation, Nashua NH


In article <1992Dec29.020155.5303@news2.cis.umn.edu>, rao@moose.cccs.umn.edu 
(Rao Akella) writes:
>
|>
|>I'm running a command procedure in a detached process, invoking it as follows:
|>
|>	$ RUN SYS$SYSTEM:LOGINOUT/INPUT=PROC.COM/OUTPUT=PROC.OUT/DETACH
|>
|>Is there any way to pass parameters to PROC.COM?
|>

Not through the RUN command.  Some alternatives.

	1.  Specify /INPUT=PROC2.COM which contains the line:

		$ @PROC parameters

	2.  Use SUBMIT/PARAM

	3.  Use SPAWN (though you can't get a detached process this way.)

	4.  Use /ERROR="parameter string" and translate SYS$ERROR in the
	    procedure to retrieve the parameters.  You should probably
	    then do a $DEFINE SYS$ERROR SYS$OUTPUT.  This is a hack and
	    not something I'd recommend.
--

Steve Lionel                    lionel@quark.enet.dec.com
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
From: POSTMASTER@MANADON-ENGINEERING-COLLEGE.AC.UK (Keith Wain)
Newsgroups: comp.os.vms
Subject: Digital Hardware Help -Is thi the Place?
Date: 29 Dec 92 12:10:00 GMT
Distribution: world
Organization: The Internet

Can any-one point me in the right direction for a mailing list on Vax 
hardware problems? I seem to be forever trying to get strange combinations 
of kit to work and, while the anwsers could probably be solved by RTFM, I 
do not have the FM nor the F$ to BTFM!
cheers (and a HNY)!

Keith Wain

Newsgroups: comp.os.vms
From: lionel@quark.enet.dec.com (Steve Lionel)
Subject: Re: ballooning EXE size
Reply-To: lionel@quark.enet.dec.com (Steve Lionel)
Organization: Digital Equipment Corporation, Nashua NH
Date: Tue, 29 Dec 1992 18:06:03 GMT


In article <01GSUT89O7JK000J0I@XRT.UPENN.EDU>, BUHLE@XRT.UPENN.EDU 
("E. Loren Buhle, Jr. [-662-3084]", 215) writes:
|>
|>I have a problem with the size of an executable going from ~1,000 blocks to 
|>something on the order of 75,000 blocks. 
|>
|>What am I doing? I am charged with writing a small interface to some existing 
|>FORTRAN code. I have no control over the existing FORTRAN code and can only say 
|>that it makes extensive use of VAX-FORTRAN Structure/record/map statements. I 
|>don't own the large body of FORTRAN code and really don't relish the thought of 
|>rewriting it...
|>

Hi, Loren...

I suspect what is happening is that you are crossing over the ISD_MAX linker
boundary; the number of image sections above which the linker stops creating
demand-zero image sections.  If this happens, the linker will create
copy-on-reference image sections for any new read/write data it sees, 
regardless of whether or not it is uninitialized, thus making your image big.
To see if this is happening to you, look at the linker map for the number of
image sections, shown in the summary at the end.  If this is above 95, you're
probably seeing this problem.

The VAX FORTRAN release notes contain a section on how to deal with this.
The most important thing is to use the linker COLLECT option statement to
collect all the read/write PSECTs into a single cluster; or rather, two
clusters if possible, one for uninitialized storage and one for initialized
storage.

If your local arrays are data-initialized to zero, remove the static
initialization; replace it with a call to OTS$MOVE5 if needed.  Consider using
COMMON for your scratch storage if you know it won't be used by more than one
routine at a time.  Also, a forthcoming release of Fortran for OpenVMS VAX
will have an AUTOMATIC statement which will allocate the local array on
the stack, saving image space (but it won't be zero-initialized).
--

Steve Lionel                    lionel@quark.enet.dec.com
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
From: george@ramsey.cs.laurentian.ca (George Nassas)
Newsgroups: comp.os.vms
Subject: long, long, really long DCL commands
Keywords: dcl
Date: 28 Dec 92 17:24:53 GMT
Organization: Dept. of Computer Science, Laurentian University, Sudbury, ON

Hi all!  Happy holidays!

The manual tells me that DCL will gladly accept commands of 1024
characters although each individual line cannot go longer than 256
characters. Can anyone fill me in on how this works? I read all over
the FM for an example but couldn't find one.

At first I thought that I could get really long lines by going:

		$ 256 chars -
		  256 chars - etc...

but no way. What gives? I've stumped all my local experts.

Please bounce a reply to my address as well as the net as I'm
sometimes away for a week or two at a time. Thanks in advance.

- George Nassas
Newsgroups: comp.os.vms
From: HEGE@FINABO.ABO.FI (Kaj H{ggman DC)
Subject: Re: Butthead - maybe we could finish it here?
Organization: Abo Akademi University, Finland
Date: Wed, 23 Dec 1992 12:14:22 GMT
X-News-Reader: VMS NEWS 1.24

In <1992Dec22.211550.19290@bmw.mayo.edu> bergerson@cvdv79.mayo.edu 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. 

This is probably quite close to the truth.

At the same time it is one of the sad side effects of electronic mail
and conferences - people who are quite nice "face-to-face" can be real
d*ckheads when they get a chance to be "anonymous".

Here at the University there are usually a few cases (1st year students) 
every year, but they always grow up and learn how to behave.
Some people just don't seem to learn that at home.

>Come on know-it-alls, didn't any of you ever have to ask for help before???

Quite right. What I really don't understand is, why anybody bothers to write 
loooooong flames and waste their (probably) valuable time, when one could
just skip the message and go to the next one?
 
> No question is dumb and I would extend the same courtesies to someone with a 
> quetion that I would want when I have one.

If I don't remember wrong you are even taught that at school (at least
over here). It should be part of everybody's education.

SO:
- all of us don't know the answers to all questions
- all of us (like me) don't speak or write English fluently - that doesn't
  make us less intelligent (no comments about me :-)
- all of us even don't know how to RTFM (I hope I do)

That shouldn't prevent us from using this magnificent resource - the net -
in order to solve our problems better and faster than anyway else,
should it?

Maybe the typical FAQ's don't need to be followed up (we don't want
to read the answers, nor the flames), they could just be replyed?

AND, you could read your posting (at least once) before you post it 
(believe it or not, I did that). 

I dunno.

Anyway, Merry Christmas And A Happy New (less flamey :-) Year 1993!

Regards,
-=HeGe=-

Kaj Haggman             Internet: Hege@abo.fi     Phone:   +358-21-654467
Abo Akademi University  Bitnet:   Hege@finabo     FAX:     +358-21-654497
Computing Center        PSImail:  22101410::HEGE
SF-20500 Abo, FINLAND   X.400:    s=hege o=abo prmd=inet admd=fumail c=fi
From: bruce@ais.com (Bruce C. Wright)
Newsgroups: comp.os.vms
Subject: Re: Alternative callable editors in MAIL?
Date: 26 Dec 92 21:37:21 GMT
Organization: Applied Information Systems, Chapel Hill, NC

In article <1992Dec26.185949.27176@engage.pko.dec.com>, cantor@star.enet.dec.com (Dave Cantor) writes:
> In article <1992Dec25.234751.5910@ais.com>, bruce@ais.com (Bruce C. Wright) writes...
>>In article <34147@twics.co.jp>, burress@twics.co.jp (Tim Burress) writes:
> [...]
>>> So my question is whether there is a procedure for installing a different
>>> callable editor, and having MAIL use that one instead of EDT.  I know it's a
>>> longshot, but the alternative is using the callable mail routines to write my
>>> own mailer, and it's not how I planned to spend my holiday.
>> 
>>You can very often set things up so that almost any editor can be used as
>>a callable editor in MAIL.  For example, suppose you have a locally-written
>>editor named XYZ -- what you need to do to make it callable from MAIL is:
> [...]
>>    2)  Have a procedure named XYZ$EDIT in the sharable image.  The
>>	arguments should look like the callable EDT interface routine
>>	named EDT$EDIT, although I think you can just get by with 2
>>	arguments for callable MAIL (input_file, output_file).
> 
> If the editor is named XYZ, then the entry point needs to be named
> XYZ$XYZ, not XYZ$EDIT.   (The entry points for some popular editors
> are TPU$TPU, LSE$LSE, and TECO$TECO.)

Are you _quite_ sure about this?  Did the behavior change recently?  I've
just tried this on a VMS V5.4 and a VMS V5.5 system, and if you name the
entry point, for example, XYZ$XYZ instead of XYZ$EDIT, then MAIL gives
you the error messages:

	%MAIL-E-ERACTED, Error activating editor XYZ
	%LIB-E-KEYNOTFOU, Key not found in tree

but naming the entry point XYZ$EDIT works as I had originally outlined.

Another anomoly that I've run across in trying this out on a couple of
VMS V5.4 systems is that if you're running DECUS UUCP, you may need to
install the XYZSHR image after all.  It seems that UUCP installs MAIL
with SYSPRV, and MAIL then won't activate the XYZSHR image (to avoid
possible security holes).  But if you're running stock VMS, then you
can avoid installing the sharable image and it all works OK.  Guess I
hadn't run across this before because when I first did that, some years
back, UUCP wasn't running on that particular VAX;  and after that, the
private editor image had usually been installed.  And when I ran a
test before my first article to make sure my memory was correct, it
worked because the machine I tested it on wasn't running UUCP.  Grrr :).

Bruce C. Wright
From: dburkhol@afit.af.mil
Subject: VMS 5.5-2 queueing!
Organization: Air Force Institute of Technology
Date: Wed, 30 Dec 1992 04:54:23 GMT

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
Xref: sparky comp.os.vms:19902 gnu.gcc.help:2815
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms,gnu.gcc.help
Subject: Re: Loading gcc 2.2 from Mango
Date: 26 Dec 1992 20:21:03 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 <gnusenet1992Dec20.232210.23638@bnlux1.bnl.gov>, kushmer@bnlux1.bnl.gov (christopher kushmerick) writes:
>following the friendly advice of one reader, I am adding the following 
>information to this post
>
>Hardware: uVax II
>
>OS	: VMS 5.1
>
>Trying to run the DCL file KITINSTAL.COM.
>
>
>In article <1992Dec19.032718.1102@bnlux1.bnl.gov> kushmer@bnlux1.bnl.gov (christopher kushmerick) writes:
>>I grabbed the files from mango for gnu gcc 2.2  . From the first file, 
>>I used backup to extract a file, KITINSTAL.COM, which is a com file that
>>builds everything.

OK, that's where you made your mistake.  You're not supposed to extract
KITINSTAL.COM, you're supposed to use the VMSINSTAL utility to do it all for
you.  You use a command of the form:
	$ @SYS$UPDATE:VMSINSTAL product_name location_of_product
VMSINSTAL then extracts the files from the saveset and invokes KITINSTAL.COM.

>>
>>However KITINSTAL.COM dies on my computer after asking for a top
>>directory for BISON. The comment is "Object of call not found" or 
>>something close to that.

Please, you're talking about a computer program here, not a game of horseshoes:
CLOSE DOESN'T COUNT.  Now, basded on your fundamental mistake (trying to do
thing by hand instead of using VMSINSTAL, you're probably running afoul of a
callback to VMSINSTAL.

>>Has anyone else had trouble with this instal com file? Has it worked fine for
>>people?

Anybody else who tried using it the way you did undoubtedly had the same
problem.

>>I tried telling it that I did not want to install bison. It dies anyway
>>with the same message. So I doubt that the problem is with setting up the
>>Bison directory.

The problem is that it's trying to make a callback to a procedure you're not
running.

>>Has anyone modified the install com to work? If so, could you mail me your
>>version?

You don't want to modify it, you just want to run it in its intended
environment:  Via VMSINSTAL.
--------------------------------------------------------------------------------
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: moeller@gwdgv1.dnet.gwdg.de ("GWDGV1::MOELLER")
Newsgroups: comp.os.vms
Subject: re: EDT/TPU and VMS V6
Date: 28 Dec 92 18:37:32 GMT
Distribution: world
Organization: The Internet

Don Stokes <wupost!waikato.ac.nz!comp.vuw.ac.nz!zl2tnm!toyunix!don@UUNET.UU.NET>
writes:

>>   And to think... TPU becomes the default editor under VMS V6.0.
>>   Oh the horror! ;-)
>
> Not on my system.  (He says, despairing of finding enough space to put
> 5.4 up on....)

I can't but expressly agree with Don!

OTOH, such heroic decisions get hairy over time, like (from SYS$SYLOGIN):

| $ B*ACKUP == "BACKUP/NOASSIST/IGNORE=LABEL"	! VMS V5 workaround
...
| $ if f$mode().nes."INTERACTIVE"
| $ then
...
| $ if f$type(backup).nes."" then	-
| 	B*ACKUP == backup - "/NOASSIST" 	! VMS V5.1-1 fix
...
| $ endif

	-wjm	;-)

Wolfgang J. Moeller, GWDG, D-3400 Goettingen, F.R.Germany | Disclaimer ...
PSI%(0262)45050352008::MOELLER      Phone: +49 551 201516 | No claim intended!
Internet: moeller@gwdgv1.dnet.gwdg.de   | This space intentionally left blank.
From: DWING@UH01.Colorado.EDU (Dan Wing)
Newsgroups: comp.os.vms
Subject: Stingray - experiences
Date: 29 Dec 92 20:29:24 GMT
Distribution: world
Organization: The Internet

We're considering purchasing a Stingray from MicroTechnology.  This is the
HSC-like configuration that connects directly to the CI, sortof like DEC's
Storme product.

Has anyone had any bad experiences with the disk drives, the server, or any
incompatibilities with the disk drives and any software on the VAX, 
problems with VAXsimPLUS reporting errors that didn't exist, or VAXsim
failing to report a failing drive, or any other comments?

The price seems very good, the performance seems very good, and now that the
legal issues are out of the way, it would appear to be a good solution.

-Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet (DGW11)
 Systems Administrator, University Hospital, Denver
From: dfilip@colornet.com
Newsgroups: comp.os.vms
Subject: Re: Unable to delete file
Keywords: delete protections
Date: 27 Dec 92 02:36:09 GMT
Distribution: world
Summary: Check the protections of the parent dir
Organization: ColorNet Information Systems

Carl J Lydick writes :
>In article <009658B3.F3FE06A0.30649@VAX1.Bemidji.MSUS.EDU>,
>ts117@VAX1.BEMIDJI.MSUS.EDU (TANDI SUNARTO) writes:
>
>>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.
>
>You can start by posting the output of DIRECTORY/FULL on both the file in
>question and the directory in which it resides, and the output of the command
>SHOW PROCESS.  That way, we'll have enough information to have a decent chance
>of being able to help you.

Although I agree with Carl that more information would be helpful, I've seen
this problem quite frequently, and it USUALLY points to the protection of the
PARENT directory, to which the user must also have write access to.

If that does not fix the problem, then more information would definitly
be needed.

For someone with privs, non-obvious protection problems can frequently be
resolved by :

	$ set audit/alarm/ena=file=fail
	$ reply/ena

and then running the offending program (I believe I have the 'set audit'
syntax correct, however I am not sitting at a VAX now, so consult your
local VAX online help for the correct order of qualifiers). This will
generate an alarm with the offending programs name, specifically what
file it could not access, and the access that it wanted.

Hope this helps.

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 ...                    =
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Newsgroups: comp.os.vms
From: pampreen@emunix.emich.edu (Dave Pampreen)
Subject: Re: Butthead 
Organization: Eastern Michigan University
Date: Tue, 22 Dec 1992 19:21:13 GMT

   I ask questions here because I can't find it in the manuals or
noone I work with has the answers.  I spend a long time checking the
manuals before I posted.  I know someone can answer it, I just don't like
being screamed at by someone who tells everybody to look in the manuals.

I have had many questions answered here, and I hope people won't be afraid
to post because they might get cussed out.
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: Detecting directory of invoked .com
Date: 25 Dec 1992 06:21: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 <1992Dec23.160636.27010@tigger.jvnc.net>, fogelinc@nmr1.Cyanamid.COM (Carl Fogelin) writes:
>At the risk of being flamed by the "active" participants of this Sig, I have
>a problem which I hope has a reasonable answer.
>
>In a DCL program, I would like to be able to determine what directory the
>invoked .com file is located in.  I seem to remember a similar thread about
>6 - 8 months ago, so I hope someone remembers the solution.

First:  You've got no reason to worry about being flamed.  You've clearly
stated what you want to know, and you're NOT repeating a question that's
already been answered for you in the last week or so.  If I understand your
question correctly (i.e., you want the device, too) then what you want is given
by the expression:
	$ F$ELEMENT(0,"]", F$ENVIRONMENT("PROCEDURE")) + "]"
See the results of
	$ HELP LEX F$ENVIRONMENT
and
	$ HELP LEX F$ELEMENT
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: brennan@tango.cchs.su.oz.au (Luke Brennan)
Subject: Re: Detecting directory of invoked .com
Organization: Cumberland College of Health Sciences
Date: Thu, 24 Dec 1992 19:10:33 GMT

In article <1992Dec23.160636.27010@tigger.jvnc.net>, fogelinc@nmr1.Cyanamid.COM (Carl Fogelin) writes:
> At the risk of being flamed by the "active" participants of this Sig, I have
> a problem which I hope has a reasonable answer.

	heh heh.. *SOME* people are still risking a post, eh? *BRAVE* !!
 
> In a DCL program, I would like to be able to determine what directory the
> invoked .com file is located in.  I seem to remember a similar thread about
> 6 - 8 months ago, so I hope someone remembers the solution.

	I suppose there are other ways to do it, but I usually do something
	like this:

	procedure = f$environment("PROCEDURE")
	proc_dir  = f$parse(procedure,,,"DIRECTORY","SYNTAX_ONLY")

	same deal for proc_dev, etc..

	not exactly obvious - even when you *DO* RTFM...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Luke Brennan                             e-mail:      brennan@cchs.su.oz.AU +
+ EDP Unit, S209                          brennan%cchs.su.oz.au@cunyvm.BITNET +
+ Cumberland College of Health Sciences,                              ,-_|\   +
+ The University of Sydney                  voice: +61 2 646 6402    /     \  +
+ East Street, Lidcombe, NSW 2141             fax: +61 2 646 4853    \_,-._*  +
+ AUSTRALIA                                                               v   +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
From: gezelter@rlgsc.com
Newsgroups: comp.os.vms
Subject: Re: cdd and c
Date: 22 Dec 92 11:43:34 EST
Organization: Robert Gezelter Software Consultant, Flushing, NY

In article <1992Dec22.004144.17281@nntpd2.cxo.dec.com>, winalski@adserv.enet.dec.com (Paul S. Winalski) writes:
> 
> 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.
>
  
Agreed.
 
> 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.
> 
 
Please remember to initialize the value of the "dead" byte to a 
NUL (%X00). If you forget it, you might be surprised one of these 
days.
 
- Bob
+--------------------------------------------------------------------------+
| Robert "Bob" Gezelter                       E-Mail:  gezelter@rlgsc.com  |
| Robert Gezelter Software Consultant         Voice:   +1 718 463 1079     |
| 35-20 167th Street, Suite 215               Fax:       (on Request)      |
| Flushing, New York  11358-1731                                           |
| United States of America                                                 |
+--------------------------------------------------------------------------+