[Info-vax] Command to show process rms file opens?

[Craig A. Berry]

On 7/30/20 8:57 AM, Stephen Hoffman wrote:
> On 2020-07-30 12:52:15 +0000, David Hittner said:
> 
>> What is the command to show all RMS files being opened while the 
>> process executes commands? I recall seeing this in an "openvms 
>> internals" presentation somewhere, but can't remember what facility 
>> does this or how to invoke it.
>>
>> I have an MMS build that runs 2 hours 21 minutes, and would like to 
>> see if there's anything that I could do to speed up the file access, 
>> such as INSTALLing frequently accessed files and images, moving files 
>> to faster access media, etc. But in order to generate a solution to 
>> the the problem I need to know exactly which files are being accessed.

In addition to the SET WATCH FILE already mentioned, you can see what's
currently open with SHOW DEVICE/FILE and, in SDA, SHOW PROCESS/CHANNEL.

> 0: Use SSD.

Or DECram for some or all of the build, depending on the size of a dirty
build tree and how much memory you have.  You didn't say what language,
but if it's C or C++, the name mangler database is a very hot file and
IIRC there is a way to point it elsewhere.  Putting .OLB and/or .TLB
files referenced by the build on a RAM disk might also make a difference.

> 1: Use recent MMK, as that tends to work better than all but recent MMS. 
> And use SSD.
> 2: Use MMK (or MMS) logging, and set up build parallelism, if you have 
> the cores and the HDD spindles. And use SSD.

Consider contributing a /PARALLEL=N feature to MMK equivalent to make
-j.  Most build systems these days expect to be able to keep multiple
cores busy, but you can't do that on VMS that I'm aware of. This
assuming that disk I/O is not your only problem, which may be wrong.

> 3: Use SSD. SSD. SSD. SSD. SSD. SSD. SSD. SSD. SSD. Did I mention using 
> SSD?
> 4: If you're on HDD, use SSD. If you can't use SSD, don't saturate 
> glacial HDD spindles. And use SSD.
> 5: INSTALL and parallelism helps mask part of the glacial HDD speeds, 
> where SSD is massively faster than HDD.
> 6: I'd suggest using SSD here, too. Too many OpenVMS systems are still 
> using HDD.
> 
> 
>