HDTenEightyP/NetNews huggingface dataset:
From: tillman@swdev.si.com ("Brian Tillman, Smiths Industries, VAX Support, x8425")
Newsgroups: comp.os.vms
Subject: Re: VMS 5.5: forwarding to a distribution list
Date: 21 Dec 92 17:07:21 GMT
Distribution: world
Organization: The Internet

Jim A. Whitfill (whitfill@meediv.lanl.gov) writes:

>define mail_list "@disk:[dir]mail_list.txs"
>
>then mail
>to: mail_list

in response to:

>Is it possible with regular old VAX MAIL to forward to a distribution list?
>(a'la @mylist)  I seem to get errors, complaining that it is an invalid user
>specification, and I'd like to know if I can get past it, or if it just doesn't

You didn't read the question.  The person didn't ask if it is possible to mail 
to a distribution list.  He knows how to do that, as can be seen from the 
original question.  He asked if it is possible to *forward* to a list.  The 
answer to that is "no".

-----------------------------+--------------------------------
 Brian Tillman               | Internet: tillman@swdev.si.com
 Smiths Industries, Inc.     |           tillman_brian@si.com
 4141 Eastern Ave., MS129    | Hey, I said this stuff myself.
 Grand Rapids, MI 49518-8727 | My company has no part in it.
-----------------------------+--------------------------------
From: nreadwin@micrognosis.co.uk (Neil Readwin)
Newsgroups: comp.os.vms
Subject: Re: Flaming and Such
Keywords: flaming
Date: 2 Jan 93 19:04:17 GMT
Organization: Micrognosis, a division of CSK(UK) Ltd

In article <74@colornet.com>, dfilip@colornet.com writes:
|> Has anyone done any stats in this newsgroup as to : [ flames ]

Well in the last 12 days we have received 597 messages in comp.os.vms
(excluding the FAQs) covering 223 distinct subjects[%]. The most popular
subject (with 23 articles) was 'vax c' (which was really about fsync() and
fflush()) and the second most popular (with 18) was 'butthead'. At least 7
other threads (containing 21 articles) were meta-discussions on flaming.

In a nutshell, 6.5% of the articles were discussions about flames (and I
guess quite a few more were the flames themselves :-). Hope this helps. Neil.

[%]
Calculated using:
	#!/bin/sh
	trap 's=$?; rm -f /tmp/gak.$$; exit $s' 0

	grep \^Subject: * | tr '[A-Z]' '[a-z]' | \
	sed -e 's/[0-9]*:subject:[      ]*//' -e 's/^re:[     ]*//' \
		-e 's/^re:[     ]*//' | sort > /tmp/gak.$$

	awk -f - /tmp/gak.$$ <<"Grok!This" | sort -n
	BEGIN {f=1;c=0} {if (f) {f=0;c=1;l=$0} else {if ($0 == l) {c++;} else {
	printf "%3d %s\n",c,l;c=1;l=$0}}} END {if (c) {printf "%3d %s\n",c,l;}}
	Grok!This

-- 
 Phone: +44 71 815 5283  E-mail: nreadwin@micrognosis.co.uk
 Anything is a cause for sorrow that my mind or body has made
Newsgroups: comp.os.vms
From: larry@eco.twg.com (Lawrence B. Henry III)
Subject: Re: TT_AccPorNam field (port numbers)
Reply-To: larry@eco.twg.com
Organization: The Wollongong Group (East Coast Operations)
Date: Wed, 30 Dec 92 19:34:13 GMT


In article <1hs2sjINNnqs@gap.caltech.edu>, carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
|>In article <gurman.725601335@umbra.gsfc.nasa.gov>, gurman@umbra.gsfc.nasa.gov (Joseph B. Gurman) writes:
|>>    For what it's worth, logged onto a VMS V5.5-2 system with UCX V2.0
|>>via
|>>Telnet, my TT_ACCPORNAM is (quotes included as delimiters) "Host:
|>>128.183.57.149   Port: 47473" Your mileage may vary.
|>
|>Hmmm.  47473 doesn't sound much like any port name I've ever heard of.  Maybe
|>the "47473" is the beginning of the hexadecimal representation of the port
|>name?  That'd be GGsomething.  Just a wild-assed guess.
|>--------------------------------------------------------------------------------

Port: 47473 is a perfectly valid decimal representation of a port number.
Port numbers can span the range of values that can fit into an unsigned short
or unsigned WORD (for the MACRO impaired). It is the port number on the
remote machine for this connection. Port 23 (telnet) on the local
machine. This information helps you more accurately track down the actual 
person doing the connecting on the remote machine.

ie if you look at a TCP connection, for example

	remote: 128.183.57.149.47473 and 
	local : 128.183.56.23 

this uniquely identifies the TCP connection to both ends. So if you
were interested in logging in to the remote machine you could figure
our which guy on that machine was connected to your machine based on this
information. The remote machine in the example that was given
probably has a fair number of connections coming and going, since these port
numbers are basically grabbed on the fly from empty (non-priv'd port number
space) and typically they are sequentially allocated [ie, 1, 2, 3..] (at 
least in the BSD world).

-Larry.
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: NEWMAIL COUNT incorrect....
Date: 23 Dec 1992 12:31: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 <Bzop55.Cqu@netnews.jhuapl.edu>, 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.

First of all, Ehud now owes me the cost of a Band-Aid (I had to apply it to my
elbow when I suffered an abrasion when I fell out of my chair laughing when I
tried his "solution").

Second, I hereby nominate Ehud for the position of "First winner of the
obfuscated VMS_SHARE [said contest created after the fact] contest."

Thirdly, to fix your new mail count:
	1)  Read all your REAL new mail;
	2)  Issue the MAIL command READ/NEW

Fourthly:  Try to get your hands on Ehud's MACRO32 program.  It's hilarious!
(But don't run it until you're someplace with a soft floor!)
--------------------------------------------------------------------------------
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: leichter@lrw.com (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: re: What is XPDRIVER for?
Date: 30 Dec 92 15:53:09 GMT
Organization: The Internet


	Booting a 4000/300 VMS 5.4-2, I get the following error early in the
	boot process:
    
	    %SYSGEN%W-NOMSG, Message number 00000910
	    [SYSEXE]XPDRIVER.EXE
	    %SYSGEN%W-NOMSG, Message number 00000910
	    [SYSEXE]XPDRIVER.EXE
    
	This occurs after loading the MSCP disk server but before mounting the
	disks.  The 4000 being booted is the disk server for a cluster of 6 VS
	3100's.

	There is no XPDRIVER.EXE anywhere on the system that I can find, but
	there also is not on another VMS 5.4-2 system which does not exhibit
	this message.

	What is the source of this message, and is it something I need to
	worry about?

Typing "EXIT %X910" reveals that the error is "no such file" - consistent
with your statement that there is no such file on the system.

The message you are seeing is coming from SYSGEN when it is trying to
configure in some device for which you don't have the driver.  There are
two possibilities:

	- You've got an explicit attempt to load XPDRIVER somewhere in your
		startup files;

	- SYSGEN is doing an AUTOCONFIGURE and is finding some device that,
		according to its built-in tables, needs a driver named
		XPDRIVER - which you don't have.

A copy of SYSGEN's tables is included at the back of the SYSGEN manual.  It
lists XPDRIVER as the proper driver for the PCL-11.  Those with long memories
will recall that the PCL-11 was a Unibus device that allowed you to connect
multiple '11's together.  If I remember right, it worked by making memory
visible to remote processors in specific "memory windows".  It was never
supported on the VAX, and there's certainly no way you could connect it to
a 4000.  This leaves one of three possibilities:

	- There's something in your 4000 that is responding in a way that
		looks enough like a PCL-11 that SYSGEN is being fooled;
	- The XPDRIVER mnemonic has been re-used for some other device.
		(Any "X" device would likely be a high-speed communication
		option; for example, XQ is a Q-bus Ethernet adapter.)
	- SYSGEN has a bug.

You can use SYSGEN's (long misnamed) SHOW/UNIBUS and try to figure out what
devices haven't been configured - but are there really devices on your system
that you don't even know about?  You might want to check - but I'm inclined
to lean toward an explicit load attempt, or a SYSGEN bug.

							-- Jerry
Newsgroups: comp.os.vms
Subject: Re: Alternative callable editors in MAIL?
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 30 Dec 92 15:54:57 GMT
Distribution: world
Organization: The Wolery

carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
> $ SEARCH SYS$MANAGER:VMSIMAGES.DAT MAIL
> sys$system:mail_server	/open /header /shared	/priv=(sysprv)						! 1/13/VMS_highusers
> sys$system:mail		/open /header /shared								! 1/139
> sys$share:mailshrp	/open /header /shared 	/protect						! 3/74
> sys$share:mailshr	/open /header /shared								! 2/107
> 
> Since MAIL_SERVER and MAIL have been decoupled, MAIL is no longer, by default,
> a privileged image.

No, Carl, wrong....

MAIL_SERVER is the image fired up by incoming DECNET mail transfers.  It
has nothing to do with delivery of local mail.  Presumably, it's privileged
so that it can set the from address etc, which wouldn't happen if it were
just calling the callable mail routines.

MAIL calls MAILSHR calls MAILSHRP, which is a protected image which can go
to kernel/exec mode which can do anything it damn well pleases.  8-)

--
Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand              +64-4-495-5052
From: Chris_F_Chiesa@cup.portal.com
Newsgroups: comp.os.vms
Subject: Re: HELP!!! Security problem for gurus.
Date: Fri, 25 Dec 92 23:53:17 PST
Organization: The Portal System (TM)
  <Bz1nrE.ALq@unx.sas.com> <1992Dec19.025940.1@us.oracle.com>

On the thread of protecting a directory, I found something recently that
might prove applicable...

I was reading through printouts of old postings from this newsgroup, 
and happened across mention of "the undocumented DUMP/DIR command."  I
tried it (you try it, now, too) and found that it displays the contents 
of a .DIR file, in terms of its significance as file-directory information 
and including its offset, in bytes, from the beginning of the .DIR file.  

One of the fields shown was "TYPE" at offset 4.  I noticed that it had 
the exact same value (I don't have a VMS system handy at the moment so
can't tell you what value that was) for ALL directory entries in ALL
.DIR files.  I wondered what OTHER valid values for that field existed,
and so I whipped out my copy of VFE (the Virtual File Editor, a PD 
thing available from DECUS) and patched a different value into offset 
4.  I found that there were several values which DUMP/DIR "knew about,"
whose purpose is as yet unknown to me.

I also found that if I put an INVALID value -- i.e., something DUMP/DIR
didn't recognize (or was it, specifically, the value 0?  I forget; try
experiments, I did!) -- into that field in the FIRST entry in the .DIR file,
a funny thing happened: I was able to do a DIRECTORY operation on the 
directory represented by the patched .DIR file, but was UNABLE to access
any of the FILES THEMSELVES.  Patching the original value, whatever it
was, back into that field, made everything work normally again.

I expect that this technique--

  a) is unsupported; use at your own risk;
  b) does NOT involve changing the ATTRIBUTES (protection, "directory"
     bit, etc.) of the .DIR file;
  c) would stymie any system manager, probably any CSC representative,
     who hasn't read this post just now, regardless of privs;
and
  d) could be implemented in a nice little PROGRAM that went out and 
     tweaked the appropriate field in the .DIR file, letting you easily 
     protect and deprotect a directory at your convenience.

Use at your own risk, of course.  Bon chance!

Chris Chiesa
  Chris_F_Chiesa@cup.portal.com
Newsgroups: comp.os.vms
From: rkoehler@author.gsfc.nasa.gov (Bob Koehler)
Subject: re: Re: Passing parameters to detached processes.
News-Software: VAX/VMS VNEWS 1.4-b1  
Organization: CSC System Sciences Division
Date: Thu, 31 Dec 1992 14:42:00 GMT

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....
>							-- Jerry
> 

Yeah, I used to think so to, until I saw it in the documentation.

------------------------------------------------------------------------------
Bob Koehler                     |   Any illusion to these opinions being other
rkoehler@author.gsfc.nasa.gov   |   than just mine alone is just that.

 " Life is life, and fun is fun, but it's all so quiet when the goldfish die. "
                         - Blixie
From: jeh@cmkrnl.com
Newsgroups: comp.os.vms
Subject: Re: How do I use more memory?
Date: 30 Dec 92 00:28:26 GMT
Organization: Kernel Mode Consulting, San Diego, CA

In article <18542@borg.cs.unc.edu>, scher@hatteras.cs.unc.edu (Ellen Scher) writes:
> I've recently acquired a VAXstation with 80 Mbytes of physical memory, 
> and I would like to use the memory almost exclusively to run really
> big (large arrays) scientific computational code. I'm more than willing 
> to sacrifice other management concerns.  
> [...]
> Currently I've set:
>      MIN_WSMAX=119531
>      MIN_WSINC=1000
> and boosted up my user authorizations to:
>    WSdef:          150     
>    WSquo:       163840    
>    WSextent:    163840
>    Pgflquo:     163840

First, it makes no sense to set (UAF) WSQUOTA and WSEXTENT to larger values
than (SYSGEN) WSMAX.  If WSMAX is 119531, then no process can ever have a 
working set larger than that, despite what the UAF parameters say. 

However, I suspect that the main cause of your trouble is that you need to
increase WSDEFAULT as well. 

WSDEFAULT determines the working set list size at the beginning of the 
execution of an image.  Your image won't use the larger values you have
allowed via WSQUOTA and WSEXTENT until the working set list size is increased
via the automatic working set adjustment (AWSA) mechanism.  

Given the default value (20, which means 0.2 seconds) for AWSTIME, and your
value of 1000 for WSINC, your process won't climb up to your maximum 
(119531 pages) until 

	119531 - 150 pages           0.2 CPU seconds
       --------------------------- * --------------- = 23.8 CPU seconds
            1000 pages/adjustment    1 adjustment

Also, if the process happens to be running in the real-time priority range,
it will never experience quantum end, and so will never have its working
set adjusted. 

Try setting WSDEFAULT to a larger value.  Or, use the command

	SET WORKING_SET /LIMIT=nnnn

just before running the image that hits all those large arrays. 

	--- 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
Xref: sparky comp.os.vms:19710 vmsnet.misc:1085 vmsnet.networks.desktop.pathworks:3829
Newsgroups: comp.os.vms,vmsnet.misc,vmsnet.networks.desktop.pathworks
Subject: Re: Using MS-Windows env. with Pathworks
From: allebrandi@inland.com (Tom Allebrandi)
Date: 22 Dec 92 01:20:10 CST
Distribution: world
Organization: Inland Steel Company; East Chicago, IN

In article <1gsq7rINN8o6@taloa.unice.fr>, fontanel@taloa.unice.fr (Fontanel Laurent) writes:
> 
> It seems that MS WinWord 2.0 Installer refuses to propose the 'Network'
> installation option when you want to install it on a disk service (is
> the disk service considered as a local disk ?)

File services are implemented at the MS-DOS file system redirector level.

Disk services are implemented at the PC BIOS disk function call level. From
MS-DOS's point of view, anything that it accesses via the BIOS disk function
calls are locally connected disks.

That's why you can "CHKDSK", "FORMAT" and a number of other things on
a disk service drive, but not a file service drive.

--- Tom
Tom Allebrandi             | Mail guru   - DECUS UUCP Development Team
Inland Steel Research Labs | NFS grunt   - CMU/Tek-IP
East Chicago, IN           | Chairperson - VMSnet Working Group, DECUS VAX SIG
219 399 6306               | Internet:  allebrandi@inland.com
DECUServe: allebrandi      | UUCP:      ...!uunet!inland!allebrandi
From: system@condor.navsses.navy.mil
Newsgroups: comp.os.vms
Subject: Re: ballooning EXE size
Date: 29 Dec 92 19:17:01 GMT
Organization: NSWCCD, Naval Ship Systems Eng Sta, Phila PA

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...
> 
> When the FORTRAN interface stub subroutines (e.g. subroutines that print a "not 
> implemented" message and return) are replaced with my code, the resulting 
> executable goes from ~1,000blocks to ~75,000 blocks. 
> 
> Yes, I use some scratch arrays (scratch arrays defined as local to the 
> subroutine), so I replaced these with LIB$GET_VM and LIB$FREE_VM and the 
> executable size when back to ~1,100 blocks. I presume the difference is due to 
> my code size. Ok so far, but I can't get away with this for long....
> 
> Eventually, the addition of the simplest code causes the executable to go from 
> 1,100 blocks to ~76,000 blocks. Looking at the LINK map, the size of my 
> interface modules are quite small. Remember, this is FORTRAN and most of the 
> memory is statically allocated.
> 
> $link/map/exec=foo.exe
>  untouchable.olb/INC=foo_main, -	! main calling routine
>  untouchable.olb/L, -		! library of untouchable code objects
>  expm.olb/l, -			! my interface routines
>  sys$input/opt
>    SYS$SHARE:FORRTL.EXE/SHARE,sys$library:vaxcrtl.exe/share
> 
> Thoughts? 
> 
What is the size of your arrays?  Do they contain pre-initialized data or are
they just created as an array of zeros?  If the arrays do not contain data you
should be able to for the linker to create the pages that are used to store the
arrays as DEMAND ZERO pages.  DEMAND ZERO pages are created when the linker
detects a region (default size: 5 pages or 2.5K bytes) in your program
that contains un-initialized storage.  There are a few cases when a bug causes
the linker to not compress a large range of uninitialized data to demand zero
pages.  Fortunately you can control the linker's use of demand zero pages with
a linker options file (see pages 3-7 and 6-19 of the VMS Linker Utility Manual
V5.0).
-- 
Mike Jacobi
NAVSSES VAXCluster system manager
System@Eagle.Navsses.Navy.Mil
System@Condor.Navsses.Navy.Mil

Disclaimer - I speak for myself.  No-one else.
From: leichter@lrw.com (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: re: Re: Passing parameters to detached processes.
Date: 30 Dec 92 15:11:51 GMT
Organization: The Internet


	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.)

1-3 work just fine.

	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.

Not only that, but in the case at hand, it doesn't work; what you'll find in
SYS$ERROR is a PPF that's the same as SYS$OUTPUT.  (I'm not sure exactly who
"fixes this up" and where, but the original value of /ERROR is simply not
accessible by the time LOGINOUT gives the command file control.)

You CAN pass a small amount of information through by setting the process
name - but PROC.COM would have to know enough to look for the information
there.  If I'm reading the original question correctly, what's desired is a
way for the information to appear in PROC's P1-P8, exactly as it "normally"
does.

Passing information through the process name is also a hack, and requires care
to avoid chosing a name that conflicts with an existing process (in which case
the proposed name would be ignored" - but while it's an "unexpected" use of a
documented, supported interface, I'd have to call it documented and supported
nontheless.

Note that running LOGINOUT to map the CLI in this way is itself undocumented
and unsupported....
							-- Jerry
From: burress@twics.co.jp (Tim Burress)
Newsgroups: comp.os.vms
Subject: Alternative callable editors in MAIL?
Date: 25 Dec 92 14:44:30 GMT
Organization: TWICS, Tokyo, Japan

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.

						Thanks!

-- 

Tim Burress                                     Internet:  burress@twics.co.jp
TWICS Co., Ltd.
1-21 Yotsuya, Shinjuku-ku, Tokyo 160 Japan