Dear Group,

I have a detached process that I wish to execute and wait for
completion of a DCL command procedure.   Since it is a detached
process I have no CLI so I cannot use lib$do_command etc.

I have seen from the system services manual sys$creprc and attempted
to use it.  I have been able to create a detached process, however I
have not been able to execute the command procedure and wait for its
completion.

Is sys$creprc the correct system service to use?  Does anyone have an
example is C or Fortran that uses sys$creprc to execute and wait for
the completion of a command procedure from a detached process.

Thanks

Stuart

stuie_norris@yahoo.com.au schrieb:

> I have a detached process that I wish to execute and wait for
> completion of a DCL command procedure.   Since it is a detached
> process I have no CLI so I cannot use lib$do_command etc.
> 
> I have seen from the system services manual sys$creprc and attempted
> to use it.  I have been able to create a detached process, however I
> have not been able to execute the command procedure and wait for its
> completion.
> 
> Is sys$creprc the correct system service to use?  Does anyone have an
> example is C or Fortran that uses sys$creprc to execute and wait for
> the completion of a command procedure from a detached process.

Out of a program, sys$creprc is o.k., but if You want a CLI (DCL), then 
the image to start must be the DCL login program
SYS$SYSTEM:LOGINOUT.EXE: it establishes a DCL environment with the usual 
symbols and process logicals. As the input for the process specify a DCL 
procedure which in turn should run the target image.

I don't have an example ready, but pass to sys$creprc parameters 
equivalent to the DCL command:
  RUN/DETACH/AUTH SYS$SYSTEM:LOGINOUT/input=myproc.com/output=mylog.log
And in myproc.com:
$! establich default directory etc.
$ RUN myimage
$ EXIT

-- 

  Joseph Huber   - http://www.huber-joseph.de

stuie_norris@yahoo.com.au wrote:
> Dear Group,
> 
> I have a detached process that I wish to execute and wait for
> completion of a DCL command procedure.   Since it is a detached
> process I have no CLI so I cannot use lib$do_command etc.
> 
> I have seen from the system services manual sys$creprc and attempted
> to use it.  I have been able to create a detached process, however I
> have not been able to execute the command procedure and wait for its
> completion.
> 
> Is sys$creprc the correct system service to use?  Does anyone have an
> example is C or Fortran that uses sys$creprc to execute and wait for
> the completion of a command procedure from a detached process.
> 
> Thanks
> 
> Stuart
> 

The customary trick used when you want a detached process to have DCL 
available is to have it run LOGINOUT.EXE.

On Oct 14, 11:16 am, "Richard B. Gilbert" <rgilber...@comcast.net>
wrote:
> stuie_nor...@yahoo.com.au wrote:
> > Dear Group,
>
> > I have a detached process that I wish to execute and wait for
> > completion of a DCL command procedure.   Since it is a detached
> > process I have no CLI so I cannot use lib$do_command etc.
>
> > I have seen from the system services manual sys$creprc and attempted
> > to use it.  I have been able to create a detached process, however I
> > have not been able to execute the command procedure and wait for its
> > completion.
>
> > Is sys$creprc the correct system service to use?  Does anyone have an
> > example is C or Fortran that uses sys$creprc to execute and wait for
> > the completion of a command procedure from a detached process.
>
> > Thanks
>
> > Stuart
>
> The customary trick used when you want a detached process to have DCL
> available is to have it run LOGINOUT.EXE.- Hide quoted text -
>
> - Show quoted text -

Yep. And here is an example stub from a real world application:

$!
$       run sys
$system:loginout                                         -
                /process_name =
"Advocate_Srvr"                         -
                /uic
=[346,6]                                -
                /
noswap                                                 -
                /
noresource_wait                                        -
                /
priv=all                                               -
                /input          = CSMIS
$com:advocate_server_init.com    -
                /output         = CSMIS
$log:advocate_server.out         -
                /ERROR          = CSMIS
$log:advocate_server.err         -
                /prior          = 4
$!

The file "advocate_server_init.com" could simply contain one DCL line
like "$run my_app.exe"

Neil Rieck
Kitchener/Waterloo/Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/links/cool_openvms.html
http://www3.sympatico.ca/n.rieck/links/openvms_demos.html

In article <fespq2$5fv$1@online.de>, Joseph Huber <joseph.huber@NIRWANA.web.de> writes:
> 
> Out of a program, sys$creprc is o.k., but if You want a CLI (DCL), then 
> the image to start must be the DCL login program
> SYS$SYSTEM:LOGINOUT.EXE: it establishes a DCL environment with the usual 
> symbols and process logicals. As the input for the process specify a DCL 
> procedure which in turn should run the target image.

   This is exactlly what the $CREPRC documentation is supposed to say.
   I wonder what the OP actually tried.

On Oct 14, 5:24 am, stuie_nor...@yahoo.com.au wrote:
> Dear Group,
:
> Is sys$creprc the correct system service to use?  Does anyone have an
> example is C or Fortran that uses sys$creprc to execute and wait for
> the completion of a command procedure from a detached process.

Stuart,

The main question has been answerred.
But what abour the undelying question...
what are you really trying to do... in the command procedure to be
launched ?

You wouldn't be the firrst one to use such mechanism for a 'submit' or
'mail' where a direct call to SYS$SNDJC or MAIL$mublefratz would be so
much more elgant and more efficient without being much more difficult
than the (apparently too difficult) call to sys$creprc.

Cheers,
Hein.

On Oct 14, 6:56 pm, Neil Rieck <n.ri...@sympatico.ca> wrote:
> On Oct 14, 11:16 am, "Richard B. Gilbert" <rgilber...@comcast.net>
> wrote:

*** repost ***

$!
$!
$run sys$system:loginout                    -
 /process_name ="Advocate_Srvr"             -
 /uic =[346,6]                              -
 /noswap                                    -
 /noresource_wait                           -
 /priv=all                                  -
 /input= CSMIS$com:advocate_server_init.com -
 /output= CSMIS$log:advocate_server.out     -
 /ERROR= CSMIS$log:advocate_server.err      -
 /prior= 4
$!
$!

BTW, the only reason for doing this is to attach a CLI (command
language interpretor) so that certain calls like LIB$ will work.

Neil Rieck
Kitchener/Waterloo/Cambridge,
Ontario,Canada.
http://www3.sympatico.ca/n.rieck/links/cool_openvms.html
http://www3.sympatico.ca/n.rieck/links/openvms_demos.html

Neil Rieck <n.rieck@sympatico.ca> writes:

>*** repost ***

>$!
>$!
>$run sys$system:loginout                    -
> /ERROR= CSMIS$log:advocate_server.err      -
>$!
>$!

Note that DCL does something funky with SYS$ERROR when starting up.
Usually harmless, but if you go looking for CSMIS$log:advocate_server.err
and don't see it, that's why.

>BTW, the only reason for doing this is to attach a CLI (command
>language interpretor) so that certain calls like LIB$ will work.

Not all LIB$, just a few of them, such as LIB$SPAWN and LIB$SET_LOGICAL
and things like CLI$PRESENT.

In article <1192485201.923845.294680@k35g2000prh.googlegroups.com>,  Neil Rieck <n.rieck@sympatico.ca> writes:
> On Oct 14, 6:56 pm, Neil Rieck <n.ri...@sympatico.ca> wrote:
>> On Oct 14, 11:16 am, "Richard B. Gilbert" <rgilber...@comcast.net>
>> wrote:
> 
> *** repost ***
> 
> $!
> $!
> $run sys$system:loginout                    -
>  /process_name ="Advocate_Srvr"             -
>  /uic =[346,6]                              -
>  /noswap                                    -
>  /noresource_wait                           -
>  /priv=all                                  -
>  /input= CSMIS$com:advocate_server_init.com -
>  /output= CSMIS$log:advocate_server.out     -
>  /ERROR= CSMIS$log:advocate_server.err      -
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

What is this?  SYS$SYSTEM:LOGINOUT.EXE discards the
pre-existing translation for SYS$ERROR (using it as a parameter in
oddball cases such as DECNET connects) and arranges things so
that the SYS$ERROR process permanent file always points to a copy
of the SYS$OUTPUT process permanent file.

$ run sys$system:loginout /auth /detach -
 /input=disk_user:[decuserve_user.briggs]test.com -
 /out=disk_user:[decuserve_user.briggs]test.log -
 /error=disk_user:[decuserve_user.briggs]test.err -
%RUN-S-PROC_ID, identification of created process is 000E6375
$ type test.log
This is test.com
  ORG_FILE_NAME = "EISNER$DRA3:[DECUSERVE_USER.BRIGGS]TEST.COM;20"
  ORG_FILE_NAME = "EISNER$DRA3:[DECUSERVE_USER.BRIGGS]TEST.LOG;4"
  ORG_FILE_NAME = "EISNER$DRA3:[DECUSERVE_USER.BRIGGS]TEST.LOG;4"

$ type test.com
$ write sys$output "This is test.com"
$ ppf = "$sys$login:ppf"
$ ppf sys$input
$ show sym org_file_name
$ ppf sys$output
$ show sym org_file_name
$ ppf sys$error
$ show sym org_file_name
$ exit