HDTenEightyP/NetNews huggingface dataset:
From: nreadwin@micrognosis.co.uk (Neil Readwin)
Newsgroups: comp.os.vms
Subject: Re: ballooning EXE size
Date: 31 Dec 92 19:44:06 GMT
Organization: Micrognosis, a division of CSK(UK) Ltd

In article <1992Dec30.230003.26308@nntpd2.cxo.dec.com>, winalski@adserv.enet.dec.com (Paul S. Winalski) writes:
|> PROCSECTCNT is the SYSGEN parameter that controls how many image sections a
|> process can have active simultaneously.  If the Linker did not give up on
|> creating new image sections while doing demand-zero compression, it would
|> be trivially easy to create images that cannot be activated.

This is all true, but note that PROCSECTCNT is not a hard limit. To quote
the 5.2 IDS ...  "The PST is allowed to grow beyond PROCSECTCNT entries,
leaving less working set list area available." For years I routinely ran
images linked to several shareable images (with a total of about 40 ISDs)
on a system with PROCSECTCNT set to 32 (the default). Every few months
(perhaps once in several hundred activations) I would find that image
activation would fail with a SS$_SECTBLFUL error (presumably because the
WSL had filled during activation). Neil.
-- 
 Phone: +44 71 815 5283  E-mail: nreadwin@micrognosis.co.uk
 Anything is a cause for sorrow that my mind or body has made
From: imhw400@indyvax.iupui.edu
Newsgroups: comp.os.vms
Subject: Re: openVMS or UNIX.
Date: 23 Dec 92 08:35:02 -0500
Distribution: world

In article <1h9kd2INN1c9@gap.caltech.edu>, carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
>                                                                  An "open"
> system means that all the interfaces are well-publicised so that others can
> write code that uses the interfaces.  Once you've done that, it's nonsense to
> talk about the interface as "proprietary."

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;
everybody thinks he knows what it is, and everybody defines it differently. 
(For example, when talking to AT&T/USL people, it obviously means "Unix(TM)",
and when talking to upper management, it is a synonym for either "good" or
"politically correct" (depending on whether the manager feels secure or not).)

Carl, your definition is one of the more useful ones.  I just wish that we
had all agreed on what an "open system" is before announcing that we sell them
or that we're going to buy nothing else.  As it is, "open" is like "new and
improved":  it looks great on the label but may not be worth much.
-- 
Mark H. Wood, Lead Analyst/Programmer    +1 317 274 0749   [@disclaimer@]
Internet:  IMHW400@INDYVAX.IUPUI.EDU     BITNET:  IMHW400@INDYVAX
Celebrate freedom:  read a banned newsgroup.
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: Changing Decnet Address on a Vaxcluster node.
Date: 22 Dec 1992 06:24:27 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 <01GSKLB748JO005E16@HOPE.CIT.HOPE.EDU>, BAREMAN@HOPE.CIT.HOPE.EDU ("Steven L. Bareman") writes:
>If I want to change the DECnet address of a node in a 
>VAXCluster do I have to reboot the entire cluster?

No.  However, chances are that, as you attempt the kernel-mode hacks that are
the only other alternative, you'll reboot the rest of the cluster whether you
want to or not (see, Jerry?  I'm learning :-).

>I want to take a node with address 51.1xx and change it
>to address 63.1 and make it an Area router.
>
>I know that I need to
>
>NCP> DEFINE EXEC ADDRESS 63.1
>NCP> DEFINE EXEC TYPE AREA
>
>I also assume that I must then edit MODPARAMS.DAT and
>change SCSSYSTEMID, run autogen and reboot the node.
>
>Am I wrong?

Yes.  You don't have to run AUTOGEN.  Changing the SCSSYSTEMID parameter has
*NO* side effects that are of concern to AUTOGEN.  You can change these
parameters in the CURRENT database using SYSGEN.  You should, of course, edit
MODPARAMS.DAT so that the next time you run AUTOGEN for a good reason, you'll
get the right SCSSYSTEMID in your system parameters.
>
>Please send responses directly to me as for some unknown reason 
>I was un-subscribed from the list.

Of course, it's not worth your time to subscribe again, is 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: jeh@cmkrnl.com
Newsgroups: comp.os.vms
Subject: re: Using LOGINOUT.EXE (was Re: Passing parameters...
Date: 31 Dec 92 20:51:40 GMT
Organization: Kernel Mode Consulting, San Diego, CA

In article <31DEC199209423681@author.gsfc.nasa.gov>, rkoehler@author.gsfc.nasa.gov (Bob Koehler) writes:
> In article <9212301623.AA19674@uu3.psi.com>, leichter@lrw.com (Jerry Leichter) writes...
>>Note that running LOGINOUT to map the CLI in this way is itself undocumented
>>and unsupported....
> Yeah, I used to think so to, until I saw it in the documentation.

Where did you see it in the documentation???

There are references under RUN (Process) in the DCL Dictionary, and under
$CREPRC in the System Services Reference, to what is now called the "nouaf"
option -- don't check the UAF if the image being run happens to be loginout.exe
. 

However I can find nothing that says that running loginout.exe in a process of
your own creation is the way to create a process that runs DCL. 

The last time I talked to VMS developers about this, they would not commit to
"it'll never change".  In fact they hinted very strongly that I shouldn't count
on it never changing.  

Personally I wish they'd either commit to supporting it or get on with doing
something else -- but in the meantime I'm not going to depend on it.  

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
drivers, internals, networks, applications, and training for VMS and Windows-NT
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and 
Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
From: PAUL@vax.rinaco.msk.su (RYBAKOV)
Newsgroups: comp.os.vms
Subject: WANTED: info about FTDRIVER and PDT$ routines
Date: 25 Dec 92 10:36:29 GMT
Reply-To: PAUL@vax.rinaco.msk.su
Organization: Russian Investment Joint-Stock Company RINACO (headquarters)


                               Hello!

        I have listened about FTDRIVER and PDT$ routines but don't known what
they are for. Please explain me if I can use them for remapping keyboard in
order to use existing English-oriented software with 8-bit cyrillic code table.
I haven't got any documentation on them and will be very glad to get any
programming examples from you.

        By the way, has DIGITAL included the TFF facility and FBDRIVER into
VMS V6.0?

                               Thank you.

------------------------------------------------------------------------------
Pavel A. Rybakov     \           RINACO            /    Living in the
Moscow, Russia.       \    Russian  Investment    /        DIGITAL
Paul@vax.rinaco.msk.su \   Joint-Stock Company   /          world ...
------------------------------------------------------------------------------
From: DGITLIN@JEFLIN.TJU.EDU (David Gitlin: Systems Manager & Analyst Scott Library)
Newsgroups: comp.os.vms
Subject: (none)
Date: 31 Dec 92 14:57:44 GMT
Distribution: world
Organization: The Internet

ADD DGITLIN@JEFLIN.TJU.EDU
From: ERICCA@RCNVMS.RCN.MASS.EDU ("ERICCA@rcnvms.rcn.mass.edu")
Newsgroups: comp.os.vms
Subject: Re: Request for sources
Date: 30 Dec 92 21:01:25 GMT
Distribution: world
Organization: The Internet

In a previous article, Kevin Mitnick <FZC@CU.NIH.GOV> wrote:
>Message sent: 22 Dec 1992 21:44:47 -0500 (EST).
> 
>Can someone E-Mail me the sources to VMS?
> 
>Thanks, Kevin
> 
	Say, I could be wrong, but isn't there a "Kevin Mitnick"
	featured in the book "Cyberpunk"? The Kevin Mitnick in
	the book, among many other things, broke into Digitals' in-house 
	network and either stole or tampered with (could be both - I can't
	remember) the as-yet-unreleased VMS 5.2(?).

	Maybe the sender of the above message is only using
	a nom de plume. :-) I think I'll check out the book again
	just to satisfy my own curiosity....

	Ellen
From: leichter@lrw.com (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: re: Alternative callable editors in MAIL?
Date: 28 Dec 92 20:49:26 GMT
Organization: The Internet


	We're running VMS 5.5, and have lots of people logging in through
	captive accounts.  The trouble is that they need to use MAIL and have
	the ability to edit their messages, BUT the default callable EDT
	editor is not sufficient for our multilingual/multistandard (whatever
	multistandard means) environment.

	For non-captive users, we simply use the MAIL$EDIT logical to point to
	a command procedure which is then spawned by mail, but the code inside
	MAIL will not allow this to work for captive users.

	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.

Sure.  If you do a SET EDIT xxx in mail, MAIL will try to use the file
SYS$SHARE:xxxSHR.EXE as your callable editor; it will invoke it using
LIB$FIND_IMAGE_SYMBOL.  (A logical name for xxxSHR can be used to place the
editor image in another directory.)  The editor must conform to the standard
callable editor interface.  I'm not sure this is actually specified anywhere
in detail, but you can use the EDT callable interface as a model.  (You have
to substitute "xxx" for "EDT" in interface names like EDT$EDIT.)

All three supplied VMS editors - EDT, TPU, and TECO (let's not forget TECO!)
are callable.  The callable interfaces for EDT and TPU are described in the
Utility Routines manual.  There is also a callable version of GNU Emacs
around, I believe.

Note that since MAIL is privileged, any callable editor that you intend to
call from MAIL must be INSTALL'ed.
							-- Jerry
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: VAX c
Date: 26 Dec 1992 07:28:30 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 <1992Dec24.173709.16437@mailer.cc.fsu.edu>, cliff@evax9.eng.fsu.edu (CLIFF BROWNING) writes:
>
>Is there a way to get VAX C to flush the VMS file buffers? 
>
>I've got a program that reads data in for the tta2: port and then writes it to 
>a file. The problem is that the data doesn't get written to the file until the 
>buffer is full, and that may not happen but once every day or two.  

Well, ONE way to do it is to run the program with a DCL procedure as its input
and the output file as SYS$OUTPUT.  What way you could use as the input file:
	$ SET OUTPUT_RATE=0:0:0.01	!'F$VERIFY(0)'
	$ RUN PROGRAM
Then use the command:
	$ RUN/DETACH/INPUT=your_procedure/OUT=your_log_file SYS$SYSTEM:LOGINOUT
--------------------------------------------------------------------------------
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: gavron@spades.aces.com (Ehud Gavron 602-570-2000 x. 2546)
Newsgroups: comp.os.vms
Subject: Re: Request for sources
Date: 24 Dec 92 20:35:00 GMT
Reply-To: gavron@ACES.COM
Organization: ACES Consulting Inc.
News-Software: VAX/VMS VNEWS 1.4-b1

In article <1992Dec23.070639.194@indyvax.iupui.edu>, imhw400@indyvax.iupui.edu writes...
#In article <9212230626.AA09743@ucbvax.Berkeley.EDU>, FZC@CU.NIH.GOV ("Kevin Mitnick") writes:
#> Can someone E-Mail me the sources to VMS?
# 
#Yes.
#-- 
#Mark H. Wood, Lead Analyst/Programmer    +1 317 274 0749   [@disclaimer@]

	And while we're on that subject, there's too much lead
	in the world.  Lead analyst.  Lead server at J.B.'s.
	Lead in the pipes killed the Romans and now it's attacking
	us.

	Well, lead on...

#Internet:  IMHW400@INDYVAX.IUPUI.EDU     BITNET:  IMHW400@INDYVAX
#Celebrate freedom:  read a banned newsgroup.

	Ehud

--
Ehud Gavron        (EG76)     
gavron@vesta.sunquest.com
Excuse me, but didn't I tell you there's NO HOPE for the
 survival of OFFSET PRINTING?
From: ARNE@KOPC.HHS.DK (Arne Vajhxj)
Newsgroups: comp.os.vms
Subject: Re: DCL symbols from an image
Date: 28 Dec 92 08:58:16 GMT
Distribution: world
Organization: The Internet

>     I am writing an application which must not only get symbols, but set DCL
> symbols.  I am unable to use the LIB$GET_SYMBOL and LIB$SET_SYMBOL services
> because I need to be able to work with integers as well.  Does anyone have an
> example (C or MACRO) that does this? I would also like to be able to determine
> whether the symbol was/is global or local on the get, and to specify global or
> local on the set.

Integer/string symbols:

You can not set integer symbols via LIB$GET_SYMBOL/LIB$SET_SYMBOL or any
other unpriviliged code.

But why bother ?

DCL is quite good to autoconvert ! Small example:

$ a=111
$ sh symb a
$ b="222"
$ sh symb b
$ c=a+b
$ sh symb c
$ exit

And yes - LIB$GET_SYMBOL will return a integer symbol defined in DCL as
a string !

Global/local symbol:

Both LIB$GET_SYMBOL and LIB$SET_SYMBOL have "table-type-indicator" argument,
which does exactly that !

                                                          Arne

Arne Vajhxj                             local DECNET:  KO::ARNE
Computer Department                     PSI:           PSI%23831001304030::ARNE
Business School of Southern Denmark     Internet:      ARNE@KO.HHS.DK


Newsgroups: comp.os.vms
From: pyron@skndiv.dseg.ti.com (Dillon Pyron)
Subject: Re: More than 1 line of command history buffer
Reply-To: pyron@skndiv.dseg.ti.com
Organization: TI/DSEG VAX Support
Date: Wed, 30 Dec 1992 18:57:58 GMT


In article <PRZEMEK.92Dec29235033@rrdstrad.nist.gov>, przemek@rrdstrad.nist.gov (Przemek Klosowski) writes:
>  I am reading a command line in my program, using C RTL function
>gets() (I suspect that this just does a plain buffered read from the
>terminal with NL as terminator, but I am not sure which VMS system
>function this may be).
>
>I like to have the command line editing provided courtesy of VMS
>system read procedure, and the fact that I can retrieve the previously
>used command line using the up-arrow key; however, I am spoiled by the
>DCL 20-line command history (and the readline library I am using on
>Unix that remembers commands across login sessions).  Is there a
>simple way to increase the command history list size, so that more
>than one last command is remembered?

Congratulations, you have discovered a well documented trap.  The application
is responsible for command line buffering and editing.  DCL does such a good
job because it was written to do so.  Your app does not because it was not. 
For proof, see SYSGEN and NCP.  SYSGEN still sucks, the DECnet weenies finally
got their act together (unless I just oopsed some V6 stuff).  Anyways, either
5.4, 5.5 or NMR (next major release) has routines to make that stuff easier
(reading from the terminal mailbox and keeping an orderly stack).  But I don't
remember where or what they are called, or, really, when.  But you might try
.. oh, you know, that R thing.
>
>Of course I could switch to unbuffered/raw read and do the line
>editing and command line history myself, but I would rather not,
>if I don't have to.

You may have to.
>
>I looked for the answer to this question in the FAQ file, but
>I found nothing, and yet I am sure I remember there was some
>discussion on this topic in the past. Help, anyone?

Streching the DCL buffer size is a VFAQ.  Thanks for reading the FAQ.
--
Dillon Pyron                      | The opinions expressed are those of the
TI/DSEG Lewisville VAX Support    | sender unless otherwise stated.
(214)462-3556 (when I'm here)     |
(214)492-4656 (when I'm home)     |"Pacts with the devil are not legally
pyron@skndiv.dseg.ti.com          |binding!"
PADI DM-54909                     |-Friar Tuck   _Robin Hood:The Hooded Man_
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: Backup question
Date: 30 Dec 1992 12:22:48 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 <29846@castle.ed.ac.uk>, ercn50@castle.ed.ac.uk (Lifesupport) writes:
[Description of the "I've accidentally overwritten my backup tape" problem
deleted]

OK.  First of all, everything depends on what kind of tape you're talking
about.  If it's a TK50 or TK70, you're out of luck.  If it's a 9-track, what
you can do is:
	1)  Mount the tape
		/FOREIGN/BLOCK=big_block_size/REC=save_set_record_size
	2)  Use SET MAG/SKIP=FILE=whatever to position near the double
	    end-of-file mark that signals logical end-of-tape;
	3)  Use DUMP or equivalent to skip over the end-of-tape mark;
	4)  COPY the tape to disk or to a file on a tape that's been mounted as
	    a FILES-11 volume;
	5)  Use dump to skip the end-of-file and beginning-of-file labels on
	    the tape, so you're at the beginning of the next saveset;
	6)  Repeat steps 4 and 5 until you've recovered all the data.
If this doesn't make sense to you, e-mail me for more 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: tannenbaum@hitu.zko.dec.com (Barry Tannenbaum)
Subject: Re: Alternative callable editors in MAIL?
Reply-To: tannenbaum@hitu.zko.dec.com (Barry Tannenbaum)
Organization: Digital Equipment Corporation
Date: Sun, 27 Dec 1992 21:17:50 GMT

The correct entrypoint is XYZ$EDIT.  It must take (at least) two parameters;
	in_file - The input file name passed by descriptor.
	out_file - The output file name, passed by descriptor.

	- Barry
From: gleeve@galaxy.dnet
Newsgroups: comp.os.vms
Subject: re: want freeware batch scheduler
Date: 22 Dec 92 13:49:26 GMT
Distribution: world
Organization: The Internet

I suggest looking (as should be routine for requests of this sort)
:-) on your friendly local VMS SIG Tapes. There have been numerous
scheduler programs which I suspect will do what is wanted here.
Art Ragosta's KRONOS comes to mind as an example...it was on the Fall
1991 tapes and an update was submitted for the Fall 1992 tapes,
which are in preparation now. There have been many others, well 
able to perform fairly complex scheduling jobs, and somewhat
easier to use for this than the usual batch-job-that-resubmits-itself
hack which most folks use. (The hack is fine for a few jobs, but
for numerous scheduled actions, particularly at intervals which are
not easy multiples of one another, it becomes cumbersome. That's why
things like KRONOS get written.)
   The sig tapes are available from your local LUG, or on tape or CD
from the DECUS library (508 841 3500; they do take credit cards).
The usual collection size is about 300 MB per 6 months; they are
cumulative, not simple "later versions of the same stuff", so
just having the last one is NOT going to get you the entire
collection. (Having all of them does, and having the last 2-3
years' worth is a pretty good start, though I grabbed something off
a 1985 tape for current use just a couple days back.)
Glenn Everhart
Everhart@Raxco.com
VMS SIG Tape librarian
From: YOUNG@tattoo.cs.widener.edu (Rob Young)
Newsgroups: comp.os.vms
Subject: RE: Pagefile on DECram ramdisk - any comments?
Date: 31 Dec 1992 17:44:36 GMT
Organization: Widener News/Mail Gateway
Distribution: world
NNTP-Posting-Host: tattoo.cs.widener.edu
X-News-Reader: VMS NEWS 1.20

In <9212311339.AA11687@uu3.psi.com> leichter@lrw.com writes:

> 
> 	We are currently running a VAX 4000-300 with VMS 5.4-3.  We have 128Mb
> 	of memory.  We currently only have one pagefile (50,000 blocks) and
> 	yes, it's on the system disk (RF31).  Our other two disk drives
> 	(RF72's) are currently being hit so hard that a secondary pagefile on
> 	those disks is not possible.  I have proposed buying an RF35, but that
> 	will not happen until the Fall of 1993.
> 
> 	We currently have a lot of memory that is not being used (170,000+
> 	blocks).  Working set sizes have been tuned so folks are getting the
> 	memory they deserve.  I have been exploring the possibility of
> 	installing a secondary pagefile on to a DECram ramdisk of say,
> 	60,000-70,000 blocks.
> 
> 	Has anyone ever done this before and if so, are there any issues that
> 	I should be aware of?  If I make the pagefile on the ramdisk
> 	sufficiently large so that it has the most Reservable pages available,
> 	I should be able to ensure that the secondary pagefile is used more
> 	often than not.  We're running DECram v1.0, and I'm getting ready to
> 	install v1.1 this week.
> 
> Think about what you are proposing:  Pages go to the pagefile when there is
> no room for them (for whatever reason) in memory.  You propose to have them
> go to - well, memory, when there is no room in memory.

	[text deleted]

I like Jerry's suggestion but might add what I did and you may be interested
if you have enough time.  I set a group of users WSEXTENT = WSQUOTA, started
with a low value and bumped WSEXTENT until the user was no longer page faulting
(or page faulting very little).  I kept an eye on them with a 
show proc/cont/id=?.  You *may* find a low enough WSEXTENT that
satisfies *most* of your users.  Advantage of this method is you know a 
peak WSEXTENT that you need and if you have enough memory you can set WSQUOTA
equal WSEXTENT for everyone.  Disadvantages are it is time consuming and you 
may find that certain applications bust this (i.e. tweaking results in an 
unreasonable WSEXTENT, say 16000).

Have you explored the possibilty of purchasing a file cacher along the lines
of PerfectCache?  With as much memory that you have this might be a great 
solution and their prices are very reasonable.  

				Rob

                                                     young@tattoo.cs.widener.edu
"I want to find someone on the earth so intelligent that he welcomes opinions 
  which he condemns"  --Chapman