R022AF07@VB.CC.CMU.EDU (Andy Foulke) (05/21/88)
Hello All,
I have been having a problem with a program creating a process
using CREPRC. If the output of the executable has been
redirected in ANY way it doesn't create the subprocess and execute
the commands in the datafile. I have included the coding of a
short pascal program and the datafile below.
Now to explain my problem in a little more detail...
For example,
The program works fine when I use the following DCL commands:
$RUN DETACH_PROG
$TYPE SYS$LOGIN:DETACH_PROG.LOG
[....log file is here with information...]
HOWEVER,
If I use the /INPUT, /OUTPUT or /DETACH qualifier the program
doesn't create the log file and doesn`t execute the commands in
DETACH_PROG.DAT. It seems ANY redirection of I/O to the program
will cause the subprocess not to be created.
For example,
$RUN DETACH_PROG /OUTPUT=SYS$LOGIN:ANYTHING.HERE
$TYPE SYS$LOGIN:DETACH_PROG.LOG
or
$RUN DETACH_PROG /DETACH
$TYPE SYS$LOGIN:DETACH_PROG.LOG
Any ideas or suggestions why it won't work?!?!
I am working with VMS 4.7
and have PASCAL 3.5. My process quotas are as follows and I
even have DETACH privilege enabled. (Even though DETACH isn't
needed here)
Process Quotas:
CPU limit: Infinite Direct I/O limit: 18
Buffered I/O byte count quota: 49904 Buffered I/O limit: 18
Timer queue entry quota: 10 Open file quota: 114
Paging file quota: 28711 Subprocess quota: 4
Default page fault cluster: 64 AST limit: 22
Enqueue quota: 200 Shared file limit: 0
Max detached processes: 0 Max active jobs: 0
Please send any replies to me, as I will be sure to summarize
a solution to the net if one is found! Thank You!,
U CCCCC U Joseph Rafail
U C M U Carnegie Mellon University
U CCCCC U Computing Services - Software Development
UUUUUUUUU R022JR3H@VB.CC.CMU.EDU (or CMCCVB.Bitnet)
------------------------------- CUT HERE ---------------------------------
{ DETACH_PROG.PAS -- This program creates a process and runs DETACH_PROG.DAT}
[INHERIT('SYS$LIBRARY:STARLET.PEN')] PROGRAM DETACH_PROG(INPUT,OUTPUT);
VAR PID_ADR : UNSIGNED;
PRCNAM,ERROR_STUFF,OUTPUT_STUFF,INPUT_STUFF,IMAGE: VARYING[50] OF CHAR;
STATUS : INTEGER;
BEGIN
STATUS := 0;
PRCNAM := 'DETACH_PROG';
IMAGE := 'SYS$SYSTEM:LOGINOUT.EXE';
INPUT_STUFF := 'SYS$LOGIN:DETACH_PROG.DAT';
OUTPUT_STUFF := 'SYS$LOGIN:DETACH_PROG.LOG';
ERROR_STUFF := 'SYS$LOGIN:DETACH_PROG.ERR';
STATUS := $CREPRC(PID_ADR,IMAGE,INPUT_STUFF,
OUTPUT_STUFF,ERROR_STUFF,,,
PRCNAM,,,,,);
WRITELN('STATUS OF DETACH_PROG IS ',STATUS);
END.
------------------------------- CUT HERE ---------------------------------
$! DETACH_PROG.DAT file which will be executed
$WRITE SYS$OUTPUT "THIS IS LINE ONE."
$WRITE SYS$OUTPUT "THIS IS LINE TWO."
------------------------------- CUT HERE ---------------------------------LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (05/24/88)
I have been having a problem with a program creating a process using CREPRC. If the output of the executable has been redirected in ANY way it doesn't create the subprocess and execute the commands in the datafile.... For example, The program works fine when I use the following DCL commands: $RUN DETACH_PROG $TYPE SYS$LOGIN:DETACH_PROG.LOG [....log file is here with information...] HOWEVER, If I use the /INPUT, /OUTPUT or /DETACH qualifier the program doesn't create the log file and doesn`t execute the commands in DETACH_PROG.DAT. It seems ANY redirection of I/O to the program will cause the subprocess not to be created. For example, $RUN DETACH_PROG /OUTPUT=SYS$LOGIN:ANYTHING.HERE $TYPE SYS$LOGIN:DETACH_PROG.LOG or $RUN DETACH_PROG /DETACH $TYPE SYS$LOGIN:DETACH_PROG.LOG [produce no output.] Using any of /INPUT, /OUTPUT, or /DETACH produces a detached process, one that is not part of your job tree; so all the examples you've had problems with end up looking pretty much the same. They are, in fact, all running into the same "gotcha'": The file spec you provide for /INPUT or /OUTPUT is passed, COMPLETELY UNINTERPRETED, to the created process. The created process will then try to open the file. It must be able to do so, IN ITS OWN CONTEXT; that is, any logicals used in the file specs must be defined in that context. When you create a detached process, it starts out with its own job table, so it can't inherit the job-wide definition of SYS$LOGIN that the creating process has. Well, where did that definition come from? LOGINOUT put it there when the process logged in. A process created with $CREPRC (or RUN/DET) does NOT run LOGINOUT (although you can have it do so explicitly). Hence, it has no definition for SYS$LOGIN, so its attempt to open its output file fails. Boom. How could you have found this out yourself? When a process dies, unless it has disabled accounting (not the case here), its final exit status is written to the accounting file. If you had used the ACCOUNTING command to check the accounting record for your processes, you would probably have found that the final exit status was "failed to open output file", or some such. Not a huge amount of information - without knowing about the problem with logicals, probably not enough to let you figure out what is going on - but sometimes enough to get you started. -- Jerry
jayz@cullsj.UUCP (Jay Zorzy) (05/27/88)
From article <8805240340.AA01194@ucbvax.Berkeley.EDU>, by R022AF07@VB.CC.CMU.EDU (Andy Foulke): > I have been having a problem with a program creating a process > using CREPRC. If the output of the executable has been > redirected in ANY way it doesn't create the subprocess and execute > the commands in the datafile. I have included the coding of a > short pascal program and the datafile below. > . > . > . > If I use the /INPUT, /OUTPUT or /DETACH qualifier the program > doesn't create the log file and doesn`t execute the commands in > DETACH_PROG.DAT. It seems ANY redirection of I/O to the program > will cause the subprocess not to be created. Looking at your "Run" commands and your code for $CREPRC, you are using the JOB logical name SYS$LOGIN in the specs for your input, output, and error files. Since you are attempting to create a detached process, rather than a subprocess, this job logical name table is not available. Therefore, process creation fails upon attempt to open any of these files, and thus no log file. The only way you could find this out would be to use the Accounting utility -- it logs all process creations and reasons for termination. Jay Zorzy Cullinet Software San Jose, CA
XPMAINT%venus.tamu.EDU%KL.SRI.COM%lbl%sfsu1.hepnet@LBL.GOV (05/28/88)
Received: from KL.SRI.COM by LBL.Gov with INTERNET ;
Thu, 26 May 88 23:00:56 PDT
Received: from TAMU.EDU by KL.SRI.COM with TCP; Wed 25 May 88 08:16:20-PDT
Received: from venus (VENUS.TAMU.EDU) by TAMU.EDU (AA01664); Wed, 25 May 88 10:16:28 MDT
Received: by venus id <2020C0AE191@venus> ;
Wed, 25 May 88 10:17:39
Date: Wed, 25 May 88 10:10:19
From: Shane Davis <XPMAINT@venus.tamu.edu>
Subject: RE: Subprocess creation problem
To: info-vax%kl.sri.com@tamu.edu
X-Vms-Mail-To: EXOS%"info-vax%kl.sri.com@helios",JNET%"r022af07@cmccvb"
Message-Id: <880525101019.2020C0AE191@venus>
>Hello All,
>
> I have been having a problem with a program creating a process
> using CREPRC. If the output of the executable has been
> redirected in ANY way it doesn't create the subprocess and execute
> the commands in the datafile. I have included the coding of a
> short pascal program and the datafile below.
>
> Now to explain my problem in a little more detail...
>
> For example,
> The program works fine when I use the following DCL commands:
>
> $RUN DETACH_PROG
> $TYPE SYS$LOGIN:DETACH_PROG.LOG
> [....log file is here with information...]
>
> HOWEVER,
> If I use the /INPUT, /OUTPUT or /DETACH qualifier the program
> doesn't create the log file and doesn`t execute the commands in
> DETACH_PROG.DAT. It seems ANY redirection of I/O to the program
> will cause the subprocess not to be created.
>
> For example,
>
> $RUN DETACH_PROG /OUTPUT=SYS$LOGIN:ANYTHING.HERE
> $TYPE SYS$LOGIN:DETACH_PROG.LOG
>
> or
>
> $RUN DETACH_PROG /DETACH
> $TYPE SYS$LOGIN:DETACH_PROG.LOG
>
> Any ideas or suggestions why it won't work?!?!
> I am working with VMS 4.7
> and have PASCAL 3.5. My process quotas are as follows and I
> even have DETACH privilege enabled. (Even though DETACH isn't
> needed here)
I believe I know what your problem is. I was bitten by a similar one not long
ago and had to go through the accounting logs to find out what had happened
to my process.
The problem is that SYS$LOGIN is not defined for the detached process and
when you use /INPUT, /OUTPUT, or /ERROR DCL does not perform any logical name
translation for those files; no attempt is made to translate them until
after the detached process is created. Thus, the way you are creating the
process, no logical device names exist except those in the SYSTEM or GROUP
tables for the detached process.
If you need to use SYS$LOGIN or would like the benefits of your LOGIN.COM,
do a RUN/DETACH/AUTHORIZE and information will be fetched from your UAF
record, thus giving definitions for SYS$LOGIN.
--Shane Davis
Systems Programming Assistant
Texas A&M Univ. Computing Services Center Software Systems Group
********************************************************************************
BITnet THEnet Internet
XPMAINT@TAMVENUS THOR::XPMAINT xpmaint@venus.tamu.edu
RSD1901@TAMSIGMA ZAC::RSD1901 --------
X233SD@TAMVM1 ------ x233sd@tamvm1.tamu.edu
SPAN: UTSPAN::UTADNX::(THEnet addr)
********************************************************************************