Conference hydra::axp-developer

From:	DEC:.REO.REOVTX::HUDSON       "[email protected] - UK Software
Partner Engineering 830-4121" 18-MAR-1997 16:10:29.01
To:	nm%vbormc::"[email protected]"
CC:	HUDSON
Subj:	RE:  No.23091, Company Nectar, stderr in subproc

Hello Mats Nilson,

Thank-you for your ASAP call on stderr in subprocess on VMS.

Because of the differences in the underlying operating systems, VMS C RTL
functions which provide an interface to Unix process manipulation do sometimes
behave on VMS differently than you might see on Unix. 

I think I need to see an example program though, to be able to understand the
exact problem you're having.  Can you forward me a code example that shows
this?

Regards

Nick Hudson
Digital Software Partner Engineering

From:	VBORMC::"[email protected]" "Mats Nilsson" 20-MAR-1997 06:36:20.43
To:	"[email protected] - UK Software Partner Engineering 830-4121
18-Mar-1997 1610 +0000" <[email protected]>
CC:	
Subj:	RE:  No.23091, Company Nectar, stderr in subproc

Reply to the message of Tuesday March 18, 1997 17:07 +0100
-----------------------------------------------------------------
hello

>I think I need to see an example program though, to be able to
>understand the exact problem you're having.  Can you forward me a code
>example that shows this?

This code i execute in my main process

     cc=3Diodu("CR",file,0 );  /* create a loggfile */
     if(cc =3D=3D 0) {
       cc=3Dopen(file, RWMODE);
       if(cc >=3D 0) {
         fill(znsys.loggfile,sizeof znsys.loggfile,0);
         movst0(file,0,znsys.loggfile,0,sizeof znsys.loggfile);
         cc =3D dup2 (cc, 2);
         cc =3D ( cc > 0 ? 0 : cc );
       }

and then all fprintf(stderr,"....) goes to the loggfile in the main
program

and then I fork a new process

#ifdef OPENVMS /* tidigare VAX */
    pid=3Dvfork();
    if(pid=3D=3D0)
      BEGIN
        path=3Dznpath(name);
        if(path !=3D 0)
          BEGIN
            LOG_EXECV(path, argv);
            cc=3Dexecv(path,argv);
          END
        if(errno =3D=3D EVMSERR)
          BEGIN
            znvmserr(vaxc$errno, errstring, sizeof errstring, 0);
            fprintf(stderr, "execv misslyckad rutin %s arggv[0],errstring
);
          END
        else
          BEGIN
            fprintf(stderr, "execv misslyckad rutin %s cc %d errno name,c=
c
,errno);
          END
        CONFIRM();
        exit(0);
      END
    else if(pid =3D=3D -1)
      BEGIN
        znseterr(ZNOSNAME, errno, RUTIN, "fork", name, " ");
      END
    return(pid);
#else


and in the subprocess the fprintf(stderr,"....) writes nothing to the
loggfile, it neither writes to the screen.

Where does it write ?


Best regards

Mats
+----------------------------------------------+
!                                              !
!    oooooo     ooooo  Nectar Systems AB       !
!    ooooooo    ooooo  Mats Nilsson            !
!      oooooo   ooo    Development Manager     !
!      ooooooo  ooo    [email protected]           !
!      ooo oooo ooo    Box 124                 !
!      ooo  ooooooo    S-281 22 H=E4ssleholm     !
!    ooooo   oooooooo  Tel. +46 (0)451 893 00  !
!    ooooo    ooooooo  Fax. +46 (0)451 817 30  !
!                                              !
! -For excellence in 4GL-                      !
!                                              !
+----------------------- http://www.nectar.se -+

% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by
vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id HAA17361 for
<[email protected]>; Thu, 20 Mar 1997 07:31:32 +0100
% Received: from nectar by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id
BAA31406; Thu, 20 Mar 1997 01:29:17 -0500 (EST
% Received: (from gmail@localhost) by nectar (8.6.12/8.6.12) id HAA17442 for
[email protected]; Thu, 20 Mar 1997 07:25:19 +0100
% Received: by gmail.nectar.se with Gmail (ginets/4.0.1) id 3330d830; Thu, 20
Mar 97 07:25:15 +010
% Date: Thu, 20 Mar 97 07:22:42 +0100
% Message-Id: <[email protected]>
% In-Reply-To: <[email protected]>
% From: Mats Nilsson <[email protected]>
% To: "[email protected] - UK Software Partner Engineering 830-4121
18-Mar-1997 1610 +0000" <[email protected]>
% Subject: RE:  No.23091, Company Nectar, stderr in subproc
% Mime-Version: 1.0
% Content-Type: text/plain; charset=ISO-8859-1
% Content-Transfer-Encoding: quoted-printable

From:	DEC:.REO.REOVTX::HUDSON       "[email protected] - UK Software
Partner Engineering 830-4121" 21-MAR-1997 15:56:19.19
To:	nm%VBORMC::"[email protected]"
CC:	HUDSON,wood_j
Subj:	RE:  No.23091, Company Nectar, stderr in subproc

Hello Mats

Thanks for the code example.  I think I have reproduced the problem - at least
in my program the value of stderr is not passed to the child process.  I am not
sure if this behaviour is intentional or not - in the past a similar problem
was reported and the answer was a bit vague.

So I have asked the engineering group to comment.

I am out of the office for the week beginning 24-Mar.  In the meantime a
colleague of mine will monitor the database to see what engineering say.

I am back in the office on 1-April.

Regards
Nick Hudson

PS John, it's #1019 in DECC.

From:	DEC:.REO.REOVTX::HUDSON       "[email protected] - UK Software
Partner Engineering 830-4121"  7-APR-1997 14:39:22.39
To:	nm%VBORMC::"[email protected]"
CC:	HUDSON
Subj:	RE:  No.23091, Company Nectar, stderr in subproc

Hello Mats Nilsson

Reference your ASAP question #23091, to do with fprintf(stderr,...) in a
subprocess.

Sorry I didn't get back to you earlier on this.  I notice you've since asked a
question on a similar theme, #25037 on fork(), which I will reply to
separately.


I asked the C engineering group to comment on the stderr problem and they said
that you should be able to access stderr from a child when it has been set up
by the parent, but there is presently an error in the DEC C RTL which prevents
this from working.  The engineering group is working to fix this error but has
no date to say when this fix will appear yet.

In the specific case that I was referring them to (since I didn't have a
complete program from you I made one up), they also said that changes would
need to be made to the source program.  I include below the information on that
in case it also applies to your case.


Here is my parent program:

================================================================================
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
main()
{
	int	pid;
	int	cc;
	char	*argv[] = {"SYS$SYSDEVICE:[HUDSON.ASAP.FORK]child.exe",NULL};

	cc = open("LOGFILE.DAT",O_APPEND | O_RDWR | O_TRUNC | O_CREAT);
	if (cc >= 0) {
		cc = dup2(cc,2);
		if (cc > 0) {
			cc = 0;
		}
	}
	fprintf(stderr,"\n\nthis is sent to stderr, before fork\n");

    pid=vfork();
    if(pid==0) /* we are the child if pid==0 */
      {
	cc = execv("SYS$SYSDEVICE:[HUDSON.ASAP.FORK]child.exe",
		argv);
        if(errno == EVMSERR)
          {
            fprintf(stderr, "EVMSERR error in child\n");

          }
        else
          {
            fprintf(stderr, "other error in child\n");
          }
        exit(0);
      }
    else if(pid == -1)
      {
        fprintf(stderr,"-1 from vfork\n");
      }
    return(1);


}
================================================================================

Here is my child program:

================================================================================
#include <stdio.h>
main()
{
	fprintf(stderr,"this is child writing to stderr\n");
	fprintf(stdout,"this is child writing to stdout\n");
}
================================================================================

The engineering group said:

> As stated in the DEC C RTL Manual, the way the child process inherits the
> parent's open files is that the exec functions pass the file-name string
> associated with each file descriptor to the child and the child opens
> the file. In the example the parent did not specify RMS sharing option
> allowing the child to read and write the file and the child's open() failed
> with "RMS-E-FLK, file currently locked by another user" status. After this
> failure, the file descriptor associated with stderr remained uninitialized
> and the first attempt to write to stderr resulted in calling internal DEC
> C RTL routine opening stderr on the SYS$ERROR device.
>
> To fix this, the open() statement in the parent program must look like the
> following:
>
>cc = open("LOGFILE.DAT",(O_APPEND | O_RDWR | O_TRUNC | O_CREAT),
>		"ctx=rec","shr=get,put","rop=rea");
>
> Unfortunately, this is not enough. The DEC C RTL does passes among other
> things RMS sharing options specified by the parent to the child, but the
> the child fails to process them correctly.
>
> This is being tracked in crtl internal bug tracking system 


Regards

Nick Hudson
Digital Software Partner Engineering

From:	VBORMC::"[email protected]" "Mats Nilsson"  8-APR-1997 07:37:29.56
To:	"[email protected] - UK Software Partner Engineering 830-4121
07-Apr-1997 1439 +0100" <[email protected]>
CC:	
Subj:	RE:  No.23091, Company Nectar, stderr in subproc

Reply to the message of Monday April 7, 1997 16:32 +0100
-----------------------------------------------------------------
Hello Nick

I see in your mail that you suggest that we shall open our files with
ctx=3Drec.

>cc =3D open("LOGFILE.DAT",(O_APPEND | O_RDWR | O_TRUNC | O_CREAT),
>=09=09"ctx=3Drec","shr=3Dget,put","rop=3Drea");

We has defined the Unix open to this function:

dkcopen(file,mod)
  char *file;
  int mod;
    {
       return(open(file,mod,0,"shr=3Dget,put,upd,del"));
    }

When we create a file we use an ordinary creat(filename,0666) and no
ctx=3Drec

When I add ctx=3Drec to the open statement I can not open the file.

I have discussed this problem earlier in October with ASAP, but could not
get it running. As I said then when I add data to a file after the EOF
mark a subprocess can not read this data, until the file is close. I even
sent a testprogram to prove it.

What does this ctx=3Drec mean, and are there any other keywords that i sh=
all
add to my open statement eg rop=3Drea, but I don't want any locking.

I have already created many houndreds of files so I can not change the
filetype of them.

Best regards

Mats
+----------------------------------------------+
!                                              !
!    oooooo     ooooo  Nectar Systems AB       !
!    ooooooo    ooooo  Mats Nilsson            !
!      oooooo   ooo    Development Manager     !
!      ooooooo  ooo    [email protected]           !
!      ooo oooo ooo    Box 124                 !
!      ooo  ooooooo    S-281 22 H=E4ssleholm     !
!    ooooo   oooooooo  Tel. +46 (0)451 893 00  !
!    ooooo    ooooooo  Fax. +46 (0)451 817 30  !
!                                              !
! -For excellence in 4GL-                      !
!                                              !
+----------------------- http://www.nectar.se -+

% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by
vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA09343 for
<[email protected]>; Tue, 8 Apr 1997 08:30:42 +0200
% Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by
mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA19124 for
<[email protected]>; Tue, 8 Apr 1997 08:37:27 +0200 (MET DST)
% Received: from nectar (nectar.nectar.se [193.14.116.1]) by server21.digital.fr
(8.7.5/8.7) with SMTP id IAA08426 for <[email protected]>; Tue, 8 Apr
1997 08:42:26 +0200 (MET DST)
% Received: (from gmail@localhost) by nectar (8.6.12/8.6.12) id IAA16684 for
[email protected]; Tue, 8 Apr 1997 08:34:33 +0200
% Received: by gmail.nectar.se with Gmail (ginets/4.0.1) id 3349e6e1; Tue, 8 Apr
97 08:34:32 +010
% Date: Tue, 8 Apr 97 08:31:03 +0100
% Message-Id: <[email protected]>
% In-Reply-To: <[email protected]>
% From: Mats Nilsson <[email protected]>
% To: "[email protected] - UK Software Partner Engineering 830-4121
07-Apr-1997 1439 +0100" <[email protected]>
% Subject: RE:  No.23091, Company Nectar, stderr in subproc
% Mime-Version: 1.0
% Content-Type: text/plain; charset=ISO-8859-1
% Content-Transfer-Encoding: quoted-printable

From:	DEC:.REO.REOVTX::HUDSON       "[email protected] - UK Software
Partner Engineering 830-4121"  8-APR-1997 15:06:39.26
To:	nm%VBORMC::"[email protected]"
CC:	HUDSON
Subj:	RE:  No.23091, Company Nectar, stderr in subproc

Hello Mats

>I see in your mail that you suggest that we shall open our files with
>ctx=rec.

This is related to the "stderr" issue - the answer to that is that it is meant
to work - i.e. you should be able to have parent and child both sharing stderr,
but at the moment (due to a bug in the C RTL) it won't work.    The bug in the
C RTL is specifically related to the way that a child process inherits file
handle information when forked from a parent.


>I have discussed this problem earlier in October with ASAP, but could not
>get it running. As I said then when I add data to a file after the EOF

I looked this up and the problem statement is a bit different - about two
processes sharing a file and having the parent reading the data that the child
wrote.  From the previous ASAP info I looked up, this should be possible
(although you may be affected by the C RTL bug I suppose).

Could you send me a complete program that shows what the problem you're having
is?  Ideally one that I can build on Unix and VMS so I can see the difference?

Thanks
nick

From:	VBORMC::"[email protected]" "Mats Nilsson"  9-APR-1997 09:16:12.21
To:	"[email protected] - UK Software Partner Engineering 830-4121
08-Apr-1997 1506 +0100" <[email protected]>
CC:	
Subj:	RE:  No.23091, Company Nectar, stderr in subproc

Reply to the message of Tuesday April 8, 1997 17:02 +0100
-----------------------------------------------------------------
>Hello Nick

>>I see in your mail that you suggest that we shall open our files with
>>ctx=3Drec.

The problem is if add this keyword to my open statement now afterwards,
when all files are created, I get an error from open.

>This is related to the "stderr" issue - the answer to that is that it
>is meant to work - i.e. you should be able to have parent and child
>both sharing stderr, but at the moment (due to a bug in the C RTL) it
>won't work.    The bug in the C RTL is specifically related to the way
>that a child process inherits file handle information when forked from
>a parent.


>>I have discussed this problem earlier in October with ASAP, but could
>>not get it running. As I said then when I add data to a file after
>>the EOF

>I looked this up and the problem statement is a bit different - about
>two processes sharing a file and having the parent reading the data
>that the child wrote.  From the previous ASAP info I looked up, this
>should be possible (although you may be affected by the C RTL bug I
>suppose).

>Could you send me a complete program that shows what the problem
>you're having is?  Ideally one that I can build on Unix and VMS so I
>can see the difference?

It is very difficult to send a complete program, because it a big system
with many programs depening of each other.

But I think all of these mail is about the same thing how open files are
inherited beetween processes, and if a subprocess can access data in a
file written by the father process and still open in the father, and vice
versa. As I have seen it, the subprocess can read data updated before the
EOF mark of the file, but it can not access data added after the EOF-mark
until the file is closed by the father, because when the subprocess opens
the file, the size of the file is the oldsize, until the father has close=
d
it, even if new records are added at end of file.

Thanks
Mats


+----------------------------------------------+
!                                              !
!    oooooo     ooooo  Nectar Systems AB       !
!    ooooooo    ooooo  Mats Nilsson            !
!      oooooo   ooo    Development Manager     !
!      ooooooo  ooo    [email protected]           !
!      ooo oooo ooo    Box 124                 !
!      ooo  ooooooo    S-281 22 H=E4ssleholm     !
!    ooooo   oooooooo  Tel. +46 (0)451 893 00  !
!    ooooo    ooooooo  Fax. +46 (0)451 817 30  !
!                                              !
! -For excellence in 4GL-                      !
!                                              !
+----------------------- http://www.nectar.se -+

% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by
vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id KAA22473 for
<[email protected]>; Wed, 9 Apr 1997 10:08:20 +0200
% Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by
mail.vbo.dec.com (8.7.3/8.7) with ESMTP id KAA21339 for
<[email protected]>; Wed, 9 Apr 1997 10:15:01 +0200 (MET DST)
% Received: from nectar (nectar.nectar.se [193.14.116.1]) by server21.digital.fr
(8.7.5/8.7) with SMTP id KAA14634 for <[email protected]>; Wed, 9 Apr
1997 10:19:59 +0200 (MET DST)
% Received: (from gmail@localhost) by nectar (8.6.12/8.6.12) id KAA16254 for
[email protected]; Wed, 9 Apr 1997 10:12:07 +0200
% Received: by gmail.nectar.se with Gmail (ginets/4.0.1) id 334b4f4e; Wed, 9 Apr
97 10:12:07 +010
% Date: Wed, 9 Apr 97 10:08:08 +0100
% Message-Id: <[email protected]>
% In-Reply-To: <[email protected]>
% From: Mats Nilsson <[email protected]>
% To: "[email protected] - UK Software Partner Engineering 830-4121
08-Apr-1997 1506 +0100" <[email protected]>
% Subject: RE:  No.23091, Company Nectar, stderr in subproc
% Mime-Version: 1.0
% Content-Type: text/plain; charset=ISO-8859-1
% Content-Transfer-Encoding: quoted-printable

closing this one, see #3446 for info