HDTenEightyP/NetNews huggingface dataset:
From: DWING@UH01.Colorado.EDU (Dan Wing)
Newsgroups: vmsnet.internals
Subject: Re: PATCH on ALPHA ?
Date: 2 Sep 92 17:36:24 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Ed Heinrich, HEINRICH@yvax.byu.EDU, writes:

[...]

>I have to agree w/ both Bruce and Hunter.  For software companies that
>have large customer bases PATCH is invaluable.

DEC has a large customer base!

>In addition, many system managers WILL apply a
>patch if they are told it fixes a potential crash-related bug, they
>may not, however, rush to do a full installation if you send them a
>patched distribution kit.  (I know of some shops that only schedule
>product upgrades during Christmas week when the plant is closed, but
>they will apply a PATCH when they receive it).

It is difficult to explain to management why you didn't apply a patch that
would prevent a crash because you feared the patch could cause a crash!

DEC has sent me a good 3-4 patches for LATmaster and LATSYM on VMS V5.4-x
and V5.5.  These were patches to existing code, not new images.  The
problems were severe enough to warrent installing the fixes immediately.

>The question of use vs. abuse of PATCH needs to be managed.  Companies
>need to insure that PATCHES are reflected in source code changes as
>soon as the patches are cut to avoid issuing subsequent releases with the
>same bugs.

That has happened here.

-Dan Wing, DWING@UH01.Colorado.EDU or WING_D@UCOLMCC.BITNET (DGW11)
 Systems Programmer, University Hospital, Denver
From: eric@sejnet.sunet.se (Eric Thomas)
Subject: re: PATCH on ALPHA ?
Reply-To: ERIC@SEARN.SUNET.SE
Organization: SUNET, Stockholm, Sweden
Date: Thu, 3 Sep 1992 00:46:23 GMT

In article <2SEP199209361066@rover.uchicago.edu>, frank@rover.uchicago.edu (Frank - Hardware Hacker - Borger) writes:
> 	Mercifully I'm not generally involved at this now, but I once was,
> 	in the early days of RSX on 11s. I remember one series of patches.
> 
> 	Patch I		Reported to fix a problem that odd parity did not work
> 			right on a single line DC interface.
> 
> 	Patch II	Fixed the problem that patch I fixed odd parity, but
> 			broke even parity.
> 
> 	Patch III	Fixed the problem that patch II fixed even parity, but
> 			broke no parity.

Do you REALLY think this is any better without PATCH? A year or two after
designing the code update distribution scheme I mentioned (100% patch-free),
the vendor I mentioned had to invent a whole new type of distribution tape,
available only for one particular release of one of their major products.
Reason: there had been so many fixes to the fix that broke the fix that fixed
the fix that correct the problem (...) that installing the product on one of
the smaller CPU's (say something the speed of a MicroVAX 3600) took ONE WEEK OF
CPU TIME, to check that everything was in order (all pre-requisites applied,
all fixed to depending products also applied, etc). Each individual
sub-component had thousands of fixes; the single most buggy component was the
software update management system itself, which you had to fix before you could
use it to fix other programs.

So they got this great idea: they would get an employee to play the one-week
game on a freshly installed machine, and then they would dump the disks to
tape, and ship these tapes to customers who would just reload the data to the
corresponding directories. That looks like directly patching the software
update management system database if you ask me, but customers were DELIGHTED
:-)

  Eric
From: DWING@UH01.Colorado.EDU (Dan Wing)
Newsgroups: vmsnet.internals
Subject: Re: PATCH on ALPHA ?
Date: 3 Sep 92 19:38:46 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Rob Spencer, robbie@winkle.bhpese.oz.au, writes:

>However, I'd like to see DEC port almost everything else first! If they're
>going to spend development time, please let them spend it on porting
>products that we use everyday, not products that we may be able to save
>a bit of time with. It's a bit hard to patch a non-existent image!!
>(Some stuff is not expected to be available until 1994! Surely you could
>have sent me a CD distribution of the new images by then!)

The opposite is also true:  it is a bit hard to use an image that doesn't
work.

>but I wouldn't really put a lot of trust in a patch on a
>fairly new machine (You can't even buy them yet!) compared to a newly
>compiled program. How many ALPHA gurus can there be in the industry by now?
>And so what proportion of developers will be able to successfully make use
>of PATCH?

A newly-compiled program on Alpha is going to be just as buggy as a
newly-compiled program on VMS.  They'll both have bugs, and both will need
fixes, no matter if these fixes are delivered in the form of patches or new
images!

If your "stuff" is delivered in 1993 (instead of 1994), but didn't work, and
DEC had a fix, but couldn't send it to you except by next day air, I'm sure
you'd rather that Patch worked!

-Dan Wing, DWING@UH01.Colorado.EDU or WING_D@UCOLMCC.BITNET (DGW11)
 Systems Programmer, University Hospital, Denver
Newsgroups: vmsnet.internals
Subject: Re: VMS tuning for a vaxcluster (LAVC)
From: jeh@cmkrnl.com
Date: 27 Aug 92 17:53:26 PDT
Organization: Kernel Mode Consulting, San Diego, CA

In article <2504@mitech.com>, gjc@mitech.com (George J. Carrette) writes:
> Now. My question is, what good does this do in a VAXCLUSTER environment,
> specifically a LAVC environment? Here a page fault consists
> of both a trip over the ethernet and a trip to disk.
>
> Obviously if a satelite has the pages of an image already in memory,
> then you will winning big, avoiding a trip across the ethernet and everything.
>
> But what about the trip to disk? Is there a way to avoid that?
>
> The LAVC server node may have plenty of free memory, but it may have *never*
> activated any of the images that people on the LAVC's are interested in.
>
> Even if it had activated those images, would there be any optimization
> available? (That is, does the vaxcluster lavc disk server -know- that
> pages from a disk file may already be available in memory?)

Not as far as the pager is concerned.  The pager is interested in either finding
a page on the local free or modified page list, or (for global valid pages) in
the working set of another process on the local node, or in the image file.
Again, if we had cluster-wide global sections... even read-only ones...

> In VMS 5.4-3 I was using the hack of having all images from SYS$SYSTEM
> and SYS$SHARE also available on the local hard disk. That is a bit hackish,
> so I didn't bother re-doing that for VMS 5.5.

Here is another hack, and a partly-baked idea at that (ie I haven't thought
this through; it might not do what you want).  But if your server is all that
memory rich you could turn some of the memory over to a RAM disk driver, copy
the frequently-executed images to the RAM disk, and include the directories
in the RAM disk early in the SYS$SYSTEM: search list.

The bad part is that if those same images are activated on the server they're
going to be in memory TWICE on the server -- once in the RAM disk and again as
global pages (or process private pages if they aren't installed shared on the
server).

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
Newsgroups: vmsnet.internals
From: pettigrew@vertex.enet.dec.com (Mike Pettigrew)
Newsgroups: vmsnet.internals
Subject: Re: RE: VMS Tuning
Date: 26 Aug 92 17:49:23 GMT
Organization: Digital Equipment Corporation


In article <7895152@MVB.SAIC.COM>, SYSMAIL@VAX.LIVERPOOL-POLY.AC.UK writes...

> 
>...................................................However it may be better to
>distribute some of a huge free list to WSEXTENT and MPW_HILIMIT.  The modified
>list tends to be sized conservatively, and letting users have a larger
>working-set will cut down on even the soft-fault overhead.
> 
>Ronan Flood, Systems Manager (pro tem),
>Liverpool Polytechnic Computer Services.


Raising the values for MPW_HILIMIT and WSEXTENT to WSMAX has been done at a
number of heavily-loaded sites.  The results have been uniformly positive
in VMS 5.3 or later versions, with dramatic reductions in hard faulting,
and soft faulting, and visible improvments in application turnaround..

----------------------------------------------------------------------------
| -Mike Pettigrew        pettigrew_mi@ripple.enet.dec.com
|                        (206) 661-3032
|                        Digital Equipment Corporation 
|                        Federal Way, Washington, USA
|___________________________________________________________________________
|These opinions are mine and not necessarily my employer's
----------------------------------------------------------------------------
From: SCHENKENBERG@Monmouth-ETDL1.Army.MIL
Newsgroups: vmsnet.internals
Subject: Re: DR bad, VAX PRO good
Date: Tue, 1 Sep 1992 10:21 EDT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

murphy@npri6.npri.com replied with the following to posting I made to the
use(full/less)ness of Digital News and Review...

>> SCHENKENBERG@Monmouth-ETDL1.Army.MIL claims that Digital Review and
>> the former Digital News are not worth the price (free, ha ha):
   FYI:  Aka. VAXman@Monmouth-ETDL1.Army.Mil.

>> [Stuff extracted from my first posting]

>> maybe; i refuse to read DR or DN (i didn't even know about the merge) but
>> i have a very high opinion of VAX Professional!

>> maybe; i refuse to read DR or DN (i didn't even know about the merge) but
>> i have a very high opinion of VAX Professional!  hunter goatley, bruce ellis,
>> and many others contribute valuable articles every issue,...
      v-----------
Yours truly too!...  which is why I did not mention the particular publication.
I didn't want to sound like I was biased or prejudiced toward that publication.

VAX Pro. is a good publication.  And it does cost money... If your employer
won't cough up the subscription price then you should!  Don't sit back and
rely on the content of those fee-free, fact-free, fainiant forums for your
knowledge of technical issues.

I do however, have a few reservation about what has been happening in recent
issues and have discussed several of these with K.D.

The magazine is "VAX Professional, A Journal for VMS Systems".  Yet, lately,
there have been columns focusing on Unix platforms, and other articles which are
approching the obscure in terms of their relationship to VAX and VMS operating
systems.

For example, 'On the C Side.'  Albeit, a good series for C programming issues,
I think the market is overwhelmingly saturated with books and articles on the
subject.  Professional Press, the publisher of VAX Pro., DEC Pro., and several
other magazines has  its own library of books on the subject.  Why not devote
this space to more VAX and VMS related articles.

I like the VAX Professional.  I don't want it to become the K-mart of computer
programming issues;  I'd rather see it remain the 'specialty' store for VMS
pertinent knowledge.

BJS-
From: RSPECTOR@vax4.bear.com
Newsgroups: vmsnet.internals
Subject: Searching the lock list for locks associated with a file
Date: 25 Aug 92 18:29:52 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

I am trying to create a utility that will search the lock list database on all
systems in a cluster and return lock information about all the locks for a
specified file or records within the file.

I wrote a program that runs on every system in the cluster.  It executes the
system service $GETLKI in kernal mode to search all the locks on a given system.
This program looks for a matching resource name.  If one is found, the lock
information will be displayed.  If there is no match, the lock could possibly
be for a record within the specified file.  The program will check to see if
this lock has a parent lock id.  If the id exists, the parent's resource name
will be checked for a match.  If a match is found, then the lock information
will be displayed.  If there is no match, then the lock will be skipped.

This solution will not work.  It is very slow.  There are about 30,000 locks
at any one time in use.  It also appears that my process uses a lot of the CPU
and goes into RWSCS state quite often.  Therefore, I am looking for an
alternative.

I would like to be able to write some privileged code to calculate a hash value
for the specified file and find the resource block from the hash table.
Once I have this I will be able to find the sub resource blocks and all the
locks associated with the resource and sub resources.

I would appreciate any help with this matter.


Robin Spector
Bear Stearns Inc. & Co.
New York, N.Y. 10167
(212) 272-3696
From: critz@star.enet.dec.com (Richard Critz)
Newsgroups: vmsnet.internals
Subject: Re:  MACRO32 vs. Alpha
Date: 31 Aug 92 19:32:21 GMT
Reply-To: critz@star.enet.dec.com (Richard Critz)
Organization: Digital Equipment Corporation, Nashua, NH


In article <714675321.287197.MILLER@TGV.COM>, MILLER@TGV.COM writes:
|>
|>SDA works fairly well.  Patch does not seem to have been ported yet.
|>Both of those will understand Alpha opcodes instead of VAX.
|>
|>-bruce
|>

SDA on OpenVMS Alpha is actually a bit more advanced than on OpenVMS VAX.
Patch not only has not been ported, there are no plans to port it.  The
support mechanism for correcting images is to replace them, not patch them.

--
-----------------------------------------------------------------------------
Richard Critz					      critz@star.enet.dec.com
      -- I speak only for myself; I make no commitments for Digital. --
-----------------------------------------------------------------------------
From: usr7495a@tso.uc.EDU
Newsgroups: vmsnet.internals
Subject: (None)
Date: 4 Sep 92 01:31:51 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

signoff macro32 kevin j. cordell
Newsgroups: vmsnet.internals
Subject: Re: Booting MicroVAX 3400 using non-system UIC
From: jms@mrsvax.mis.arizona.edu (Entia non sunt multiplicanda praeter necessitatem)
Date: 31 Aug 1992 15:23 MST  
Reply-To: jms@arizona.edu
Distribution: world,local
Organization: University of Arizona MIS Department
X-Lunar-Date: 1 day, 20 hours, 35 minutes since the new moon
News-Software: VAX/VMS VNEWS 1.41    

In article <503@ssdc.UUCP>, eseeger@ssdc.UUCP (Eric Seeger) writes...
> 
>Is there a way to boot up a MicroVAX 3400 running VMS V5.4 so that a 
>site specific definition can reside in a different UIC group instead of 
>the system accounts group.  

Trivial.  This is something that we've been doing for years.  Here
is an example from the system startup files:

$ set uic [aais]
$ create/name_table/parent=lnm$system_directory/prot=(W:R) lnm_aais
$ set uic [system]
$ ! logical name tables created; now fill them:
$ run/uic=[aais]/priv=(tmpmbx,netmbx,grpnam)/noauth -
        /input=disk$sneezy:[aais.dba.logicals]logical_table.aais -
        /output=disk$sneezy:[aais.dba.logicals]logical_table.aais_error -
        /error=disk$sneezy:[aais.dba.logicals]logical_table.aais_error -
        sys$system:loginout

The .COM procedure specified in the /input switch then looks like this:

$ assign/table=lnm_aais disk$pima:[aais.world.exe]addcall.exe tpu$calluser
$ assign/table=lnm_aais disk$pima:[aais.world.exe] aais_exe

Make sure, of course, that you check for errors occasionally.

jms

Joel M Snyder, 1103 E Spring Street, Tucson, AZ, 85719 
Phone: 602.882.4094 (voice) .4095 (FAX) .4093 (data)
BITNET: jms@Arizona  Internet: jms@arizona.edu  SPAN: 47541::telcom::jms
I want EARS!  I want two ROUND BLACK EARS to make me feel warm 'n secure!!
From: SYSMGR@IPG.PH.KCL.AC.UK
Newsgroups: vmsnet.internals
Subject: re: RE: VMS tuning for a VAXcluster (LAVC)
Date: 28 Aug 92 15:32:18 GMT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Harvey Brydon writes:

...

> My claim is that paging through [an unloaded] ethernet is faster than to a
> local disk.  Of course if a lot of systems page this way, you will have a
> network contention problem which will slow things down.  [By the way, this
> assumes paging to another VMS system.  Paging to an Infoserver, as per the
> VXT2000 workstation is essentially the speed of the disk on the infoserver,
> plus you are generating ethernet traffic.  There is no caching on an
> Infoserver.]
>
> Any disagreements with the above?  Anybody do any quantitative testing on
> this?

An interesting viewpoint, and this may  be true if you have low-end
satellites on a high-end boot server with state-of-the-art disks (or
disk arrays) on an HSC. It certainly is NOT true if your boot node is simply
the most powerful VAXstation in a cluster of ten or twenty others, all with
SCSI disks.

The real weakness in the argumemt, I think, is the idea of an unloaded Ethernet.
10 Mbps was close to infinite when Ethernet was invented, but at most sites
today backbone traffic is saturating at peak times. Using a local disk for
paging (and for copying frequently used images to) reduces load on the
Ethernet, which is good all round. We really need something faster than
Ethernet: I can only hope that the prices of FDDI kit will fall rapidly in
the next few years (and that copper alternatives to fibre will be offered).

What would be really nice would be a cheapish box that took data to-and-from
a boot node at high speed (like FDDI) but in some simple-to-engineer way
(like bit-parallel words down a ribbon cable - maybe use standard SCSI bus?)
This box would in turn have (say) eight ordinary Ethernet ports emerging
from it. Internally it would function like a very fast multiport bridge.
The driver for this box would have an interface just like an Ethernet port
driver, but the data throughput would be a lot higher. I'm a physicist
not an electronics wiz, but I would have thought that a box like
this could be made a lot cheaper than an FDDI repeater and interface, and
by distributing satellites on the ethernet strings connected to it one
could increase the bandwidth between them and the server considerably.
Any entrepreneurs out there?

        Nigel Arnot

                NRA%ipg.ph.kcl.ac.uk@nsfnet-relay.ac.uk   (internet)
                NRA%uk.ac.kcl.ph.ipg@ukacrl.bitnet        (bitnet)
Newsgroups: vmsnet.internals
From: pettigrew_mi@ripple.enet.dec.com (Mike Pettigrew)
Subject: Re: RE: VMS tuning for a vaxcluster (LAVC)
Organization: Digital Equipment Corporation
Date: 28 AUG 92 10:09:23 PDT


In article <9208281401.AA18734@sndsu1.sinet.slb.com>, brydon@dsny25.sinet.slb.com writes...

> 
>My claim is that paging through [an unloaded] ethernet is faster than to a
>local disk.  Of course if a lot of systems page this way, you will have a
>network contention problem which will slow things down.  [By the way, this
>assumes paging to another VMS system.  Paging to an Infoserver, as per the
>VXT2000 workstation is essentially the speed of the disk on the infoserver,
>plus you are generating ethernet traffic.  There is no caching on an
>Infoserver.]
> 
>Any disagreements with the above?  Anybody do any quantitative testing on
>this?


Experiments with a production system of approximately 120 VAXstations on
a LAVC, show that local page and swap files consistently offer better
performance than paging or swapping to disks on the server.

Caching adjustments on the server, beyond the defaults computed by AUTOGEN
did not appear to have a critical effect on performance.

What does have a very critical effect is changes to the system parameters
WSMAX, MPW_HILIMIT, PQL_MWSQUOTA, PQL_MWSEXTENT , and also changes to the
SYSUAF field WSEXTENT.  On a memory-rich system, these fields can be raised
to much higher values than the default calculations.

The practical effect of raising these parameters is to eliminate paging
and swapping activity on the sattelite nodes althogether.

If you INSTALL all of the images that you are using on the sattelite nodes,
and keep a free list of about 4,000 pages, you will rapidly have all of
the relavent system image pages cached in the free list at the sattelite
node.

Ethernet bandwidth is comparable to the disk transfer speeds, thus light
access to COM files and incidental data files is as fast from the server
as it is from a local disk.  If you have lots of users, and your applications
have many COM files, you will run into problems with seek contention, and
should consider local disks.  If you have an application that uses many data
files or is I/O intensive, you will have seek and bandwidth contention, and
again should consider local disks.

----------------------------------------------------------------------------
| -Mike Pettigrew        pettigrew_mi@ripple.enet.dec.com
|                        (206) 661-3032
|                        Digital Equipment Corporation 
|                        Federal Way, Washington, USA
|___________________________________________________________________________
|  Surprises Every Day!
|___________________________________________________________________________
|These opinions are mine and not necessarily my employer's
----------------------------------------------------------------------------
From: "(Jon Pinkley, Westinghouse (216)486-8300 x1335)"
Newsgroups: vmsnet.internals
Subject: How myths are born...
Date: Wed, 26 Aug 92 02:48:55 -0400
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

Jamie Hanrahan, Kernel Mode Consulting, San Diego CA, writes concerning
MMG and VMS tuning in general:

>Lots of well-known "authorities" on VMS get these details wrong, repeatedly,
>in print.  Professional courtesy prevents me from naming names.

Unfortunately, it isn't limited to software.  It seems that the "free" trade
rags have lots of inaccurate "facts" in their columns.

I was really disappointed with a recent column that "explained" Modems and
the V. specs.  It was written by a winner of the DECUS Award for Technical
Excellence (Highest Technical Award).  (For Jamie's sake, I will state that I
am not talking about him.  As far as I know, he doesn't write a column, but
perhaps he should.)  No wonder there is so many Myths to debunk.

Which brings me to my point.   Jamie, can you please post the notes from
your excellent talk at DECUS:  "The VMS Scheduler: Myth vs. Reality"

Jon Pinkley  jon@clevax.wec.com  ...uunet!tron!clevax!jon (216)486-8300 x1335
From: SCHENKENBERG@Monmouth-ETDL1.Army.MIL
Newsgroups: vmsnet.internals
Subject: Re: STACK LAYOUT IN SPECIAL KAST?
Date: Fri, 28 Aug 1992 14:25 EDT
Organization: Macro32<==>Vmsnet.Internals Gateway
X-Gateway-Source-Info: Mailing List

>> I'm hacking some code to watch a process, and I want to see which procedures
>> it's been calling.  Basically I send an IPL2 KAST to the process when it's
>> CUR from some code on the timer queue, and I intend the KAST code to check
>> previous call frames to find the saved PC.
>>
>> When I'm in the KAST how can I find the saved PC, PSL and FP of the code
>> I've interrupted, so that I can trace back through the stack.

I'm not sure of what you mean by a KAST?  I Special Kernel AST or an AST run-
ning at KERNEL access mode?

If its a special Kernel AST, the ast routine is not invoked in the same fashion
as a normal AST.  A SKAST is called thru a JSB a normal AST thru a CALLG.

In a normal AST the AP will point to 5 arguments. The saved R0, R1, PC and the
PSL, along with, the optional AST parameter (if one was specified.) You should
be able to walk back the call frames from the current FP to get the info you
want.

Th SKAST is different.  The delivery of the AST routine is accomplish thru a
JSB instruction.  The AST delivery routine places the address of the target
processes PCB in R4 and the address of the ACB in R5.  You should be able to
access the data you want from these structures.  The SKAST runs at ipl 2,
disabling the delivery of other ast's until it RSB's back, and should provide
enough synchronization to the structures you want to read information from.

BJS-