finding out another process's default directory?

[Jess Goodman]

What is the easiest way to determine the current default directory for another process under Alpha VMS 7.3-2 ?

TIA

[labadie_1]

What do you mean, sys$login of this user or the directory in which he is at the moment ?

[Hoff]

Assuming this is not a discussion of SYS$LOGIN or SYS$LOGIN_DEVICE, the RMS parsing defaults are process-private AFAIK.

This information is maintained within some process logical names and within a system service, and AFAIK there are no related APIs to access the associated SYS$DISK logical name and the SYS$SETDDIR system service directory information across processes.

Accordingly, the best approach is to have a cooperating application communicate that setting as needed.

To confirm this, made a quick pass through the sys$getjpi itemcodes for OpenVMS V8.3, and see nothing relevant listed. This service would be the logical spot to implement this.

Kernel-mode hackery is certainly feasible.

[Derek Garson]

If this is required purely for informational purposes then the answer is that VMS itself does not provide that functionality.

If this is required because the application design really needs this then I would suggest changing the application design.

Regardless of the above, bear in mind that the current default directory can be a rather ornery beast, depending as it does on any number of process private logical names, particularly where the default directory is set to a search list.

[Hoff]

{{{Regardless of the above, bear in mind that the current default directory can be a rather ornery beast, depending as it does on any number of process private logical names, particularly where the default directory is set to a search list.}}}

That, and it's wicked fickle.

[Jess Goodman]

Some server processes on our systems sometimes start writing temporary files to a directory that should never be used for temporary files. The program that is writing the file uses the current default directory (instead of SYS$SCRATCH like it should, but it's not our code and it probably just uses a C RTL call, TMPNAM or TMPFILE).

I can identify the process that wrote the files *after* the fact from security audits. But I would like to identify when one of these server processes actually changes their default directory by monitoring this important process attribute somehow.

I know there is no $GETJPI item code or other API for it. I can find out the current default device by getting the tranlation of SYS$DISK via ANALYZE/SYSTEM and CLUE PROCESS/LOGICAL. So I was looking for a SDA method or a kernel-mode program that could return the current directory. (On my VAX 6.2 systems we have a program called "P" that can do this.)

[Hein van den Heuvel · Accepted solution]

The way to get this is to queue a kernel mode AST to the PID in question and then pick up PIO$GT_DDSTRING in the context of the targetted PID.

Brian 'VAXman' Schenkenberger made examples of this back in 1993. And there is also an even older 'lib_default_dir' routine out there.

Not sure where that stands with OpenVMS versions, Itanium ports and so on.

With SDA you can most certainly just read it:
ANAL/SYSTEM
SDA> SET PROC AUDIT_SERVER
SDA> ex PIO$GT_DDSTRING;20
00000000 00000000 00000000 00000000 00000000 0000005D 45584553 59535B08 .[SYSEXE]....................... 00000000.7FFD0290

There's your counted string.

SDA> set proc hein
SDA> ex PIO$GT_DDSTRING;20
00000000 00000000 00005D4E 4945482E 52455355 5F455652 45535543 45445B15 .[DECUSERVE_USER.HEIN].......... 00000000.7FFD0290

Google is your friend.

hth,
Hein.

[Jan van den Ende]

Re Hein.

Yeah, that DOES get you the -directory-; but _NOT_ the device on which to search that directory. Which might be a Concealed Device, and/or a searchlist. Both are already demonstrated by [SYSEXE] ; which normally should reside in SYS$SYSROOT: , which is both.

This looks to be only half the answer.

Proost.

Have one on me.

jpe

[Jess Goodman]

Thanks Hein, that was what I was looking for. I did GOOGLE but I guess I didn't know what to search for.

Jan, that was the entire answer to my quesion -as I already said you can get the current translation of SYS$DISK from SDA's CLUE PROCESS/LOGICAL command.

Thread closed.

[Hunter Goatley]

Regarding Hein's mention of queueing kernel-mode ASTs, VMS made this a lot easier and safer on Alpha and Integrity by providing the kernel-level routine EXE$READ_PROCESS. It does the AST queueing to fetch data from another process's context. It still has to be called from kernel-mode, but it wouldn't be very hard to write a kernel-mode routine that will get the PIO$GT_DDSTRING value for another process using EXE$READ_PROCESS.

My GETCMD utility makes use of this (albeit in BLISS):

http://vms.process.com/ftp/vms-freeware/fileserv/getcmd.zip

(The VAX version still does the old queue-an-AST method.)

Hunter