Detached process does not run, but no error indicated

[John Popernack]

Dale-

The page file quota limit does not look right in SYSGEN. I don't think it has been changed, but I will try setting it higher (along with the default) to see if it has an effect. Currently, it is:

PQL_DPGFLQUOTA 65536 65536 -1 -1 Pagelets D
internal value 4096 4096 0 -1 Pages D
PQL_MPGFLQUOTA 32768 2048 -1 -1 Pagelets D
internal value 2048 128 128 -1 Pages D

also, here are some others that are probanly important:

PQL_DWSDEFAULT 3632 1024 -1 -1 Pagelets
internal value 227 64 0 -1 Pages
PQL_MWSDEFAULT 3632 512 -1 -1 Pagelets
internal value 227 32 32 -1 Pages
PQL_DWSQUOTA 7264 2048 -1 -1 Pagelets D
internal value 454 128 0 -1 Pages D
PQL_MWSQUOTA 7264 1024 -1 -1 Pagelets D
internal value 454 64 64 -1 Pages D
PQL_DWSEXTENT 524288 16384 -1 -1 Pagelets D
internal value 32768 1024 0 -1 Pages D
PQL_MWSEXTENT 524288 2048 -1 -1 Pagelets D

Do any of these appear to be too low to you? I would think that these are sufficient for the test program anyway.

The exact command I used from DCL was

r/detach/process_name=(name) (process)

I also tried it without the process name. It always returns with the normal message as if nothing was wrong.

Thanks
John

[John Popernack]

FYI-

Here is the test program source code (FORTRAN):

write(51,*) 'test started:'
end

Thanks
John

[John Popernack]

Bojan-

I tried again with dbg$error defined and got the same results. When you suggested to use the debugger, was the idea to get output (ie. error messages) to be displayed in the DECterm window? I thought I would be able to debug the program.

Thanks,
John

[Bojan Nemec]

John,

The idea was to debug the program and see why is exiting. The DECTerm window is suposed to run the debugger (character cell interface). Try also to add a the /ERROR=somelogfile qualifier to the run command. Maybe you will see some errors in this file.

Bojan

[John Popernack]

Dale-

I just noticed that my default page file quota is actually greater than the maximum. Not sure how that happened.

John

[Bojan Nemec]

John,

The idea was to debug the program and see why is exiting. The DECTerm window is suposed to run the debugger (character cell interface). Try also to add a the /ERROR=somelogfile qualifier to the run command. Maybe you will see some errors in this file.

Abbout yours test program. Sorry, but my FORTRAN is rusty (more than 20 years from my last program) but I suppose that you write "test started:" to SYS$OUTPUT. If it is so, you must also provide an output file with the /OUTPUT qualifier.

Detached processes have no input,output or error if you dont provide them in the RUN command or in the SYS$CREPRC system service. Note also that you have no CLI (DCL), so no symbols and some LIB$ routines which needs DCL.


Bojan

[John Popernack]

Bojan-

In FORTRAN write(51,*) will write the output to FOR051.DAT in your default directory.

Thanks,
John

[Dale A. Marcy]

Bojan, I had the same suspicions as you, so I created the fortran program and ran it detached. It did create a FOR051.DAT in my Sys$Login directory running the program detached.

John, I was looking at the quotas also, but did not have a definite answer. On at least one of my systems, I have increased the PQL_DPGFLQUOTA to 400000, but that system does a lot of ORACLE work and I think it was needed for ORACLE. I am still looking.

[John Gillings]

John,

The success message from the RUN command just means the process was started. What happens from then on isn't reported back to the creator process. There are two ways to determine if your process ran - one is ACCOUNTING, the other is to find the file it creates - it will be called FOR051.DAT and will either be in your SYS$LOGIN directory, or perhaps in the directory that was your default was set to when you started the process.

Given your command, LOGIN.COM will not be executed. IMPERSONATE privilege is not required because you're not starting the process under a different UIC.

This is a DETACHED process... that means it bears no relationship with the creator, so logical names defined will not affect it. If you have privilege, you can define the DBG$* logical names in the GROUP table. Otherwise, you need to run LOGINOUT and feed /INPUT with a command procedure containing the appropriate DEFINE commands.

But here are some simple rules for detached processes...

1) ALWAYS define ALL quotas, don't depend on PQL SYSGEN parameters. SEARCH SYS$STARTUP:*.COM for sample RUN commands.

2) Think about WHY you're using a detached process. Would a BATCH job be easier? Remember for a DETACHED process, you're responsible for all environment and you don't have DCL running underneath you (so, for example, SPAWN won't work)

3) All file names (including /INPUT/OUTPUT and /ERROR qualifiers) should be fully expanded. No process level logical names.

[John Popernack]

Bojan & Dale-

I increased my page file quotas (default and max) to 65536 and 2000000 respectively. I issued write current, write active, write default, exited and rebooted. I verified that the sysgen parameters were correct and re-ran. The same thing happened.

I ran it again using /error=error.log and nothing was written to error.log.

I'm begining to think this may all just be a bad dream and hopefully I'll wake up soon.

Thanks,
John

[Bojan Nemec]

John,

I say that my fortran is rusty (and now I see that is just more rusty than that I beleive).

So the output is not the problem, but also try to define it (it cant hurt).

Now back to the accounting.

I ran your procedure and it just hangs after the accounting command


I am not sure that the command hangs. Maybe yours sys$manager:accountng.dat is a huge file and contains years of accounting informations. Try to do a DIR/SIZE on this file and if has several thousand blocks give the accounting command enough time to find records. The command scans the file from the beginning and sequential searches all the records. If no records are found the command will exit at the end of the file. You can also try to run ACCOUNTING without qualifiers and see the whole contents of the accounting file (abort with Y if the dates are too old).

Bojan

[John Popernack]

FYI-

I have Oracle running on this system. After I rebooted, I ran the test program BEFORE starting up Oracle. The other process uses Oracle.

Also, it may be that I would be better off running a batch job, but I don't know that much about it. Anyways, the process (and many others like it) have run like champs for a very long time now and I would like to fix whatever is preventing them from running. If the test program cannot run detached, I don't see how anything has a chance at running detached.

Thanks,
John

[John Popernack]

Bojan-

The size of the file is 2388457 blocks. I'll try again and wait for it to complete.

Thanks,
John

[Dale A. Marcy]

If the existing accounting file is large, issue the SET ACCOUNTING/NEW_FILE command and try running the detached process again and repeat Bojan's instructions for checking the accounting record. The SET ACCOUNTING/NEW_FILE will not delete the old accounting file, but will create a higher version with nothing in it.

[John Popernack]

Dale-

I started a new accounting file and reran the process detached. I got the following message from the accounting utility:

Date / Time Type Subtype Username ID Source Status
--------------------------------------------------------------------------------
18-JAN-2005 15:17:47 FILE_BL 00000000 00000000

I guessed that this indicates a new accounting file, so I reran and the accounting utility gave the exact same message.

Thanks,
John

[Bojan Nemec]

John,

This is a huge accounting file. You (or yours system manager) should create a new accounting file as Dale suggested. Then you can backup this file, rename it to avoid purging or (depends on yours company policy) simply delete it. You will wait quite a lot of time to read the file.

Bojan

[Bojan Nemec]

John,

You reran the detached process after creating the new accounting file?

If yes, it seems that the process is not created.

Bojan

[John Popernack]

Bojan-

I started a new accounting file and reran (see previous post). The accounting record did not have any information on any process (detached or otherwise) so I am guessing that that record is probably created when a new accounting file is created. Is that true?

Also, I ran it one more time, ran the accounting utility and got the exact same output from the accounting utility.

Thanks,
John

[John Popernack]

FYI-

A while back, we installed a second cpu but we were sent the wrong cpu and the speeds did not match. We had it in there a few weeks before we realized the error. The only problem that I noticed to occur was that "main terminal" used to boot to a DECWindows logon and it would boot to a VT style terminal while the second cpu was installed. After the second cpu was removed, it went back to normal.

Could this have anything to do with it?

Thanks,
John

[John Popernack]

On second thought, forget about the second cpu thing. We have another alpha that we copy our software to for demos and it is doing the same thing on that alpha. That alpha has always had (and can only have) one cpu.

Thanks,
John

[Jan van den Ende]

So,

-- you have a fresh ACCOUNTNG file.
-- DETACH Accounting is enabled
but: NO process info whatsoever in ACCOUNTNG.

If you also enable Interactive and/or Network or Subprocess accounting, then activate any such process (and terminate it!), then does info about THAT appear in ACCOUNTNG?
... just to verify that if we think we are looking at accounting info, that is really what we do, and it _IS_ functioning.
It would be a pity if there was a problem there obscuring what we want to see!.

On Qouta: not specifically for Decwindows, but we HAVE quite regularly, on diverse kinds of processes, run into BYTLM being low. What are those PQL_*'s ?

hth,

Proost.

Have one on me.

Jan

[Kris Clippeleyr]

John,

Just a wild guess.
Over here we had a similar problem, that was caused by the redefinition of the logical name "LNM$TEMPORARY_MAILBOX". That logical is normally defined as LNM$JOB in the table LNM$SYSTEM_DIRECTORY (kernel mode).

FWIW,

Kris (aka Qkcl)

[Ian Miller.]

I have seen delays before I could see records in accounts but usually not more than 5 mins or so.

[John Popernack]

I figured it out. I was trying to think of when it stopped working and what changed at that time. It happened about the same time I split our development into two directories (3.1 and 4.0). I made two significant changes:

1) Recreated our shareable images with _31 and _40 at the end. This didn't seem like it could be the cause, since I ran the test program without any of those images installed.

2) Created a new root directory as a concealed device. This made it convenient to switch between the 3.1 and 4.0 directories (all the subdirectories are defined based on the concealed device, so I just redefine the concealed device logical). In order to switch between the two without messing up anyone else on the system, I defined the root logical /job instead of /sys. Since it is no longer defined system-wide, the detached process doesn't know the logical.

I know there are several ways to fix this. Any ideas on what is the best way?

Thanks for all the help,
John

[Jan van den Ende]

John,

any possibility of starting your detached process as running LOGINOUT.EXE with /INPUT= ?

Another possibility (although not my favorite choice)
Have the different DEFInes in different GROUP LNM tables, and run from a different GROUP UIC.

hth.

Proost.

Have one on me.

Jan