Operating System - OpenVMS
1748210 Members
2760 Online
108759 Solutions
New Discussion юеВ

Issue to launch EXE as detached process

 
SOLVED
Go to solution
Sethunath K.O
Occasional Advisor

Issue to launch EXE as detached process

Hi All

I would like to get your help on the following

We submit a DCL script which calls other scripts that launch the BASIC.EXE (written in Decbasic program). This BASIC.EXE create a detach process (created using sys$creprc) that will call the MAIN.EXE (in C++) that contains call to the function socket/applications.

If I run this MAIN.EXE directly in command prompt then the program is working fine. But when I run through the above method (as detached process) it fails as return and error as " CMD: Failed to create connect socket: function not implemented ". Can you please throw some light on it?

Also it is working in some of other servers. I have checked most of the user privileges that seems to be same. Do I need to check for any special privilege for the same?


Thanks
Sethu
11 REPLIES 11
Hein van den Heuvel
Honored Contributor

Re: Issue to launch EXE as detached process

just google: $creprc detached fail
And READ some of the returned results.

You may want to use LIB$SPAWN instead,
Or specify LOGINOUT as the image and have it run the real image.

The failure message suggests to me that it is a secndary failure and that a primary failure, possibly getting a logical name value, went unnoticed.

Is that BASIC.EXE really useful?
Could a well crafted command line RUN command take its place?

Hein.

Robert Gezelter
Honored Contributor

Re: Issue to launch EXE as detached process

Sethu,

I concur with Hein. There is likely an unreported failure of a system service call.

A thorough review of the sources is in order. A short term fix is to use the OpenVMS Debugger to try to identify the particular call that is failing. However, in my experience, when there is one such error, there are likely to be more. The thorough source review is a far sounder alternative.

- Bob Gezelter, http://www.rlgsc.com
John Gillings
Honored Contributor
Solution

Re: Issue to launch EXE as detached process

Sethu,

When you create a detached process running just an image, that's all you get - a "naked" image. Such a process lacks an underlying CLI (usually DCL), and therefore quite a few things don't work. The most obvious is SPAWN.

The other downside is your process does NOT inherit quotas the way you might expect. Unless you've specified a "quota" argument containing a valid PQL to $CREPRC (and be VERY careful how you define your PQL - everyone gets the structure wrong the first few times), your process will run using the SYSGEN parameters PQL_D*, which are typically way too low to do anything useful.

In your case I'd guess you're doing domething that requires a CLI without realising it, or with insufficient quotas.

To confirm change your $CREPRC to execute SYS$SHARE:LOGINOUT.EXE with an INPUT file containing the DCL command "$ RUN MAIN". This will execute your program on top of DCL, and will login as yourself, and thus inherit your UAF quotas.
A crucible of informative mistakes
Sethunath K.O
Occasional Advisor

Re: Issue to launch EXE as detached process

Hi John & All

Thanks for the reply. It is helpful.
The Basic.exe (Decbasic program) has a structure (record) where it manipulate the PLD* structure. The way of manipulation is get all the parameter from the username by (getuai call). But one parameter is hard coded as string pqllst::quota_list = 71 and the sys$crepc call is as follows

sys_status = sys$creprc( pidadr, file_name,in_log, out_log,err_log,,pqllst::quota_list by ref, process_name, uai_pri by value, uai_uic by value,,prc$m_imgdmp by value )

When I removed pqllst::quota_list to 0 (to get default quota) then it is working fine. I think now it is taking default quota. Please let me know whether I am right? (Also what should the correct value of that?)

I also try $CREPRC to execute SYS$SHARE: LOGINOUT.EXE with INPUT - DCL command "$ RUN MAIN".

Thanks very much
Sethu
Hoff
Honored Contributor

Re: Issue to launch EXE as detached process

You'll have to post up the declaration of the quota list record structure to ensure this, but -- if it works without, and fails with -- you've certainly got a good candidate for the trigger.

The quota list -- I don't see an example around anywhere -- is a contiguous sequence of byte-longword pairs that end with a null pair, and this is passed by reference. In BASIC, this would often be created with a RECORD declaration.

Probably the fastest way to the solution would involve posting a small standalone example that launched some random image, should you have difficulties getting the PQL process quota list to work.

I dug around in the usual places and didn't see an example of BASIC with sys$creprc with a PQL, but you've got most of the example written. Whoops. Just found (a really old) example here:

http://mvb.saic.com/freeware/vax82a/linedrop/startup.bas

John Gillings
Honored Contributor

Re: Issue to launch EXE as detached process

Sethu,

The PQL for $CREPRC is a horrible structure. It's an array of 5 byte entries (each is a BYTE LONG pair). The trick is it must be packed, and these days most languages don't like to do that. You may need some pragmas or other language specific directives to force the compiler to not align the fields (I'm not sure how this is expressed in BASIC).

It's so tricky that the official OpenVMS course Programming System Services sample program has it wrong! Instead of setting working sets as intended, it sets the CPU limit to some absurd number. What was worse, you couldn't see the error in the source code, or even using symbolic names under DEBUG. As far as I know the bug in the courseware has never been fixed (I specifically requested it NOT be fixed, but the instructors notes be updated so they know about it, and can use it as an example)

To check your PQL, examine it directly under DEBUG and make sure you can follow the byte/long sequence, and the parameters are correct. You'll need $PQLDEF and $CREPRC documentation to decode the structure:

DBG> EXAMINE/HEX/LONG pqllst::quota_list
DBG> EXAMINE/HEX/LONG
DBG> EXAMINE/HEX/LONG

etc..

On the other hand, if you run LOGINOUT you can omit the PQL
A crucible of informative mistakes
John Gillings
Honored Contributor

Re: Issue to launch EXE as detached process

re: Hoff

>Just found (a really old) example here:
>
>http://mvb.saic.com/freeware/vax82a/linedrop/startup.bas

Wow! and I thought C was an ugly language! ;-) That is truly hideous!

! the following is to set QUOTA in CREPRC &
\ MAP (DUM1) LONG LST(3%) &
\ MAP (DUM1) WORD WD(7%) &
\ LST(0%)=0% &
\ LST(1%)=0% &
\ LST(2%)=0% &
\ LST(3%)=0% &
\ WD(0%)=(6%+20%*256%) &
! 6 is the value of PQL$_FILLM..to allow following processes to hove &
! more than the default of 10 files opened. Since my default is 20 &
! I allowed 20 max for detached proc &
\ WD(2%)=10%*256% ! 10 is PQL$_WSQUOTA &
\ WD(3%)=450% ! set to 450 instead of default 120 &
\ WD(5%)=(7%+16%*256%) ! 7 is PQL$_PGFLQUOTA &
\ LST(3%)=39% ! the 16 above plus this 39 together set 10000 in &
! quota list &

What it really wants to say is:

PQL=((PQL$_FILLM,20),
(PQL$_WSQUOTA,450),
(PQL$_PGFLQUOTA,10000),
(0))

There MUST be a clearer and simpler way to express this, even in BASIC!
A crucible of informative mistakes
Sethunath K.O
Occasional Advisor

Re: Issue to launch EXE as detached process

Hi John & Hoff

Thanks very much.
For the reference I have attached the Decbasic program.
Please note that I have modified this Decbasic program (written in 80├в s) with -$CREPRC to execute SYS$SHARE: LOGINOUT.EXE with INPUT - DCL command $ RUN MAIN ├в With out PLD structure- and it is working fine.


Thanks and Regards
Sethu
Hoff
Honored Contributor

Re: Issue to launch EXE as detached process

Your sys$getjpiw call is broken. No status check. No IOSB. That's weak coding practice, as it assumes no errors. Something akin to this for the status:

CALL lib$stop(stat by value) IF (stat AND 1%) = 0%
CALL lib$stop(iosb_status by value) IF (iosb_status AND 1%) = 0%

Same for lib$get_foreign, SYS$TRNLNM, etc.

There's a way to include the system services definitions from within basic$starlet; that's available with a line such as this one:

%include "STARLET" %from %library "SYS$LIBRARY:BASIC$STARLET.TLB"

I'd suggest the following, as BASIC defaults for declarations don't necessarily match your expectations:

OPTION TYPE = EXPLICIT

Most system services really don't like to find floating point, for instance.

What is this quota_list stuff? You need pass the address of the array; assigning a value into that variable just looks wrong. That assignment looks to stop on the contents.

There's also some potential confusion here on establishing quotas; you'll want to size them for the application image (if you're not running under DCL), rather than reading the values off a UAF entry.

sys$getjpiw status isn't checked (the return status from the system service is just if the call started, not if the call worked; the call success is determined via the IOSB). And FWIW, the process name can be replicated within a UIC group (arguably a bug, but there was no solid interlock here when last I looked), and is explicitly allowed to be replicated across groups, and a test such as shown is always group specific.

A test such as sys_status <> ss$_normal misses a whole pile of potential successful return status values. (That's why there's a low-bit test shown above.)

I haven't yet looked at the code in any detail around the failing quota list; this is just a quick skim for coding issues and coding errors I've encountered over the years... (If I can get to the code itself, that'll be later today...)

Stephen Hoffman
HoffmanLabs LLC