Detached process does not run, but no error indicated

[John Popernack]

I am having a problem detached processes.

I have some processes that I used to run detached all the time. They don't run anymore and I don't know what has changed.

The program is normally launched from another program via SYS$CREPR. The call returns SS$_NORMAL, but no new process is created. Normally, the process runs continuously until it gets a command to exit. I determined that the first line of code in the program is never executed. If I run the program "un-detached" it runs fine. The same thing is observed if I run it detached from the DCL prompt. When running from the DCL prompt I get a message that the process was started with PID = XXX.

To simplify the experiment, I created a test program that simply writes a text string to a file and exits. Again, everything is fine running normally, but not detached.

I ran each of the programs with the /dump qualifier and then ran the dump analyzer. The dump file was not created.

I am running OpenVMS version 7.2-1. My account has IMPERSONATE privilege and Maxdetach = 0. I also tried setting Maxdetach to 2. Actually, the account I am using has all privileges authorized and granted by default.

Any ideas?

Thanks
John

[Jan van den Ende]

John,

first check:

DID the process even get created?

ACCOUNTNG is THE tool to find out!
And _IF_ it was, then the final status can give you vital info!

If not, one further question:
It used to function, you write.

Same VMS version, same user?
I am thinking various quota here, later VMS versions tend to require ever more, or a different user might have different quota, even the same user might have altered quota.

Just the first things to check, and on the answers, we can take it from there.

Proost.

Have one on me.

Jan

[Bojan Nemec]

John,

Try to set the PRC$M_IMGDMP flag in the stsflg (the last one, where you set the PRC$M_DETACH flag) of the SYS$CREPRC system service. You will receive a dump file (on yours current default directory, image name with the .DMP type). You can analize this dump, with:

$ ANALIZE/PROCESS dumpname

This command puts you in the debugger where you can inspect what hapens.

Bojan

[John Popernack]

Jan-

Thanks. I will try the ACCOUNTING utility. I'll let you know what I find out. I am not familiar with it, so it may take a while. In the meantime, the answers to your questions:

I am using the same version of OVMS as I did when it worked and the same user. I don't believe the user quotas have changed, but I tried all the tests with another user (that we never change) and got the same results.

[Bojan Nemec]

John,

Sorry, I forgot that you can force the dump (mentioned in my previous post) when you use the run command with the /DUMP qualifier:

$ RUN/DETACHED/DUMP ...

Bojan

[John Popernack]

Jan-

I ran accounting/user={username} and then ran the process detached from another window. The process never showed up.

Thanks

[Lokesh_2]

Hi John,

Is your system sylogin.com (logical sys$sylogin) changed recently?

Something like the following is added:

if f$mode() .eqs. "OTHER" then logout

Thanks & regards,
Lokesh

[John Popernack]

Bojan-

I tried the /dump qualifier at the DCL prompt and no dump file was created.

Thanks

[Bojan Nemec]

John,

No dump file means that the program exited normaly. To get Jans accounting information try with this sequence:

$ T=F$TIME()
$ RUN/DETACHED ...
$ ACCOUNTING/USER=you/SINCE="''T'"/FULL

Bojan

[John Popernack]

Lokesh-

Actually it has changed. I placed the line

set term/perm/insert/vt100

in the MODE_OTHER section
I commented this out, logged off, logged on and re-ran the test. The same thing happened. The only other line in that section is

Exit 1

I'm not sure, but I don't think the exit command is the problem - I think that has always been there.

Thanks
John

[Bojan Nemec]

John,

You must avoid any terminal settings if you are not sure that you have a terminal attached to yours process.

Maybe you can try to debug the program (if you have the sources and posibility to compile the program with the debugger). Here is an Ask the wizard page which speaks about debugging deatached processes:

http://h71000.www7.hp.com/wizard/wiz_4640.html

Bojan

[John Popernack]

Bojan-

I placed that command there on accident and never removed it (I should have put it in the INTERACTIVE_MODE section). I decided to put the command into individual login.com files instead and never went back to clean it up.

Thanks
John

[Dale A. Marcy]

I have not seen the command that you are executing to create the detached process, but it might be worth looking at the protections on any input and/or output files specified to see if they have been changed.

[John Popernack]

Dale-

I created and ran a new test executable that simply writes a text string to a file then exits. If I run the test program normally, the file is created and contains the text string. If I run it detached, it does not. This test program should run detached, so I don't think I need to check input/output files of the other program. Also, I don't think there could be a security issue, since I can run either program normally and they function fine.

Thanks
John

[Dale A. Marcy]

That makes sense, but I saw where you said your account had all privileges by default and was not sure that was the same account you were using for the detached runs.

[John Popernack]

Bojan-

I'm going to try your procedure. One question, though, will the ACCOUNTING utility continue to append to a log file after I'm done testing? Or is there anything else I should be aware of?

Thanks
John

[John Popernack]

Bojan-

I ran your procedure and it just hangs after the accounting command. I believe this means that it didn't run. Is that true?

Thanks
John

[John Popernack]

Dale-

Yes, that was the account I was using.

Thanks
John

[John Popernack]

Bojan-

I went to the link you sent to me for debugging detached processes. I am unfamiliar with some of the steps in the process. Do you know of any examples of this that exist?

Thanks
John

[Bojan Nemec]

John,

The accounting utility is managed with the command SET ACCOUNTING. You can see which resources are tracked by the accounting with the SHOW ACCOUNTING command. The ACCOUNTING command runs a program which reads the accounting file (most times SYS$MANAGER:ACCOUNTNG.DAT or a file pointed by the logical name ACCOUNTNG).

Now, first check if you have enabled the process accounting, with the SHOW ACCOUNTING. You should see one of these lines:
PROCESS any process termination
DETACHED detached job termination

If accounting is not enabled for any of these resources, you can enable with:

$ SET ACCOUNTING/ENABLE=DETACHED

Then try to run the detached process.
Now you can try with the ACCOUNTING command. (you can use the /IDENT qualifier with the pid you receive from the RUN command or use my previous sequence of commands)

If you have enabled and want to disable accounting for detached processes use:
$ SET ACCOUNTING/DISABLE=DETACHED

Bojan

[Bojan Nemec]

John,

The debugging method depends on what you have on yours machine and how you run the detached process. First you must get a free terminal then if you have no input,output and error files in the run command, then you can just do

$ RUN/INPUT=term/OUTPUT=term/ERROR=term ...

If you have these files, than you must define the logical name DBG$INPUT and DBG$OUTPUT to point to this terminal. The logical names must be defined in a table which is visible by the detached process (mostly this is the group table of the detached process). Be aware that this will afect all processes which see this logical name, so if another user will run a debuger, this will start on yours terminal.

Now to the terminal. The most easy way is
when you have a workstation or an X connection, then you can create a terminal with:
CREATE/TERMINAL=DECTERM /NOPROCESS /DEFINE_LOGICAL=(term)

If you have directly connected terminals, pick one free and logout. From another terminal do:

$ SET TERMINAL/NOTYPEAHEAD term
This will prevent logins on that terminal!
($ SET TERMINAL/TYPEAHEAD term to reenable logins)
Now you have a terminal (or DECterm or a physical one) you define the logicals and run
the detached process (compiled and linked with debugger).

$ DEFINE/GROUP DBG$INPUT term
$ DEFINE/GROUP DBG$OUTPUT term
$ RUN/DETACHED

The debugger will start on the "term". After you have finished debugging, deassign the logical names and reset the terminal.

Bojan

PS

Now I see that you are new to this forum so:

Welcome to the VMS forum!

[Dale A. Marcy]

Have you looked at your PQL_D* and PQL_M* sysgen parameters to see if these values might have been changed to a low value? According to the DCL manual for detached processes:

- If you do not specify a value for a particular quota, that quota is given the value of the corresponding PQL_D* (default) system parameter.

- If you specify a value for a particular quota, that value is compared with the quotas for the creator process (maximum) and the system parameters PQL_M* (minimum). If the value you specify is within the allowed range, it is used for the new process. If you specify a value greater than the creator process's quota, the creator process's quota is used. If the specified value is less than the corresponding system parameter, the system parameter value is substituted.

If possible, please provide an example of the run command you are using for creating the detached process.

[John Popernack]

Bojan-

I entered the show accounting command and detached processes were enabled. I'll try the debugger. Thanks a lot for the info.

John

[John Popernack]

Bojan-

I tried the debugger. The DECterm window opened but the debugger did not start. I issued the following commands:

create/ terminal = decterm/ noprocess/ define_logical = dbg_term

define/ group dbg$input dbg_term
define/ group dbg$output dbg_term

run/ detach/ process_name = demo (process)

Is there a dbg$error that should be defined?

Also, I ran the program in normal mode (not detached) and the debugger started and I could step through the program. As soon as I exited, the DECterm window disappeared.

Thanks
John

[Bojan Nemec]

John,

Sorry, I forgot the dbg$error logical name. Try with defining it. There is a link to the debugger manual for debugging processes without CLI:

http://h71000.www7.hp.com/doc/73final/4538/4538pro_002.html#debug_with_nocli_sec

Note that you can not run the DECWindows debugger interface for detached processes.

Bojan