Operating System - OpenVMS
1748226 Members
4644 Online
108759 Solutions
New Discussion юеВ

Re: Problems with $CREPRC

 
Shashikant_B
Occasional Advisor

Problems with $CREPRC

Hi All,

We are having some problems while doing $CRPRC in Uniface 7.2.06 and
Open VMS V7.3-2.
The requirement is to run another uniface session (as a
asynchronous/detached process) from the current uniface session.


We have written this C code to create a detached process.
/* include files */
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include


int main(int argc, char **argv)
{
..............
struct dsc$descriptor_s cmdStr, bTimeOut;


static const $DESCRIPTOR (image_name_d, "SYS$SYSTEM:LOGINOUT.EXE");


static const $DESCRIPTOR (process_name_d, "ec_sys_creprc");


static const $DESCRIPTOR (inparams,
"DKA200:[DANZAS1.EUP.DEV]input.txt");


sprintf(cmdStr.dsc$a_pointer, "%s %s %s %s %s %s",
"@CON2CW_CALLEU3.COM",
EXE_FILE,
ASN_FILE,
"ICW_CON",
termcd,


shell_params);


RetStat = lib$spawn (&cmdStr, 0, 0, &FlagsMask, 0, &spawn_pid);
RetStat = sys$creprc(&spawn_pid, &image_name_d, &inparams, 0, 0, 0,
0,
&process_name_d, &cmdStr, 0, 0,
PRC$M_INTER|PRC$M_NOPASSWORD, 0, 0);


printf("Spawn pid is %x Restat is = %d\n\n", spawn_pid, RetStat);


The strange thing is that the retstat is 1which is correct, but the
process is not executed/the log file is even not created.


Could anyone please help in this?
Please let me know if you need some more information.


Regards,
Rajni.


5 REPLIES 5
Wim Van den Wyngaert
Honored Contributor

Re: Problems with $CREPRC

Did you check with accounting if the process was created and how it terminated ?

Is the file you @ in the home directory ?

Wim
Wim
Shashikant_B
Occasional Advisor

Re: Problems with $CREPRC

Hi,

Yes we had seen accounting/id. The result of this command is -
Date / Time Type Subtype Username ID Source Status
--------------------------------------------------------------------------------
24-APR-2006 11:08:33 IMAGE LOGINOUT EU3BUD 00000EDB 000184C4
24-APR-2006 11:08:33 PROCESS SUBPROCESS EU3BUD 00000EDB 000184C4


Status is 000184C4.
And the message interpreatation is

MESSAGE = "%RMS-F-DEV, error in device name or inappropriate device type for o
peration"


Please let us know what could be the probable reason of this error.

Regards,
Rajni.
Joseph Huber_1
Honored Contributor

Re: Problems with $CREPRC

First: in Your code I see a spawn call followed by a creprc: which of the two does not work ?
I assume the second one:
You doe not specify an output device in the creprc call, therefore no "log file", and I assume also this is the reason why the program does not run at all.
In addition, You specify a string descriptor
(&cmdStr) in the creprc argument list, where an integer (base priority) is expected: are You confusing spawn and creprc ?
If You specify LOGINOUT as the image to run, then sys$input (Your inparams string) must be the DCL procedure to execute.
I have the impression, what You really want is to call spawn with cmdStr as command to execute, not creprc:
lib$spawn(&cmdStr,&inparams,&outputfile,...)
http://www.mpp.mpg.de/~huber
Hein van den Heuvel
Honored Contributor

Re: Problems with $CREPRC

Is this actual code, or a cut & paste job.

If it is the real code, then 'go back to start, do not pass go'.
The spawn and creprc 'almost' do the same thing, the only essential difference being that spawn creates a sub-process while creprc creates a detached process.
In the code presented the 'spawnid' and 'RetStat' from the spawn are both over-written by the creprc.
One of the two (the spawn) has to go.
To debug, just clone that printf and stick it between the spawn and creprc.
After that you can relate the PID in the accounting file to the right call.
Rigth now you only have the pid of the creprc.

Be sure to heed Joseh's comments.

hth,
Hein.


John Gillings
Honored Contributor

Re: Problems with $CREPRC

Rajni,

Your $creprc does not specify a PQL. It will therefore inherit SYSGEN PQL_D* quotas which are typically VERY low. The most common symptom is the process starts but fails very early due to lack of some quota. Not even enough to write a sensible error message. The completion status for the process in ACCOUNTNG.DAT may help, but it probably isn't worth even investigating until you've specified reasonable quotas, without a change in symptom.

Beware the PQL data structure, it's badly aligned (byte, long, byte long...), so you'll need to work fairly hard to ensure it's correct. Check the structure by examining it in HEX at runtime from DEBUG to make absolutely certain you've got it right. The C compiler will do its best to align the structure, which will make all your quota definitions wrong!

Try something like this:

#pragma __member_alignment __save
#pragma __nomember_alignment
typedef struct pqls
{
char item;
int value;
} pqls;
#pragma __member_alignment __restore

pqls pql_list[] = {{PQL$_WSDEFAULT,1024},
{PQL$_WSQUOTA,1024},
{PQL$_WSEXTENT,2048},
... other quotas ...
{PQL$_LISTEND}};

Make sure you specify all quotas for the process.

(left as an exercise to find the PQL$ symbols)
A crucible of informative mistakes