HDTenEightyP/NetNews huggingface dataset:
From: billb@crpmks.uucp (Bill Bochnik (Info Systems))
Subject: Re: Plans for mixed Alpha/VAX cluster with common system disk?
Reply-To: billb@crpmks.UUCP (Bill Bochnik (Info Systems))
Organization: Ciba-Geigy Corporation
Date: Thu, 19 Nov 1992 14:30:24 GMT

In article <1992Nov14.080016.1283@news.arc.nasa.gov> adelman@tgv.com (Kenneth Adelman) writes:
>>In article <1992Nov13.100832.3777@dxcern.cern.ch>, julian@vscn08.cern.ch (Julian James Bunn) writes:
>>
>> What worries me more about a mixed architecture VAX/Alpha VMS Cluster is
>> how the poor innocent users are going to sort out the confusion between
>> VAX and Alpha executables.
>
>    David Kashtan had an interesting solution to this problem.	Create
>a format for images that allows you to "store" both a VAX and an Alpha
>image in the same executable.  Then you just need an APPEND/IMAGE
>command or somesuch to create these "duel-architecture" executables.
>
>							    Ken

Sounds like agreat idea.  In the mean time, I have heard that they will 
require 2 system disks in a mixed "cup" environment.   

-- 
Bill Bochnik			| It's hard to be a James Bond in an Abbott
Systems Analyst 		|	and Costello world.
Ciba-Geigy Corporation		| Signed and sealed, they deliver oblivion.
philabs!crpmks!billb		| It's worse than that, he's dead Jim.
Newsgroups: comp.os.vms
From: olin@vger.cheme.cornell.edu (Steve Thompson)
Subject: retrofitting the old VMS queue manager
Reply-To: olin@vger.cheme.cornell.edu
Organization: Chemical Engineering, Cornell University, NY
Date: Mon, 16 Nov 1992 16:54:49 GMT

I need to return to using the old VMS queue manager (as used in VMS A5.5 and
previous versions) on a cluster running 5.5-1, while retaining everything
else the same (ie I don't want to reinstall A5.5). This is not related
to any problems with the new queue manager - I have other reasons for
doing this which I can't go into here. Anyone know how to retrofit the
old queue manager? Thanks,

Steve

---------------------------------------------------------------------------
Steve Thompson, System Mangler   Internet: thompson@cheme.tn.cornell.edu
School of Chemical Engineering   Bitnet:   thompson@crnlchme
Olin Hall, Cornell University    Phone:    (607) 255 5573
Ithaca NY 14853
---------------------------------------------------------------------------
From: prk6066@ritvax.isc.rit.edu
Newsgroups: comp.os.vms
Subject: Zmodem For VMS?
Date: 22 Nov 92 23:44:17 GMT
Reply-To: prk6066@ritvax.isc.rit.edu
Organization: Rochester Institute of Technology


 I need to find Zmodem, or Ymodem for VMS... Kermit just doesn't cut it. Can
anyone direct me to an FTP site where I might be able to find this?
From: ronp@jomby.cs.wisc.edu (Ron Peterson)
Newsgroups: comp.os.vms
Subject: File locking in EVE
Summary: Is there a way to lock files so only one user can update at a time?
Keywords: files, locking, eve, vms
Date: 23 Nov 92 17:54:35 GMT
Organization: University of Wisconsin, Madison -- Computer Sciences Dept.

Email responses to ronp@jomby.cs.wisc.edu are fine.

I would like to be able to automatically lock a file when it is edited
with eve so that the file integrity is maintained.  Is it possible
without using special software or renaming to a different directory?

	Ron
From: simons/G=Colin/I=CB/S=Sewell/O=H.A.Simons.Ltd/OU=CORP@mhs.attmail.com
Newsgroups: comp.os.vms
Subject: re.2: extending INDEXF.SYS (new idea!)
Date: 17 Nov 92 16:16:58 GMT
Distribution: world
Organization: The Internet

Wolfgang J. Moeller writes:

|It occurred to me that there is a VMS utility for extending files,
|which *has* that important check built-in:
|
|  $ MCR SYSGEN CREATE disk:[000000]INDEXF.SYS/size=<newsize>


	If this does work, you had better check to see if
	the INDEXF.SYS file has not been marked NOBACKUP!!
From: CZIWKGA@VMSFE.ULCC.AC.UK ("Kevin Ashley, Systems Development, ULCC")
Newsgroups: comp.os.vms
Subject: re: problem making an outbound x29 call
Date: 16 Nov 92 09:44:00 GMT
Organization: The Internet

Anders (Rolff ?) wrote a few days ago in a message which had no mail
address about a problem he was having with x29 calls.

He wrote:

>I think I have tracked down the problem to facility negotiation. If I make
>an x29 call with $ set host/x <addr> I get the following accounting
>info on the remote node:
>
>Calling facilities:
> 42 07 07
>
>Accept facilities:
> 42 07 07
>
>But, if I use psi$x29_outgoing_c the call fails with Virtual call cleared
>and the accounting info on the remote node looks like this:
>Calling facilities:
> 42 07 07
>
>Accept facilities:
>
>
>It doesn't seem like the remote node is accepting the facilities.
>

No, anders, this just means that the remote node didn't accept the call.
If there isn't a call accept, then there aren't any accept facilities for
psi accounting to record. In any event, since the calling facilities you
showed in both these calls are the same, this would not make sense. What
would be more useful would be to show the other information that
PSI accounting shows, ESPECIALLY anything that differs between the
call that works and the call that fails. Most useful of all would be
the second page of output from PSI accounting showing the clearing
cause and diagnostic fields, and stuff like the protocol ID.

There are 1001 reasons why calls like this can fail, including security
facilities on the remote node that are fussy about exactly how incoming
calls are set up. At least you have managed to demonstrate that the
calls are reaching the remote node, and not getting bounced somewhere
else in the network, and this is helpful.

But, if you show us the rest of the PSI accounting info from the remote end,
someone might be able to do more than hazard a guess as to why it failed.

------------------------------------------------------------------------------
Kevin Ashley                              K.Ashley@Ulcc.ac.uk
Systems Development Group Manager         ...ukc!ncdlab!K.Ashley
University of London Computer Centre.
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: Modem DialBack Security for VAX?
Date: 17 Nov 1992 19:03:10 GMT
Organization: HST Wide Field/Planetary Camera
Reply-To: carl@SOL1.GPS.CALTECH.EDU
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <1992Nov16.170824.28028@lmt.mn.org>, elliott@lmt.mn.org (David Elliott  MIS x 363) writes:
>We're looking into the possibility of setting up a dial-back modem security
>arrangement on our 6410.  I'm not certain if this is a modem thing or a VAX
>thing, but I'd sure like to hear from you if you have any information about
>this sort of stuff.  Please feel free to mail me directly at
> davide@ramrod.lmt.mn.org

I've got a program that does dialback.  It currently simply accepts a phone
number (and optionally a terminal line) from the user, but could be easily
modified to check a database to determine where to dial back to.
--------------------------------------------------------------------------------
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: oberman@ptavv.llnl.gov
Newsgroups: comp.os.vms
Subject: Re: ?Why does this backup go so slow?
Date: 17 Nov 92 16:32:27 GMT

In article <1992Nov12.124928.1@woods.ulowell.edu>, welchb@woods.ulowell.edu writes:
> It took us 4.5 hours to do an image backup of an RA90 (80% full of user
> data) onto an RA92?  Why does it not go faster?   [I had prepared a much 
> longer version of the question, with so many particulars, that my boss 
> said to just ask the simple question.]

Well, I guess you will have to live with the simple answer (at least from me).

BACKUP is more seriously effected by system tuning and user quotas than any
application I have seen. My 2.1 GB disk can be backed up to tape in less than
4.5 hours.

Please read the rather long discussion of tuning an account for BACKUP use. I
think it was in the VMS V5.2 release notes or maybe the New Features manual.

On my muti-user systems I have a special account that is used ONLY for backup.
OF particular concern are the working set quotas (NOT WSEXTENT) and the file
limit. The SYSGEN parameter "CHANNELCNT" is also significant. Lots of other
limits need to be very high for good performance. While all of these interact,
the most important is WSQUOTA. This will determine how BACKUP sets up it's
buffers.

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: koberman@llnl.gov		(510) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
From: 00mjstum@leo.bsuvc.bsu.edu (Matthew J. Stum)
Newsgroups: comp.os.vms
Subject: Re: DCL question.
Date: 19 Nov 92 13:53:31 GMT
Organization: Widget Enterprises

hamjavar@hydra.unm.edu (Farid Hamjavar) writes:
> Hello :
> 
> As you can tell the following simple DCL script prints its first two
> parameters/arguments :
> 
> $ DISPLAY= "WRITE SYS$OUTPUT"
> $ DISPLAY  "''p1'"
> $ DISPLAY  "''p2'"
> 
> Now if any of the parameters starts with   /    this script will crash :
> 
> $ @t.com /parameter1  /parameter2
> %DCL-W-IVQUAL, unrecognized qualifier - check validity, spelling, and placement

It's only if the first parameter begins with a /... other than that, you're
fine.  The hack that I use when I wish to use qualifiers as parameters is
something along the lines of:

$ COMMAND :== "@T.COM """""    ! sends a blank string to P1

And then $ COMMAND /PARAM1 /PARAM2  is perfectly legal.
However, you have to shift all of your P#'s in your command procedure:

$ DISPLAY= "WRITE SYS$OUTPUT"
$ DISPLAY  "''p2'"
$ DISPLAY  "''p3'"

-- 
Matt Stum                    Gwydion ap Myrddin       Ball State University
00mjstum@leo.bsuvc.bsu.edu   Shire of Afonlyn, MK     Muncie, IN  USA
From: sean@isis.win.net (Sean Gonzalez)
Newsgroups: comp.os.vms
Subject: Experiences with exabyte jukeboxes, anyone?
Date: 17 Nov 92 13:34:23 GMT
Reply-To: sean@isis.win.net (Sean Gonzalez)
Organization: The Internet
X-Unparsable-Date: Mon, 16 Nov 1992 23:48.48.80


        Does anyone have any experiences with exabyte (8mm) jukeboxes? 
        We are currently considering using a MicroTechnologies Inc.
        (MTI) jukebox and would appreciate any comments which might save
        us headaches in the future.  Also, if you have successfully used
        some other vendor's jukebox, please do share your experiences. 
        Thanks! 

                                                        Sean.

-----------------------------------------------------------------------
Sean Gonzalez                                         sean@isis.win.net
        "May our users be forgiving of our systems' faults..."
From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: How to get remote node name from RSH process?
Date: 18 Nov 92 16:28:43 GMT
Reply-To: carl@SOL1.GPS.CALTECH.EDU
Organization: HST Wide Field/Planetary Camera
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <921118095020.20201179@ECF.NCSL.NIST.GOV>, ALLEN@ECF.NCSL.NIST.GOV writes:
=	I'm using Multinet to execute various DCL command files on our Vax
=	from a Sun workstation using the rsh utility. From within the VAX
=	command file I'd like to be able to determine the name (or IP address)
=	of the workstation from which it was invoked.
=
=	I've played around a little and I see the VMS process seems to be
=	running against a mailbox device but I havn't found any record of
=	the remote node that created the process or mailbox.  Anybody able
=	to offer any assistance?

It's in the process logical name MULTINET_RSHELL_ADDRESS.
--------------------------------------------------------------------------------
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: bruce@ais.com (Bruce C. Wright)
Newsgroups: comp.os.vms
Subject: Re: The problem with $CREMBX System_Service
Date: 19 Nov 92 09:32:26 GMT
Distribution: world
Organization: Applied Information Systems, Chapel Hill, NC

In article <1eevvpINNhgv@gap.caltech.edu>, carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
> In article <1992Nov18.171216.26136@nntpd2.cxo.dec.com>, winalski@adserv.enet.dec.com (Paul S. Winalski) writes:
> =
> =The DCL command interpreter uses RMS to read its input file.  RMS is a
> =record-oriented I/O system.   [...]
> 
> The fault is not in RMS.  MAILBOXES ARE RECORD-ORIENTED DEVICES.  You can't
> read a single character from a mailbox (well, you CAN, by using $QIO[W], but
> the only character you can read singly is the first character of a record,
> and then you lose the rest of the record).
> 
> =The solution is to buffer characters inside your program until you read a
> =CR from the terminal, then write the buffered string (not including the CR)
> =to the mailbox using one $QIO.
> 
> Or have the application that's reading the mailbox buffer what it reads until
> it sees a CR in the data its reading from the mailbox.  Both techniques are
> equally effective, and I'd choose the one for which obtaining and modifying
> the source code is easier.

Another solution, which may be more like what the original author was
looking for, would be to use the pseudoterminal driver (either the FTA
driver or the PY/TW drivers depending on VMS version and/or convenience).
It wasn't entirely clear to me whether the applications were all newly-
written applications or not;  and in any event, from the point of view
of the consumer application, a pseudo-terminal is (nearly) indistinguish-
able from a real terminal, so even if it isn't newly-written it would
probably be very easy to make it run on a pseudo-terminal.

You can often use mailboxes for this sort of thing, but as Carl points
out there are problems because of the record-oriented nature of mailbox
I/O.  But the pseudoterminal drivers are true stream-oriented devices
that allow you to do single-character I/O in the manner that the original
author was expecting the mailbox driver to operate.  They're both useful
devices, but in general mailboxes are more useful for sending highly
structured messages, and pseudoterminals are more useful for capturing
terminal-like I/O streams.

Bruce C. Wright
From: alanmoore@yang.earlham.edu
Newsgroups: comp.os.vms
Subject: Looking for decw$xtshr.exe
Date: 16 Nov 92 16:15:38 GMT
Organization: Earlham College, Richmond, Indiana

I have downloaded XFig, and need decw$xtshr.exe to compile it.  Any
help in locating it would be appreciated.

Thanks,
Alan Moore                              alanmoore@yang.earlham.edu
System/Network Manager, Postmaster      (317)983-1437
Earlham College
Richmond, IN
From: mlevin@HUSC.HARVARD.EDU
Newsgroups: comp.os.vms
Subject: Re: How do I throw a pixmap up on a DecWindows screen at once?
Date: 14 Nov 92 16:41:57 GMT
Distribution: world
Organization: The Internet

Ok - thanks!

Mike Levin

Newsgroups: comp.os.vms
From: jsue@ncsa.uiuc.edu (Jeffrey L. Sue)
Subject: Re: TUNING - QUANTUM SYSGEM parameter
Originator: jsue@troon.ncsa.uiuc.edu
Organization: The Dow Chemical Company
Date: Thu, 19 Nov 1992 13:47:54 GMT

In article <27A0322A_00174E60.00963CCA9D4FA020$626_2@UK.AC.KCL.PH.IPG> SYSMGR@IPG.PH.KCL.AC.UK writes:
>Slightly provocative reply:
>
>If QUANTUM=20 is OK on a microVAX-II (less than 1 VUP) (and it is!), then
>logically QUANTUM=1 on anything rated at more than 20VUP should be OK,
>maybe even optimal.
>

Maybe this information has already been posted.  If so, I pologize.

I have been to courses, and many DECUS sessions where Patrick O'Malley
discusses tuning quantum.  What should be kept in mind when reducing
QUANTUM is that it may seemd to improve *trivial* performance, it reduces
"throughput".  This means that in the same amount of wall-clock time,
you get less "total" work completed.  This is a trade-off.

Other factors to consider are:  whenever a context switch takes place,
the on-cpu instruction cache is invalidated.  Thus the more often you
context switch (smaller quantum), the more often the cache will become
invalidated.  Therefore your job will get less done because it must rebuild
the cpu's instruction cache everytime it becomes the CUR processes, and it
is doing this more often.  (note:  the CPU cache is a hardware cache, not
one of the XQP (ACP_*) caches - which are for the file system.)

I have played with quantum and found that on the smaller processors it
made a big difference in the performance of "trivial" response, like for
MAIL, DIRECTORY, DELETE, TYPE, etc..  However, on the faster processors
today, rarely do these activities even use a quantum before they give up
the cpu voluntarily for a wait-state (I/O completion, LEF, etc.).  Also,
in the cases where I lowered quantum,  the longer-running operations tended
to take more time - my guess is this happens because the scheduler must stop
processing more often to determine "who's next" to run... even if there is
only one job on the system.

I eventually settled back to DEC's default of 20 for quantum.  In the
evenings I set quantum to 100 (1 full second) so that the long, 
number-crunching jobs can actually get more time in the cpu before the
scheduler stops the processing to do a context switch.  This can cause 
longer delays for interactive processing, and trivial response.

Much of the decision on whether to reduce quantum depends on who/what
you're trying to tune for.  In my case I have a mix of trivial, and non-trivial
processing going on at the same time.  Thus I don't want to context-switch
too often.  I hesitate to say that, merely because today's processors are
much faster than a uVAX II, you can lower quantum.  One of the reasons we
pay for the faster processors is to get more work completed.  Throttling
it all back to a uVAX II speed would miss this point.  We could get the
same affect by merely buy a lot more uVAX II's, distribute the load, and
spend a lot less money than a VAX 6610.

Hope this doesn't confuse the issue too much.

Jeff
-- 
-----
Jeff Sue   
 - All opinions are mine -       (and you can't have any, nya nya nya)
Newsgroups: comp.os.vms
From: jim@news.miami.edu
Subject: Re: Is a heterogeneous system possible under 5-5?
Keywords: OLD_QUEUE_MANAGER
Organization: University of Miami, RSMAS
Date: Tue, 17 Nov 92 23:40:45 GMT

To select the old queue manager one can edit
SYS$SYSROOT:[SYS$STARTUP]VMS$CONFIG-050_JOBCTL and insert the line

$ newjobctl = 0

just before the lines

$ define/user sys$output nl:
$ if newjobctl
$ then

This will run the old queue manager.
Note that _ALL_ nodes in the cluster must run the same type of queue
manager (all old or all new).

Also, in SYSTARTUP_V5.COM, DEFINE /SYSTEM /EXEC logicals for SYSUAF,
RIGHTSLIST, NETPROXY, and VMSMAIL_PROFILE to point to node specific files.

Works for me.
Jim Brown, U Miami, jim@lime.rsmas.miami.edu
-- 
Jim Brown, University of Miami, RSMAS/MPO
[send mail to jim@lime.rsmas.miami.edu]
From: francini@narfvx.enet.dec.com (John Francini)
Newsgroups: comp.os.vms
Subject: Re: SYSTEM-F-NOLINKS, maximum network logical links exceeded
Date: 22 Nov 92 17:35:06 GMT
Organization: Digital Equipment Corporation, Littleton, MA


In article <22NOV92.01314219@moleng.ucsc.edu>, wipke@moleng.ucsc.edu writes...
>NCP shows max links = 32, but SHOW NET shows zero links to the node
>that gives this error upon SET HOST <anyothernode>.  Is max links
>for the network or for the node?  Is there some other parameter tha
>that causes this?
> 
>wipke@secs.ucsc.edu

The error is coming from the remote system, not the local one, if I
understand your scenario correctly.  In other words:

You're logged onto NODEA::.  You SET HOST to NODEB::.  You get the
SYSTEM-F-NOLINKS.  NODEB::'s using the maximum number of links.

NODEB's NCP max links parameter needs to be increased.

HOWEVER, if NODEB:: is really a VAXcluster alias, then you need to look at
the "Alias maximum links" parameter on EACH system in the cluster, as this
value is separately managed.  When every system in the cluster has used up
all of its cluster alias links, then the NOLINKS error will be generated.

John Francini
PATHWORKS for VMS
Digital Equipment Corporation
francini@narfvx.enet.dec.com
From: kirk@tallis.enet.dec.com (Matthew B. Kirk)
Newsgroups: comp.os.vms
Subject: Re: Plans for mixed Alpha/VAX cluster with common system disk?
Date: 23 Nov 92 16:44:11 GMT
Organization: Digital Equipment Corporation


In article <4321@bcstec.ca.boeing.com>, silverm@bcstec.ca.boeing.com (Jeff Silverman) writes...
				.
				.
				.
> 
>I would think that the image activator could be modified to issue an error
>message which said "This is a VAX/VMS program" or "This is an Alpha/VMS
>program".  

This is what I get running (and analyzing) an OpenVMS VAX image on OpenVMS AXP...

        Welcome to OpenVMS ALPHA V1.0

    Last interactive login on Thursday, 19-NOV-1992 12:11
    Last non-interactive login on Thursday, 19-NOV-1992 16:24

XLATED::KIRK>> set def [test]
XLATED::KIRK>> run/nodeb 352
%DCL-W-ACTIMAGE, error activating image 352
-CLI-E-IMGNAME, image file $1$DUA2:[TEST]352.EXE;2
-IMGACT-F-NOTNATIVE, image is not an OpenVMS Alpha AXP image
XLATED::KIRK>> anal/image 352

Analyze Image                                23-NOV-1992 11:42:55.46   Page 1
DISK:[TEST]352.EXE;2
ANALYZ A05-10

This is an OpenVMS VAX image file

IMAGE HEADER
					.
					.
					.



=============================================================================
Matthew Kirk				  	     kirk@tallis.enet.dec.com

All opinions expressed here are mine and do not reflect those of Digital
Equipment Corporation.
=============================================================================
Newsgroups: comp.os.vms
From: sommar@enea.se (Erland Sommarskog)
Subject: Re: Plans for mixed Alpha/VAX cluster with common system disk?
Organization: Enea Data AB
Date: Sun, 15 Nov 1992 21:25:39 GMT

Julian James Bunn (julian@vscn08.cern.ch) writes:
>What worries me more about a mixed architecture VAX/Alpha VMS Cluster is
>how the poor innocent users are going to sort out the confusion between
>VAX and Alpha executables. I assume DEC will provide solutions for system
>logical name tables etc etc for MAVCs, but I bet they wont for the default
>login directories. The particular problem I see is if the user logs in to
>the Alpha node in the Cluster one day, re-compiles and links all his source
>files, then logs in to the VAX node in the Cluster the next day (why should
>he care what architecture he happens to get?) and wonders why he gets
>
>Image file VXCRNA::DISK$C:[JULIAN]COUNTER.EXE;20
>Image is not an OpenVMS Alpha image

If your users cannot handle such problems, don't get a mixed
architecture cluster.

This is not a new problem. At our office we have an HP9000 and a
IBM RS/6000, running different various flavours of Unix and with
their disks cross-mounted over NFS. Of course the machines are not 
binary compatible.

If you are doing development in such a mixed environment, you are
probably doing it with a reason, for instance your application
is supposed to run on both.

The exact solution is site dependent, as many development environment
issues are. I have devised a specicialized generalized CM environment
tool (yes, that is an oxymoron), which supports multi-architecture
environments. That's for Unix, but the basic idea would work on VMS
as well. Use different directories for architecture-specific stuff,
set up some logicals to point at them, and put all the control in
the MMS (make) file.

In case of innocent users who are just playing with their own stuff,
they should learn to stick to one architecture. And of course learn
the difference between a VAX and an Alpha machine.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se