can't start detached process with sys$system:loginout.exe

[Chris D Cook]

I am trying to run a simple program in a detached process by passing a starter script as an input file:

run /detached /augh /input='infile /output='outfile /error='errfile /proc='procname sys$system:loginout.exe

type 'infile
$! starter.com
$ run tempdir:blah.exe

blah.exe contains an infinite-loop that appends a small message to a tempfile every few seconds. I can check the file to see if the process is running.

After the run command, I get a message telling me the id of the new process, but blah.exe never seems to get started, and the new process is either not started, or stops immediately.

If I issue the run command with blah.exe as the file to be executed (instead of loginout) it works, but I am using the input since I will soon need to pass parameters into the app.

I did see messages posted that the detached process would not have access to certain logicals, so I tried absolute addresses in place of logicals, but that made no difference.

Also, just for kicks, i tried running loginout interactively and it ended my session. Didn't know if this was normal or not since I have been unable to find documentation about what loginout actually does (and how).

Thanks in advance.

[Chris D Cook]

7.3-2 in case that makes a difference.

[Jim_McKinney]

> run /detached /augh /input='infile /output='outfile /error='errfile /proc='procname

I presume that "augh" is only a typo in your posting and not the code.

Does 'outfile' get created? If so, what are its contents?

Use VMS ACCOUNTNG to determine the final status of the job - it will likely provide a clue.

$ ACCO/FULL/ID=xxxxxxxx

where those x's are replaced by the PID that you observe when the detached job is started.

> what loginout actually does

Either performs the requisite actions to accomplish a login or a logout. Since you were already logged it knew to log you out :)

[Robert_Boyd]

I presume /AUGH is really /AUTH ?

Do you have Accounting turned on? if so have you looked for accounting records for the process start/termination?

Do you get a logfile created for outfile? If you did get an OUTFILE created, there should be some message(s) in it.

All of your apostrophes should be in matched pairs. Your command should be

run /detached /augh /input='infile' /output='outfile' /error='errfile' /proc='procname' sys$system:loginout.exe

The way you typed it in will not evaluate properly. If you actually had the command the way you typed it in here, you probably had some of the symbol interpretation fail which would have made the run fail to open the input or output. You should see that logged in the accounting record(s) for the process.


Robert

[Robert_Boyd]

Fooey -- I duplicated the typo for /augh -- it should be /auth ;-)

Oh well !!

[Jim_McKinney]

> The way you typed it in will not evaluate properly.

In this case the symbols in the command line will translate correctly due to the trailing space delimeter for each of the symbols introduced with a single-quote character. However, I agree that it is bad policy to not pair up the quotes.

As noted, "/augh" is incorrect. But, the fact that command execution resulted in the creation of a process indicates that this wasn't actually part of the command line that was executed as it would have been rejected by DCL and the RUN would never have executed at all.

[Chris D Cook]

I reran the procedure to get the information requested, and wouldn't you know... it worked this time. I have looked for things that may have changed, but so far I haven't found anything.

I will keep this thread open for a little longer in case it starts acting up again.

Yes, augh was a typo.

Thanks for the suggestions; hopefully this stays "fixed"

Chris

[Robert_Boyd]

Jim,

Thanks for the correction -- I have to say though that it is so easy to make a mistake and leave out the blank and I have been bitten so many times by mismatched apostrophes and/or quotation marks. There have been some bizarre commands executed because of mismatches -- and some cases were very difficult to debug. One reason why I do really like to use DCL_CHECK on procedures that are going to become production code. I don't always agree with everything DCL_CHECK flags, but at least I get flagged on everything of importance.

Another possibility is a security issue -- if the requested output file or input file are not accessible by the user starting the detached process, so it might be helpful to do a REPLY/ENABLE=SECURITY before doing the run command and see if you get any OPCOM alerts.

Robert

[Mohren]

I have got a similar problem. I tried to start a detached process by
run /detached /input=test.com sys$system:loginout.exe
with test.com:
$ runexe=="data1:[user.mohren_j]test"
$ runexe
$ exit
With acco/full/id= I mostly only get information of quite old processes (march 06)

Thanks in advance for your help

[Wim Van den Wyngaert]

You don't get sys$scratch and sys$login. Define them yourself in the script.

I also specify /input=f$parse("file") because loginout doesn't understand (all) logicals.

I would still check with accounting why the startup failed.

Wim