- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Problems with $CREPRC
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-23-2006 08:01 PM
тАО04-23-2006 08:01 PM
Problems with $CREPRC
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-23-2006 08:46 PM
тАО04-23-2006 08:46 PM
Re: Problems with $CREPRC
Is the file you @ in the home directory ?
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-23-2006 09:23 PM
тАО04-23-2006 09:23 PM
Re: Problems with $CREPRC
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-23-2006 10:05 PM
тАО04-23-2006 10:05 PM
Re: Problems with $CREPRC
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,...)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-23-2006 11:56 PM
тАО04-23-2006 11:56 PM
Re: Problems with $CREPRC
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-24-2006 01:22 PM
тАО04-24-2006 01:22 PM
Re: Problems with $CREPRC
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)