Conference bulova::decw_jan-89_to_nov-90

	- Delete your REMCHILD.COM!

	- Clean up your DECW$LOGIN.COM!

	- Get that SET DISPLAY/NODE=0/TRANS=LOCAL out of your LOGIN.COM!

The new CHILD, Release 13, available only from PRNSYS::RELEASED_TOOLS:[CHILD],
makes this stuff go away!  New with release 13:

	- Processes created with CHILD/IMAGE=SYS$SYSTEM:LOGINOUT.EXE
	will have DECW$DISPLAY defined automatically to be the same
	display as was active when the CHILD command was issued.

	- CHILD will automatically start the DECTerm controller if none
	is found for your current node, display, and screen.

The REMCHILD command procedure is no longer needed, and is no longer
part of the kit.  Just issue the CHILD command as if you were local, and
it will do whatever needs to be done to create your terminal.

If you followed my example (now deleted) for using CHILD from your
DECW$LOGIN.COM, you can delete all the stuff related to creating "early
DECTerm" and waiting for it to appear.  Just issue the CHILD commands -
CHILD will create an early DECTerm automatically, if it's needed.  (It's
a session manager bug that DECW$TE_1 get's started also. :-)

I hope that this makes people happier.

			- jeff

	WONDERFUL news!! Thanks Jeff!

	This means all I have to do on a remote node is a SET DISPLAY/NODE=AXEL
	and then whatever CHILD command I want to start up the app??

							mike

    I get a DECterm controller alright, but the base priority is set
    to 0 (yes, Zero). This causes great response problems.
    
    I can't see anything wrong in the source code, so it this a bug?
    
    
    Stephen.

I can't say that I can explain that.

I have encountered a problem where if you log out your CHILD sessions
that were created by DECW$LOGIN.COM,  DECWindows will fail to kill the
extra DECTERM controller (_PRNSYS::0.0, in my case) that CHILD created.

This causes a problem when you go to log in again, and CHILD encounters
a duplicate process name.  I'm thinking about a fix, but don't have one yet.

It does, however, come up as priority 4, not 0.  I can't imagine what's
going wrong.  What's your system configuration?  

I see both problems here: the _ATRGON:0.0 process stays around and the decterm
process sitting at prio 0.  I didn't really look at your sources, but I guess
it could caused by the whole thing being started from a batch queue.  Batch
processes on our system run at prio 3 and you would then need (to enable) ALTPRI
to get a process with prio=4.

I take that back - the _PRNSYS::0.0 I creat from DECW$LOGIN.COM is
running with a base priority of 0.  I'll hunt this down and fix it.

Regarding the process-name thing - I'm getting scrod by the session
manager creating a second DECTerm controller instead of using the one
that's already there.  The second one overrides the logical names set up
by the first one, and since the second was was killed, I can't find the
first one to re-use it.  I'm considering just killing the process if
it's already there.

    It's easy to track this down.  Take a look at line 218 in the file
    decw_term_port.c.  You're in the middle of a call to $CREPRC, and you
    specify the ninth argument (the first zero on line 218), which is the
    'baspri' argument, passed by value, as 0.  So, the created process has
    base priority 0.
    
    Fix:  change line 218 of decw_term_port.c to read:
    
    	31, 0, 0, PRC$M_DETACH));
    
    Of course, if you have ALTPRI privilege, you will get a nicely
    real-time terminal controller :-)  Otherwise, you will get a base
    priority equal to your own priority.  Maybe you want to specify the
    base priority as 4 ...
    
    Maybe this bug arose because you really intended to write "(void *) 0,"
    which would have then been a NULL pointer.  But the argument is not
    passed by reference.
    
    					- Ken

Okay, I found the problem.  I specified a base priority of 0, and VMS
obliged.  Apparently this parameter is not REALLY optional.  I changed
it to 4.  (Now that wasn't hard to fix.)  I also added code to delete
stale DECTerm controllers created by previous incarnations of CHILD.

This is an update to release 13, not a new release.

Affected files are CHILD.EXE and decw_term_port.c, to be found (with the
rest of release 13) in PRNSYS::RELEASED_TOOLS:[CHILD].

If updating a system-wide installation, it is adequete to simply copy
CHILD.EXE to replace the one in SYS$SYSTEM:

Let me know if you have any further problems.

So given the *new* and improved version, what's the best way to kick
off remote DECterms?  I just tried via a Remote Batch submission
and got the following:


$ set verify
$ set display/create/node=DOOBIE
$ @tools:remchild MRFLEX
$ if p1 .eqs. "" then inquire p1 "Application?"
$ if p1 .eqs. "" then goto EXIT
$ if p2 .eqs. "" then p2 = 1
$ goto MRFLEX
$ MRFLEX:
$ child/det/nopass/image=sys$system:loginout/tit="MrFlex DCL Window" -
        /ititle="MrFlex"/x=-0/y=400/ix=0/iy=5/decterm/paus=1
%SYSTEM-W-NOSUCHDEV, no such device available
Identification of created process is %X2040026a
Process 0x2040026a terminated with status 0x1bc:
%SYSTEM-F-NOLOGNAM, no logical name match
%SYSTEM-F-IVLOGNAM, invalid logical name
  MILLER       job terminated at 15-FEB-1989 16:04:53.97


Regards,

              == ken miller ==

It looks like REMCHILD failed to completely create a DECTerm
controller.  I'd try removing the call to REMCHILD entirely and see if
things get better.

You SHOULD be able to simply say

	SET DISPLAY/NODE=mumble/CREATE
	CHILD/this/that...

and everything else is automatic.  Also, it doesn't do any HARM to
create extra DECTerm controllers, so everything should still be okay
even if you run REMCHILD.COM.  CHILD will use an existing controller if
it can find one.  (Be sure you get the new one that doesn't create
priority 0 DECTerm controllers.)

Did this used to work?  Does your server allow connections from this
node?

Like I said, I'm new to CHILD so I'd never tried this before. However...

I took remchild.com out of the loop and tried it by hand.  On one node in
my cluster, the:

	SET DISPLAY/NODE=mumble/CREATE
	CHILD/this/that...

worked fine.  However,  on this other node, I got the following:

<mrflex::miller.ewtest> $ child
%SYSTEM-W-NOSUCHDEV, no such device available
Identification of created process is %X2020016c
Process 0x2020016c terminated with status 0x1bc:
%SYSTEM-F-NOLOGNAM, no logical name match
%SYSTEM-F-IVLOGNAM, invalid logical name

I figured it was DECwindows, so I tried running clock:  It runs 
successfully.  Therefore, there's some specific problem with creating
the DECterm Controller process on this node.  I'm running 
DECW$STARTUP on all of the systems, and I can run FileView &
DECW$TERMINAL successfully on MRFLEX (though CHILD
still comes back with:

%SYSTEM-W-NOSUCHDEV, no such device available
%SYSTEM-F-IVLOGNAM, invalid logical name


Any ideas?

Thanks,

               == ken miller ==

re: < Note 111.11 by MCNALY::MILLER "Bush For President...Kate Bush!" >

By any chance does child use /title value as process name ? If so, your title
name is greater than 15 character which normally produces the invalid logical
name message from sys$creprc. I haven't used child in a while so this is
just a guess.

Jatin

No, CHILD uses /PROCESS as the process name.

I'm going to think about this some more.

I inadvertantly installed CHILD locally (i.e. @CHILDINSTALL rather
than @CHILDINSTALL  SYSTEM), which caused one node to see it
and the other one to resort to an August '88 version!

Thanks to Jeff for straightening it out!  Can't ask for more than a *great*
tool and personal support as well ;)

Thanks again Jeff.

Regards,

                == ken miller ==

Okay, now for a second update of release 13 of CHILD.

Today's version creates the DECTerm controller process (if needed) with
the same process name algorithm as the session manager.  Therefore,
there will no longer be any "_node::0.0" process names, only names of
the from "DECW$TE_n", where "n" is the WSA device unit number that is
being used by the emulator.

The best news of all is that the session manager will now notice that the
terminal emulator process already exists, and not bother to create a
second one, but instead, re-use the one created by CHILD.

This is particularly great news for people with smaller memory sizes,
since you'll be running only one emulator instead of two.

This new version also virtually eliminates the problem of "duplicate
process name", since there is no second process created to override the
logical names set up by the first one.

I forgot to mention, the files that changed are only:
	PRNSYS::RELEASED_TOOLS:[CHILD]CHILD.EXE,DECW_TERM_PORT.C

I really like the CHILD program!  However, I am having a little difficulty
trying to use CHILD to start up the VWSLAT program in a detach process from
CHILD.  I get the following error(s):

Process 0x45000162 terminated with status 0x10d3811c:
%LOGIN-F-INVINPUT, invalid SYS$INPUT for interactive login
%SYSTEM-W-NOSUCHDEV, no such device available

My CHILD command is relatively simple:

$       CHILD/IMAGE=SYS$SYSTEM:LOGINOUT.EXE           -
             /PRIORITY=3                              -
             /NOFOCUS                                 -
             /PRIV                                    -
             /INPUT=MVINUP$DUA1:[DW.VWSLAT]VWSLAT.COM -
             /DETACH                                  -
             /PAUSE=5                                 -
             /SHRINK                                  -
             /PAGE=24                                 -
             /PROC=VWSLAT                             -
             /ITITLE="My LAT"                         -
             /TITLE="VWSLAT control terminal"         -
             /DECTERM                                 -
             /LINE                                    -
             /INSERT

And, the VWSLAT.COM program is relatively simple, also:

$ DEFINE/USER SYS$INPUT SYS$OUTPUT:
$ RUN MVINUP$DUA1:[DW.VWSLAT]VWSLAT.EXE
$ LOGOUT

Can you offer me any help/advise?  Thanks!

-- Don

    This may be a DECterm controller problem:
    
       When I create 5 DECterms using child I have no problems but when
    the sixth appears the DECterm controller dies. Any suggestions?
    
    
    
    Stephen.

Regarding .17  (Invalid input device...), add "/NOPASSWORD", and all
will be fine (I think).  It doesn't like to take input from a command
file when it has to prompt for username and password.  /NOPASSWORD
gives you a process that's already logged in as you.

Regarding .18, are you createding detached processes or subprocesses? 
You may have hit your subprocess quota. SHOW PROC/QUOTA and see if your
subprocess quota is too small.

Also, try saying
	CHILD/IMAGE=SYS$SYSTEM:LOGINPUT.EXE/NOPASS
and see how many you can do before your system crashes.  (Just kidding.)

You may also be hitting your systems process limit.  Do a SHOW MEM and
look at your "slot usage".  If the FREE number is  0 or 1, you should
raise PROCSECTCNT in MODPARAMS.DAT and do a new autogen.

I'm new to DECWINDOWS (having  just started using it last week), I use
CHILD from my DECW$LOGIN.COM to start up dedicated DECTERM sessions.  I
have no problem getting the sessions to come up during login, but I cannot
seem to get them to run the application I want in the process.  Here is how
I use CHILD :

$ CHILD/DETACH /NOPASSWORD /PAUSE = 15 -
       /IMAGE = SYS$SYSTEM:LOGINOUT.EXE -
       /PROCESS = "Emacs" -
       /ITITLE ="Emacs" /TITLE = "Emacs" -
       /IY = 2 /X = 4 /Y = 180 -
       /SETUP_FILE=DSU$:[KADKADE.DECW]DECW$TERMINAL_EMACS.DAT "Emacs/Nosub"

The window "Emacs" shows up fine, but without Emacs started up.
What am I doing wrong?

Thanx,
Sudhir

    I'm running all the DECterms detached and there are 90 process entry
    slots free.
    
      I can still only get a max of 5 up.
    
    
    Stephen.

Regarding .20,

The command parameter cannot be used in conjunction with /IMAGE.  See
HELP CHILD PROCESS for details.

There is no GOOD way to pass a command into a detached process.  The
most common alternatives are:

1 - Use subprocesses instead of detached processes.  I start Emacs as a
subprocess with:

    $ CHILD/SHRINK/PAGE=40/Y=0/PROC=emacs -
	/ITITLE=EMACS/TITLE="Emacs editing windoiw" -
	/DECTERM/LINE/INSERT/CUSTOM="*.fontSetSelection: 0" - "emacs"

This is by far the easiest, but subprocesses have problems due to the
nuisance of deductable quotas, and you may have to figure out what
those are and how to raise them.

2 - Use an input command file.

Replace your Emacs command with:
		/INPUT=SYS$LOGIN:EMACS.COM
leave the rest of the qualifiers.  In EMACS.COM, have
	$ DEFINE/USER SYS$INPUT SYS$OUTPUT:
	$ EMACS/NOSUB
	$ LOGO

This works okay, but if your LOGIN.COM or SYLOGIN.COM does any "$ SET
TERM" commands, you should change them to be "$ SET TERM SYS$OUTPUT:"
commands, since "SET TERM" will use SYS$COMMAND by default, which is
derived from SYS$INPUT, which comes from the /INPUT qualifier.  You
can't SET TERM a command file.  I've taken care in my SYLOGIN.COM to
	$ SET TERM/LINE/INSERT SYS$OUTPUT:
because of this.

3 - Hide the command in the process name, and process it in LOGIN.COM.

I've done this in the past, but it's so messy I don't do it any more. 
You issue CHILD with /PROCESS=@EMACS, and at the end of your LOGIN.COM
you check for process names beginning with "@" and issue the remainder
of the process name as a DCL command, as follows:

$ IF F$EXTRACT( 0, 1, F$PROCESS()) .NES. "@" THEN $ GOTO nochild
$	define/user sys$input sys$output:
$	'F$EXTRACT( 1, 20, F$PROCESS())'
$	stop/id=0
$ nochild:
$ exit

Note that LOGINOUT tries to change your process name to your user name,
so you should do a:
	$ set noon
	$ set proc/name="''f$edit( f$getjpi( 0,"USERNAME"), "TRIM")'"
	$ set on
first, to make sure that process name is already in use.

Re: .19

Thanks for the help!  That did the job.  However, I've been getting the 
following warning whenever I use CHILD to start up a detached process:

    %SYSTEM-W-DEVALLOC, device already allocated to another user

What does this mean?  When I do a SHOW PROC/FULL and see the devices allocated
to the detached process, all seems well, but I get the feeling I'm not looking
for the right thing.  It seems that this is happening when trying to create a 
new DECTerm.

Any ideas?

Thanks in advance!

-- Don 

This note includes a reference to a new CHILD image, as well as a
discussion of how to avoid the "assigned to another user" error.

If you do a HELP CHILD TERMINAL, it will explain somewhat crypticly
about how when you create a DETACHED process, the terminal can be owned
by the created job, or the CHILD job, but not both.  CHILD sometimes
needs to assign a channel to the terminal in order to do some things.

The qualifiers that do not require assigning a channel under DECWindows
are listed in this HELP topic.  It also discusses a little bit about
who owns the terminal.

If CHILD needs to assign a channel, and the device is owned by the
created process, and the CHILD process does not have the SHARE priv,
then you will get this error.  One easy way to make the error go away
is to say SET PROC/PRIV=SHARE, if you can.  In most cases, however, you
do not actually need the offending qualifier for detached jobs, since
the "SET TERM" types of qualifiers are usually handled by a combination
of DECTERM and SYLOGIN.COM, and the rest of the offending qualifiers
send control sequences which aren't understood by DECTerm anyway.

In your case (from .17), the offending qualifiers are /NOFOCUS, /PAGE,
/DECTERM, /LINE, and /INSERT.

/NOFOCUS is a no-op on DECTerm, leave it out.  /DECTERM is handled by
DECTerm itself, so is no problem.  /LINE and /INSERT should be handled
by your LOGIN.COM, and are not needed here.  This leaves /PAGE.  See
following paragraph.

Now, coincidently, I was burned today by a minor "bug" that's related
to this, so I fixed it in CHILD.  Notice that /PAGE is not among the
permitted qualifiers!  This was because earlier baselevels of DECTerm
did not set VMS's concept of /WIDTH and /PAGE for you.  With the
released version, this is no longer the case, so CHILD does not need to
assign a channel to do /WIDTH and /PAGE on a DECTerm.

There is a new image in PRNSYS::RELEASED_TOOLS:[CHILD]CHILD.EXE which
lifts the requirement that /PAGE assigns a channel under DECWindows.  If
you don't want the new image, you can accomplish the same thing with
qualiier /CUSTOM=("*.rows:24").

Also, once you get to the point where CHILD works without SHARE and
without the "assigned to another user" error, you can omit /PAUSE and
allow your LOGIN to run faster.  The reason for the pause is two-fold:

   1 - It gives the for the created process to get the first channel on
   the terminal, so that it owns the terminal and can run wihtout SHARE.

   2 - It allows CHILD to see the exit status of the created process, so
   if it doesn't start properly you can find out why.

So long as CHILD isn't assigning a channel and the process runs okay,
the /PAUSE is not needed.

    I am getting the same problem as exposed in .18.
    My processes are typically created by this sort of command:
    
    $ child/image=sys$system:loginout.exe-
      /uaf-
      /nopass-
      /detach-
      /shrink-
      /x=250-
      /y=95-
      /ix=13-
      /iy=1-
      /ititle="Notes"-
      /title="Notes on Get27"-
      /setup=bij:[decw]decw$terminal_mail.dat-
      /process="Notes"
    
    1 -> 5 is fine, the sixth one crashes the DECterm controller, hence all
    the processes 'attached' to it.  Here is my authorize entry:
    
    
    Username: BIJAOUI                          Owner:  PIERRE BIJAOUI
    Account:  KZ3                              UIC:    [106,6] ([KZ3,BIJAOUI])
    CLI:      DCL                              Tables: DCLTABLES
    Default:  USER:[BIJAOUI]
    LGICMD:   LOGIN
    Login Flags:
    Primary days:   Mon Tue Wed Thu Fri
    Secondary days:                     Sat Sun
    No access restrictions
    Expiration:  1-JUN-1989 00:00    Pwdminimum:  8   Login Fails:     0
    Pwdlifetime:         30 00:00    Pwdchange:  18-FEB-1989 20:22
    Last Login: 22-FEB-1989 17:26 (interactive), 22-FEB-1989 17:36
    (non-interactive)
    Maxjobs:         0  Fillm:       200  Bytlm:        80000
    Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0
    Maxdetach:       0  BIOlm:       100  JTquota:       6000
    Prclm:          10  DIOlm:       100  WSdef:          300
    Prio:            4  ASTlm:        24  WSquo:          512
    Queprio:         0  TQElm:        10  WSextent:     32800
    CPU:        (none)  Enqlm:        50  Pgflquo:      80000
    Authorized Privileges:
      SETPRV TMPMBX NETMBX
    Default Privileges:
      TMPMBX NETMBX READALL
    Identifier                         Value           Attributes
      PSI$X25_USER                     %X80010009      NORESOURCE NODYNAMIC
      MRAI                             %X80010014      RESOURCE NODYNAMIC
      QAR$MAINTAINER                   %X80010015      NORESOURCE NODYNAMIC
      ACB                              %X80010019      RESOURCE NODYNAMIC
    
    
    Help ! :-)
    
    
    Pierre.

Hmmm.  The first thing I notice is that you has an ASTlm of 24, I have
an ASTlm of 300.  I also have an Enqlm of 599.

I would suspect ASTlm, since I know that a DECTerm will require at least
2 AST's per emulator, plus at least one more, you would be limited to
about 11 anyway.  If for some reason they happen to use 4 per emulator
(not unreasnable), well, seems it would crash at about 5.  CHLID tries
to give it 300, but your UAF will override the values provided by CHILD.

Try it an let me know what happens.

    That was it ! It works fine now (at least with 6 windows).
    
    FYI, when it dies, there is with no log (just a sys$error.; file
    created,  with 0 blocks in it). 
    
    
    Thanx a lot,
    Pierre. 

What is that SYS$ERROR. file doing?  show/device/files tells me that the 
terminal controller started by CHILD has the file opened.  I've never seen
anything in it.  Is there a way to avoid creating it?

Wook

	I'm running the version of child dated 17-FEB-1989 10:57:19.00
	And when I create the first decterm using child I get the following
	error message...
	
$       CHILD                                          -
            /detach/image=sys$system:loginout/nopass    -
            /pause=3    /insert     /page=48          -
            /ix=3    /iy=0    /x=2     /y=208 -
            /process="Term_48"                            -
            /title="@c.48""          /ititle=""@c.48""    "-
            /setup=sys$login:decw$terminal_default.dat
Deleting stale DECTerm controller
Creating DECTerm controller
%SYSTEM-F-DUPLNAM, duplicate name
$

	This is happening in DECW$LOGIN.COM where I start 4 'Children' the rest of them
	start fine, but i run into this on the first one.
	
	Any ideas what's happpening

		Jan

    Re SYS$ERROR.;*
    
    Can we do something about it? Did you mean to use the file pointed to
    by logical name SYS$ERROR? I found copies SYS$ERROR.; littered around
    my SYS$LOGIN which is getting to be a nuisance.
    
    --svb

I guess I meant can we avoid creating it or at least can we make it useful by
being able to store something real in it and put it someplace out of the way.

Wook (who's up to SYS$ERROR.;12 and counting)

    A quick question on the use of the /newterm switch. Been playing around
    w/ child for only a day or so (super utility!), and wrote the following 
    cmd file to pop open a new window.

    $! Filename: new_window.com
    $! Author:   Dom Carr (HPSCAD::DMCARR)
    $!
    $ u:='f$getjpi("","username")
    $ child/image=sys$system:loginout   -
        /detach                         -
        /newterm=dom$window             -
        /priv                           -
        /nopass                         -
        /pause=2                        -
        /proc="''u'''f$trnlnm("dom$window")'"               -
        /title="  ''f$trnlnm(""dom$window"")' on DIAG09""     "-
        /ititle="''f$trnlnm("dom$window")'"                 -
        /y=100
    $ exit

    I spent much time diddling around with figuring out how to create
    a unique process name as well as getting the name of the newly
    created window for the title & the icon, when I stumbled upon the
    /newterm switch. Works (almost) like a charm.

    If I "set verify" & invoke this, I'll see my logical dom$window show
    up as "_TWA106:". However, when I switch to the new window, and do a 
    "sho term", it shows "_TWA107:".

    When I pop back to the invoking window, and do a "show logical 
    dom$window", it now shows "_TWA107:".  Its consistently off by 1.
    I could really care less whether the window title accurately matches
    the "show term" info, but was wondering whether I was doing something
    stupid or found a "bug". 

						-Dom

What you are doing is using an old translation of the DOM$WINDOW logical when
you call CHILD, and then when CHILD runs, it (re)defines the DOM$WINDOW logical
that newterm points to.  You may notice that the first time you call CHILD with
that particular logical, it evaluates to the null string, since the logical is
undefined, since CHILD hasn't run before.

In other words the sequence of events is as follows:

1) The .COM file containing the sequence is run.
2) DCL gets to the CHILD call
3) The statement is interpreted, and all DCL symbols and lexicals (the "'"s)
   get interpreted at this time.  Notice that here, the current value (if any)
   of the DOM$WINDOW logical specified by the f$logical() lexical gets used.
4) CHILD is started, and interprets its parameters, getting the relevant
   titles, process name, etc. it will use.
5) CHILD creates the new terminal, and creates a new value for the DOM$WINDOW
   logical.  This value is different from the old value used in the title and
   process name. 

-Mike

    Re: -.1

    Yeah, you're right. I hadn't noticed on the first invocation that the
    logical was undefined. This brings up some questions. 

	(1) My attempt at doing this was spurred because my new windows
	had no process names at all (when the /process switch was left out).
	Again, is this cockpit error or am I just missing something here?

	(2) Without jumping thru hoops, is it possible to get the name of
	the created window ("terminal name") set correctly in its title
	as I've attempted? 

    BTW, running VMS 5.1, 5.1 SDC of DECWindows, and using the latest
    (release 13) of child. 
						    -Dom

There is a new PRNSYS::RELEASED_TOOLS:[CHILD]CHILD.EXE that specifies
SYS$ERROR files file to go to "NLA0:", and defaults the process names
for detached processes to the output device name.  The change sources are
DECW_TERM_PORT.C and NEWPROC.C, if you keep track.

1. The creation of SYS$ERROR files was an inadvertant side effect of my
omitting the SYS$ERROR parameter on SYS$CREPRC for the DECTerm
controller.

2. Regarding the process name thing.  Empty process names are bad
style, so this new image uses a DEFAULT process name for processes
created with /IMAGE will be the same as the output device name (usually
the created terminal name).

In your case, where you are using /IMAGE=SYS$SYSTEM:LOGINOUT.EXE/DET/NOEXE,
you could have put a SET PROC/NAME in your LOGIN.COM to fix up the empty
process name, but if you get the new CHILD you won't need to do that.

Of course, it won't let you default the window title or icon title to
include the device name.  That's real hard, since I don't know the device
name until after I have told DECTerm what titles I want.

Anything else I can do for you?

		:-), Jeff

>	(1) My attempt at doing this was spurred because my new windows
>	had no process names at all (when the /process switch was left out).
>	Again, is this cockpit error or am I just missing something here?

That was CHILD's fault, not yours.

>	(2) Without jumping thru hoops, is it possible to get the name of
>	the created window ("terminal name") set correctly in its title
>	as I've attempted? 

You have to jump through hoops.  You have to tell DECTerm the title
before DECTerm will tell you the device name.  

>	I'm running the version of child dated 17-FEB-1989 10:57:19.00
>	And when I create the first decterm using child I get the following
>	error message...
>	
>$       CHILD                                          -
>            /detach/image=sys$system:loginout/nopass    -
>            /pause=3    /insert     /page=48          -
>            /ix=3    /iy=0    /x=2     /y=208 -
>            /process="Term_48"                            -
>            /title="@c.48""          /ititle=""@c.48""    "-
>            /setup=sys$login:decw$terminal_default.dat
>Deleting stale DECTerm controller
>Creating DECTerm controller
>%SYSTEM-F-DUPLNAM, duplicate name

This could be any of a number of things.

1 - Does this version of child create process names of the form
_NODE::0.0, or the more reasonable DECW$TE_1?  If you are getting the
_NODE:: processes, get a new CHILD and things might get better by
themselves.  I lost track of what the dates were when I made that
change.

2 - Does process name "Term_48" already exist?  If so, it's your problem.

3 - I give only 10 seconds after printing "Deleting stale DECTerm
controller" for the process to actually go away, and I don't look back
to check if it actually did.  If you are spawing a lot of processes in
DECW$LOGIN.COM before issuing a CHILD command, the system may be running
too busy to delete the process in time for CHILD to create a new one.
Try issuing your first CHILD command earlier in DECW$LOGIN.COM.

4 - Are you doing anything that might interfere with CHILD's ability to
detect the DECW$TERMINAL_MAILBOX_node::0.0 mailbox logical name?  Funny
SET DISPLAY values or a DEFINE of DECW$DISPLAY to something other than
a WSA device might interfere with CHILD.

Let me know how you make out.

    Re .35, i hope you're married. You'd be a swell parent! Thank you.
    
    --svb

	Can the new version of child shring the corrent window ?
	Paul H.

CHILD/DEVICE=SYS$OUTPUT:/SHRINK will shrink the current window if you
are running VWS, or if you are running a terminal emulator that
implements the VWS OSC sequence for window shrinking.

DECTerm does not support this sequence, so the answer is NO.  This
feature is "on the list" for future versions of DECTerm, at which point
this CHILD command will start working.

We have a problem with the use of CHILD. We try to start VWSLAT with the use
of CHILD from DECW$LOGIN.COM on a VAXstation 2000 with 6Mb memory. CHILD
creates a DECterm1 but VWSLAT is not started. SYLOGIN and LOGIN are not
executed. When closing DECterm1 and quitting the session manager, all windows
are removed from the screen, the arrow remains but no new login window is
displayed. Log in by SET HOST shows that the process DECW$TE_1, owned by me,
is still running. Stopping it does not get me out of the hang situation.
Can anyone tell us if we're doing anything wrong, please.

Directory SYS$COMMON:[SYSEXE]

CHILD.EXE;17             35  24-FEB-1989 12:57:12.00
VWSLAT.EXE;1            103   3-FEB-1989 13:16:37.00

SYS$LOGIN:DECW$LOGIN.COM
------------------------
$ child -
  /shrink 
  /decterm -
  /lineediting -
  /insert -
  /title="DECwindows LAT" -
  /ititle="VWSLAT" -
  /process="VWSLAT" -
  /x=3 -
  /y=756 -
  /nobroadcast -
  /page=5 -
  /width=40 -
  "run SYS$SYSTEM:VWSLAT"

What do you do in DECW$LOGIN.COM BEFORE the CHILD command?

I have found that the first call to CHILD needs to be geven when the
system is not too busy.  Otherwise there is some kind of synchronization
problem between CHILD and the newly created DECTerm controller.

Does DECW$SM.LOG contain any additional information?
Does the problem go away if you do this before spawning any other
processes in DECW$LOGIN.COM?

    Re: 111.41 

    You're missing a hyphen at the the end of the line with the "/SHRINK"
    qualifier. Everything beyond that's just being ignored by dcl.

						    -Dom

Re: .42,.43

Thanks and sorry to have bothered you. The missing hyphen was the reason
why VWSLAT wasn't started. The session has hanged once today too, however,
but I haven't been able to reproduce it. (DECwindows V5.1, DECW$LOGIN.COM
does only have the CHILD command in it and DECW$SM.LOG doesn't show any
errors). Maybe has to do with the system parameter settings. Thanks anyway.

/Jan Hallberg

I am tring to use CHILD to create a VTX window.  My command is:
$        CHILD/IMA=SYS$SYSTEM:LOGINOUT/PAU:10/NOPASS -
         /process="VTX"/ititle="VTX"/title="VTX" -
         /INPUT=FA$UPDATE:VTX.COM

and /INPUT=FA$UPDATE:VTX.COM is:

$ define/user sys$input sys$output
$ vtx
$ logout

When the window comes up, I get the message, probably 
from VTX: "Controllng device not a terminal"

This command and file are basically the same I use to start a LAT session.
I've tried using various /QUALIFIERS to signal a video type terminal, but with
no luck.  Perhaps someone can shed some light on this.

BTW: SDC VMS 5.1 and SDC DecWindows.  Child is a 24-FEB-1989 version.

Alan

I can easily reproduce the problem in .45.  Apparently, VTX uses
SYS$COMMAND instead of (or in addition to) SYS$INPUT.  It worked with
the following VTX.COM:

$ define/user sys$input sys$output:
$ define/user sys$command sys$output:
$ vtx
$ logout

VTX Works fine.  Beware, though, that VTX will change the color scheme on the 
window and possibly the screen. BUT VTX will do this on  a  VT241 as well.

Alan

Throw in a $ SET TERM SYS$OUTPUT:/NOREGIS at the beginning of VTX.COM,
and your colors will sit still.

    I have a VS2000 in a LAVC with some big VAXen. I have been using VWSLAT
    to bring up sessions on the big guys. I decided to try running DECterms
    on them as an alternative. I have three different problems with Child.
    
    My procedure is simple: we have a cluster-wide JBCSYSQUE file, so I
    have access to batch queues all over the cluster from my workstation.
    I have a procedure START_DECTERM.COM which I use interactively on my
    workstation and which I submit to a batch queue on whichever big VAX I
    want a session. 
    
    I would very much appreciate some help with this, especially the last
    problem. I find this approach has significant benefits over using
    VWSLAT (a *fine* product, don't get me wrong), in that the terminal
    windows come up (1) neatly iconized, (2) already logged in, and (3)
    automatically at startup!
    
    My problems, in reverse order of severity:
    
    #1: On my workstation (named KAIRYS) I couldn't get Child to set the
    window and icon titles until I added a /PAUSE (at least I think that's
    what made the difference). I understand this should not be necessary,
    since (1) I'm running with SHARE, and (2) I am using only "safe"
    qualifiers.
    
    #2: On one VAX (named SWSCIM) I cannot get Child to set the titles on
    the *first* DECterm (the one that starts the controller process) no
    matter what I do. Subsequent DECterms are set up fine.
    
    #3: On the other VAX (CIM) the batch process hangs forever in LEF at
    the Child command.
    
    The relevant parts of my START_DECTERM.COM follow. I have only removed
    the stuff with which I set up my title and process name strings.
    
	$!
	$!  START_DECTERM.COM
	$!
	$ set noon
	$ prev_privs = f$setprv ("detach, share, world")
			:
			:
			:
	$ set display /create /transport=decnet /node=kairys
	$ decwdisplay = f$trnlnm ("DECW$DISPLAY")
	$!
	$ child	/decwindows -
		/image=sys$system:loginout.exe -
		/setup_file=decw$user_defaults:decw$terminal_default.dat -
		/detach /nopass /shrink /pause=30 -
		/process = "''pname'" -
		/title   = "''title'" -
		/ititle  = "''icon'"
	$!
	$ set display /noperm 'decwdisplay'
	$ set process /priv=('prev_privs')
	$ exit

Are all of your problems limited to the cases where CHILD is trying to
start the DECTerm controller?  That's clearly the case for the two
larger nodes, but it's not clear from your note if that's true for the
workstation.

Are the larger nodes "busy" machines?  I have a lot of trouble getting
CHILD and the newly created DECTerm controller synchronized right.  One
workstations, this has been "fixed" by issuing the CHILD command earlier
in DECW$LOGIN.COM, before the machine is too busy.  Obviously you can't
do that here.

A resonable work-around is to start the emulator process by hand on each
node, but first,  I'm going to MAIL you the name of a new image to try.

My problem  is  similar  to that in .9, but I'm sure that the resolution for
that  problem  isn't correct for me. I got the latest version of CHILD a few
days ago (CHILD was not previously installed on my system), and installed it
on my workstation.

I wanted  to  start  up  a terminal session on my workstation asynchronously
from  my  decw$login.com,  and to start a remote session on the cluster with
the display set back to my workstation. My DECW$LOGIN.COM looks like:

$ submit/remote tle::c$:[daniels.bin]startgrue
$ spawn/nowait mc decw$banner
$ spawn/nowait mc decw$clock
$ spawn/nowait -
  child/image=sys$system:loginout.exe/nopass/pause/title="DANIELS on GRUE" -
	/setup=dua0:[daniels]decw$terminal_default.dat/x=20/y=0/detach -
	/ititle="GRUE::DANIELS"

If I  don't do the spawn/nowait on the CHILD command, my workstation freezes
when  I  log in. With the SPAWN/NOWAIT, I just never get my window. The same
CHILD  command  works  if  I  enter  it from another terminal logged into my
workstation. The relevant portion of STARTGRUE.COM is:

$ set verify
$ set display/create/node=grue
$ set def C$:[DANIELS.CHILD]
$ @childinstall
$ child/image=sys$system:loginout.exe/nopass/pause/title="DANIELS on TLE" -
        /setup=C$:[daniels]decw$terminal_default.dat/x=30/y=0/detach -
	/title="TLE::DANIELS"

When I submit this file, I get the same error as the person in .9 did:
$ set display/create/node=grue
$ set def C$:[DANIELS.CHILD]
$ @childinstall
$ child/image=sys$system:loginout.exe/nopass/pause/title="DANIELS on TLE" -
        /setup=C$:[daniels]decw$terminal_default.dat/x=30/y=0/detach -
	/title="TLE::DANIELS"
Creating DECTerm controller
Failed to create DECTerm controller
%SYSTEM-W-NOSUCHDEV, no such device available
Identification of created process is %X204002c3
Process 0x204002c3 terminated with status 0x1bc:
%SYSTEM-F-NOLOGNAM, no logical name match


Help!

- Brad

    Well, as long as I'm here... I can't start a detached decterm using the
    /page= qualifier.  When I try to do so, the window pops up for a
    second, and then disappears...
    
    							Michael

Regarding .51 - it looks like you are using a SLOW computer. I've put up
a new CHILD.EXE that adds some extra delays after it thinks the DECTerm
controller is running.  Try this and see if it helps.  Remember to
update BOTH systems.

Regarding .52 - This will happen if the process fails to be created, or
if CHILD get's a channel on the terminal before you do.  This should't
be related to /PAGE, unless you are running and older version of CHILD,
from the time before DECW$TERMINAL would fix the page size for you.  In
the older CHILD, /PAGE needed to get a channel on the terminal to tell
VMS about it's size.  In the current CHILD, it doesn't do that.  Fetch a
new one and see if the problem goes away. PRNSYS::RELEASED_TOOLS:[CHILD].

I have done a similar thing as Brad did in note 111.51 with the NEW version
of child that was suggested by note 111.53. My workstation HORSEY is in a 
cluster with NWACES, an 8530 as well as other workstations.
	My decw$login.com looks like:

$ @[gentile]login.com
$ submit/noprint sys$manager:decw$startvue /queue=vue$batch /name="FISH"
$ submit/remote nwaces::diamond$:[gentile.com]starthorsey
$ spawn/nowait/input=nl:/proc=decw$mail run sys$system:decw$mail
!$ spawn/nowait/input=nl:/proc=decw$bookreader run sys$system:decw$bookreader
!$ spawn/nowait/input=nl:/proc=decw$clock run sys$system:decw$clock
!$ spawn/nowait/input=nl:/proc=notes notes
$ child/image=sys$system:loginout.exe/nopass/pause/title="GENTILE on HORSEY" -
        /setup=diamond$:[gentile]decw$terminal_default.dat/x=30/y=30/detach -
        /ititle="HORSEY::GENTILE"

My starthorsey.com looks like:
$ set verify
$!
$! This MUST go on vue$batch, not sys$batch
$ submit/noprint sys$manager:decw$startvue /queue=vue$batch/name=vue$gentile_nw
$ set display/create/node=horsey
$ set def diamond$:[gentile.decwindows]
$!
$! This is installed in sys$common:[sysexe]
$! @childinstall
$! wait 00:00:05
$ child/image=sys$system:loginout.exe/nopass/pause/title="GENTILE ON NWACES" -
        /setup=diamond$:[gentile]decw$terminal_default.dat/x=40/y=40/detach -
        /ititle="NWACES::GENTILE"

The submit of the batch job to create does not start the job. I get a:
	Client is not authorized to access server.
For the starthorsey.log i get the following right after the CHILD command:
$ child/image=sys$system:loginout.exe/nopass/pause/title="GENTILE ON NWACES" -
        /setup=diamond$:[gentile]decw$terminal_default.dat/x=40/y=40/detach -
        /ititle="NWACES::GENTILE"
Creating DECTerm Controller
Failed to create DECTerm controller
%SYSTEM-W-NOSUCHDEV, no such device available
Process 0x2920014f terminated with status 0x1bc:
%SYSTEM-F-NOLOGNAM, no logical name match

CHILD has been installed permanetly on both systems. 
Any ideas. Why can't I do the batch job to create a FileVue on the mini? I can
do it from the DCL command line!!
	Help, 
			Sam

Re .-1:

The new  version  worked  for  me  (thanks!), but there was an extra problem
which  may  be  what you're experiencing. For some reason the DECterm device
driver  wasn't getting started on some nodes in the cluster. Go on to one of
the  nodes  from which you get the "no such device" error, and do a "sho dev
py".  If  there's  no  PYA0:, you've probably got the same problem. Ask your
system  mangler to restart Decwindows on that node. PYA0: should show up. If
it  doesn't,  or  if  it  does and you still can't get child to work, then I
don't know what's going on.

- Brad

Do you have proxy access oni NWACES?  If not, the batch job may be
running in the default DECNet account (leaving you open to worms?)
instead of running under your own user-id.  This is assuming, of course,
that you have performed the proper authorizations in your session
manager customize menu to allow such connections.

You have to make the "client is not authorized to access server" message
go away.

    I've noticed that if CHILD is run on a client system, the controller
    process stays around, even after the user has logged out of the
    terminal session on the client machine.  Is there a way to prevent
    this from happening?
    
    Dave
    

Re: .57

Not in V1.  The DECterm controller will always exit when the last window
is closed in V2.

				-- Bob

If you log out from the session manager's SESSION PAUSE menu with a
terminal window open on the remote system, the remote terminal emulator
will exit.  If you log out of your remote sessions first, then the
terminal emulator doesn't have any windows open on the display, and
this prevents the emulator from being notified that the user logged
out.

I think it's a session manager bug, but it might be a window manager
problem or simply an X protocol problem (can a client get ANY messages
if it doesn't have a window open?)

    I can't seem to get child "/X=" and "/Y=" qualifiers to act like
    geometry syntax would in Xdefaults.
    For example if I specify "/X=-n" it will position the window
    'n' units from the right side of the screen.
    The same thing for negative Y units. This will not work with the
    child X & Y qualifiers.
    
    This would be a neat fix.
    
    jjjones

Hmm.  Note that saying /X and /Y merely sets the "*.y" resource in the
customization string.  Are you suggesting that I should be using a
different resource name, like "*.geometry" to set /X and /Y?

The best place for this fix is in DECTerm itself.

By default, CHILD creates a VWS window if it thinks VWS is present
(determined by calling UIS$PRESENT).

If you have both installed, like for example, if you are running Fred's
DECWindows inside VWS hack, or XUISSHR, the UIS inside DECWindows hack,
you should specify one of /DECWINDOWS or /VWS on the command line to get
what you want.

In the case of XUISSHR, you MUST say /DECWINDOWS, since XUISSHR can't
handle the UIS$CREATE_TERMINAL calls that CHILD sends it.  The result is
usually an empty window that goes "Username:" when you hit return.

This one nailed me this morning.

Re: .60

>    I can't seem to get child "/X=" and "/Y=" qualifiers to act like
>    geometry syntax would in Xdefaults.

Could you explain this?  Exactly what do you put in decw$xdefults.dat (assuming
that's what you're talking about) that will position something relative to
the right or lower edge of the screen when you give it a negative number?
"DECW$TERMINAL.x: -10" doesn't work.  The only place I've seen something
work this way is with -geometry on Ultrix.

As far as I can tell, there's no way CHILD could implement this given the
current design of DECterm; I'd have to change the interface.

				-- Bob

    When I recently tried /ix=/iy=, it worked okay with HPWM, but the
    effect with vanilla DECWINDOWS was to create a huge icon box and run
    out of virtual memory (this was before I upgraded to 14mb from 6mb).
    
    Be very careful....
    
    ANdy

    What is the official status of CHILD?  I have a customer who has
    seen and used it and is in love with it.  He wants to know if and
    when he can have it.  What should my response be?

    Re: .63
    
    Bob,
    
    What I am referring to is the ability to specify X and Y points
    of reference with the "*geometry:" XDEFAULTS resource.
    For instance with clock:
    
    	Clock*geometry:		100x100-0-0
    
    will place clock in the lower right hand corner.
    
    +0+0 offset from upper right corner
    +0-0 offset from lower right corner
    -0+0 offset from upper left corner
    -0-0 offset from lower left corner
    
    Hope this explains,
    Send mail if more questions,
    jjones

Re: .66

Oh.  DECterm doesn't support the geometry resource, so there isn't much
CHILD can do unless it wants to read the screen's width and height and
figure out the initial placement by hand.

				-- Bob

>
>    What is the official status of CHILD?  I have a customer who has
>    seen and used it and is in love with it.  He wants to know if and
>    when he can have it.  What should my response be?
>
I don't know the answer, but ...

If *you* don't know the answer, can we assume it wasn't you who showed this to 
the customer? Who did? And why?

             <<< BULOVA::DOCD$:[NOTES$LIBRARY]DECWINDOWS.NOTE;4 >>>
         -< DECWindows - Please do a DIR before starting a new topic! >-
================================================================================
Note 725.0                CHILD/Image how does it work?               No replies
ENGLES::WALSH                                         9 lines   3-MAY-1989 23:42
--------------------------------------------------------------------------------
    I am trying to use the child program to create a terminal window
    with a program running in it.  I want the terminal to log out if
    the user exits or ctrl_y's.  I think that /image should be able
    to do this but every time i try to run a program with this switch
    it creates the window and exits.  Is there something special that
    I have to do to my code to make the image remain running ?  Is there
    some other way that I should try?  I have created a com file that
    will do this but I would think that I could do this through Child.
    Thanks for your help dan.
----------------------------------------------------------------------------
/IMAGE only works well with LOGINOUT.EXE, because without a commmand
interpreter and logical name tables, most programs don't work very well.
Programs run with /IMAGE will not have any of your process logical name
tables nor symbols, and also have no CLI support, which means that they
can't parse commands.

If it's okay for the program to be a subprocess, the best way to do this
is to say something like:

	$ CHILD @filename

and for the file to contain something like:

	$ SET CONTROL=(Y,T)
	$ DEFINE/USER SYS$INPUT SYS$OUTPUT:
	$ RUN yourprogram
	$ EXIT

Another way which can be made to work is to say:

	$ CHILD/INPUT=NLA0: "RUN yourprogram"

This is a problem if the program reads from SYS$INPUT, but if you can
convince the program to use only SYS$OUTPUT, you will be okay.

Jeff
	CHILD works with VMS T5.2-429 - will it be broken by the final version?
Andy

The 22-MAR-1989 and earlier versions of CHILD and VWSLAT are known to
NOT work on VMS baselevel V5.2-42B.  There are new versions of both of
these programs on PRNSYS that have been corrected to work on ANY V5.1 or
V5.2 baselevel.  This change affects DECWindows users only, VWS users
are unaffected.

	PRNSYS::RELEASED_TOOLS:[CHILD]CHILD.EXE,DECW_TERM_PORT.C
	PRNSYS::SYS$SYSTEM:VWSLAT.EXE

In discussion with the DECTerm authors, there is a good chance that
changes will be made so that OLD version of CHILD will work just fine
on the final release of VMS V5.2, but I made the CHILD changes anyway -
it's more robust this way, and it doesn't hurt.

[I hid .69 because there was some questions regarding it's
appropriateness to a public forum, because it discussed too much detail
about the plans to include CHILD-like capabilities in a future product.]

This stuff always makes me nervous...  To quote from note 1.0:

>    In the meantime, here is what I view this conference as being all
>    about:
.
.
.
>    What it is NOT:
.
.
.
>    	4.  A forum for unannounced product discussion.  (The moderators
>    	    will deal with sensitive material fairly harshly...i.e. delete)

Of course I know that no one would even think of disclosing information about
an unannounced product to customers, but if someone who read .69 before it
was set hidden *is* thinking about passing that information along to customers
then I'd like to point out that .69 contained several inaccuracies, and I
can't tell you what they were!

Yes, CHILD is a wonderful tool, and we'll "probably" include something similar
to it in a supported product.  I don't want to get any more specific than that.

				-- Bob

re: .68
>If *you* don't know the answer, can we assume it wasn't you who showed this to 
>the customer? Who did? And why?

The customer saw child running on a workstation being used by a resident on 
site.  The workstation belongs to Digital, so the resident has put CHILD on it
for his personal use.

I guess I can assume from the discussions here, that CHILD is not available in
any way, shape, or form for customer use at this time.

    On-site residents shouldn't be using INTERNAL USE ONLY software that
    might be seen by customers regardless of who is actually using or
    owns the hardware in question.
    
    				-John

    ...unless the proper contracts have been put into place, first,
    right?
    
    	-Al
    
    	

    re .74

    The resident in question should immediately remove CHILD and any other
    internal software that may have been culled from the Enet from any
    workstations on the customer site. Plus, the resident's supervisor
    should bring him/her up-to-date on proper use of DEC equipment at
    customer sites.

	Residents are rarely provided with any ground rules.  In fact, it
is not unusual for a newly hired Specialist to be thrown onsite in his
first week with little or no background on Digital.  So perhaps, more needs
to be done to get/help managers to educate their staff.

Kevin
BTW, the VWSLAT software provides some of CHILDS capabilities.  I am not sure
if the version that is in ASSETS supports DECwindows yet.

re Note 111.77 by STAR::BECK:

>                -< This should be viewed as a serious infraction >-
  
        If this is a "serious infraction" then DEC just isn't a place
        worth working for anymore.  I can't believe how petty we've
        become, what with the constant trademark police, et al.  This
        may not be the cause of our low productivity, but I suspect
        that it's related.

        Bob

Well, I didn't mean to imply it should be viewed as a firing offense, but 
neither is it something to be encouraged, and it is something to be corrected.
I don't see how it relates to the "Notes culture", either, except insofar as
NOTES makes it easier to disseminate things inside the company which should
not find their way outside in an uncontrolled fashion.

The "Notes culture" does make it easier for them like me to take pot-shots 
like .77, however; I'll grant you that.

re Note 111.80 by STAR::BECK:

> The "Notes culture" does make it easier for them like me to take pot-shots 
> like .77, however; I'll grant you that.

        That's what I meant -- with our modern worldwide
        communications, it is very easy to know a little about a
        situation that is otherwise very far from our own and beyond
        our knowledge.  (We can all be like upper management. :-)

        And we can tell the world what we think, rather than a few
        folks at the water cooler.

        Bob

Actually it is quite common for Software Specialist to have proprietary
DEC software at customer sites; this is one of the most important services
provided by DEC SWS consultants.  Many of the LAN, system tuning, and
capacity planning tools are not sold or otherwise provided to customers.
Field service also has a number of proprietary tools, with more to come,
that will be used on customer sites.

Obviously there is a need for good judgement, but unless you are managing
the customer support end of the business, I suggest that you not make
blanket statements about what is and is not appropriate at customer sites.

    Re .82:
    
>Obviously there is a need for good judgement, but unless you are managing
>the customer support end of the business, I suggest that you not make
>blanket statements about what is and is not appropriate at customer sites.

    Hear, hear!

I have been using child windows for a couple of weeks and would like to use the
in a prototype internal application (until the "real supported" product comes 
out).  I have noticed that every so often the windows disappear.  Has anyone else 
seen this?  I get no error message and no warning.  Is there something set up
wrong in my system?  

Child seems to be a great application but this is an aggravating problem.

Dan
 

Re: .84

It's unusual for just one window to disappear; when DECterm crashes *all*
your DECterm windows (on that controller) disappear.

What version/baselevel of DECwindows are you running?

				-- Bob

I was creating the windows with a decnet connection so that when the decnet 
connection finally went away all of its subprocesses would go away.  I guess I 
will have to build a com file that will sleep and check periodically if its 
subprocess window exists.  In a future release of Child it would be nice to be
able to allow the user to enter a /wait option what would stop the program 
from exiting until the child window was deleted.  I have gone in the code and
commented out the nowait switch and this works fine.  

Will you all please keep all of this Software Specialist policy and
procedure crap out of my CHILD support topic!

Now, regarding the often asked question "Can CHILD be given to customers?"

The answer is:

	"No, CHILD currently uses undocumented internal interfaces that
	are subject to change, and it is therefore inappropriate to
	provide the CHILD code as an example program on the use of
	DECW$TERM_PORT, SYS$CREPRC, and LIB$SPAWN.  Also, because this
	interface is subject to change, it is inappropraite to provide
	customers with only the executable code.   CHILD is not
	supported by Digital.

	However, most of what CHILD does can be done with some
	combination of these three routines, and a few cals to the CLI$
	library routines, and in some cases, the IO$M_SETMODE QIO. 
	Given the documentation on these routines, a software
	specialist or VMS system programmer should be able to
	write a CHILD-like program to meet any specific to a customer's
	needs.  (CHILD is overly general - providing lots of options.  A
	specigic program, such as "create a new logged-in session", can
	be done in about 40 lines of C code.)

	Either that, or wait for DIGITAL to provide a supported
	solution." 

Okay, now, if I were to sanitize CHILD of it's use of undocumented
internal interfaces, you would loose the following features:

	- In VMS V5.1, CHILD would not be able to be (easily) used from
	DECW$LOGIN.COM.

	- CHILD would be able to be (easily) used to create DECTerm
	windows from a remote client.

	(Later versions of VMS/DECWINDOWS may correct these without a
	need to update CHILD.)

This version CHILD would then be acceptable as an ASSET - but my
feeling is that the most common desire is to be able to use CHILD from
DECW$LOGIN.COM, and the inability to do so with a sanatized version
might open up a substantial support hassle from customers that expect
this capability, and are annoyed when it's not there.

Now, a question for those interested enough to read this far:

Bearing in mind that a supported solution IS in the works - and the
reduced capability of a sanatized version - should I push such a version
through ASSETS for field use, or not?

    
    
    I'm having a problem using CHILD in my DECW$LOGIN.COM file to start
    VWSLAT.  Bellow is my DECW$LOGIN.COM and DECW$SM.LOG can someone
    please tell me what I'm doing wrong.  Also can I does anyone know
    How to get notes to startup as an Icon?
    
    Thanks,
    -Bruce
    
    DECW$LOGIN.COM
-------------------------------------------------------------
$wait 00:00:10    ! so my SM is left most icon
$spawn/nowait/proc=notes notes
$spawn/nowait/proc=mail run sys$system:decw$mail.exe
$child /shrink/decterm/linedit/title="DECWindow LAT"-
       /ititle="LAT"/process="LAT"/x=5/y=730/nobroadast-
       /page=5/width=40 "run dwtools$root:[vwslat]VWSLAT.EXE"
-------------------------------------------------------------
    DECW$SM$LOG
-------------------------------------------------------------
%SET-I-NEWLIMS, new working set:  Limit = 200  Quota = 200  Extent = 8192
%DCL-S-SPAWNED, process NOTES spawned
%DCL-S-SPAWNED, process MAIL spawned
%SYSTEM-W-NOSUCHDEV, no such device available
%SYSTEM-F-IVLOGNAM, invalid logical name
%DCL-W-SKPDAT, image data (records not beginning with "$") ignored
Session Message: Started DECterm controller 
    
  HARRIS       logged out at 15-MAY-1989 11:13:56.03
-------------------------------------------------------------
  

>$child /shrink/decterm/linedit/title="DECWindow LAT"-
>       /ititle="LAT"/process="LAT"/x=5/y=730/nobroadast-
>       /page=5/width=40 "run dwtools$root:[vwslat]VWSLAT.EXE"

This should work, are you SURE you have the latest CHILD?  Some
old versions would issue the given error message when run from
DECW$LOGIN.COM.  New ones create the DECTerm process and wait for the
device to become available.

Release 14 of CHILD includes a /[NO]WAIT qualifier.

This release contains a new CHILD.CLD, which means that you MUST
re-install CHILD on your system with CHILDINSTALL.COM.

Simply copying the .EXE file will result in a:

	"error parsing 'wait'" error!

You heard it here first, don't come asking me where this message comes from! 
You need to use CHILDINSTALL or other means to perform a new SET COMMAND
on the new CHILD.CLD.

The files are in PRNSYS::RELEASED_TOOLS:[CHILD]*.*.

Changed files for this release are CHILD.CLD,CHILD.HLP,CHILD.EXE,NEWPROC.C.

Read CHILD.TXT for details.

	It would depend on the timeframe for this support under VMS/DECwindows.
I would guess that if the support is over 6 months out, then it would be
worth getting it into ASSETS.

Kevin

    I am having a problem using CHILD to create terminal windows.  The
    first call the CHILD seems to ignore the window characteristics on the
    command line.  For example, DECW$LOGIN.COM contains the following:
    
    $ NEWSESSION/SHRINK/X=150/Y=0/PROC="Term1" -
    	/ITITLE=Term1/TITLE="Terminal 1 window" -
    	/SETUP=DECW$TERMINAL_DEFAULT.DAT
    $ NEWSESSION/SHRINK/X=150/Y=350/PROC="Term2" -
    	/ITITLE=Term2/TITLE="Terminal 2 window" -
    	/SETUP=DECW$TERM2_DEFAULT.DAT
    
    NEWSESSION is defined to be:
    	CHILD/IMAGE=SYS$SYSTEM:LOGINOUT.EXE/NOPASSWORD/DETACH
    
    The first window (TERM1) is created, but not in the right location,
    without the correct title, not shrunk and the icon does not have the
    correct name (it has the default DECterm 1).
    
    The second window (TERM2) is created properly.  The setup files differ
    only in the color of the background.
    
    After all this is done, if I logout of TERM1, and issue the NEWSESSION
    command by hand in TERM2, it creates TERM1 properly.  It only appears
    to be the very first call the CHILD that is not behaving as expected.
    
    By the way, the initial call IS setting the process name to TERM1.
    
    How do I tell which version of child I am running?
    
    Hope I'm not doing something stupid and hope someone can help.
    
    -Max (oryx::max)

To solve this problem, place your first call to CHILD earlier in
DECW$LOGIN.COM.

The problem is that on a busy system, DECTerm somehow manages to forget
to interpret the customization string of emulators that are created too
soon after the emulator itself is started.  There's nothing I can do in
CHILD to work around this problem but to "wait longer".

CHILD (the latest one or two versions anyway) will try to pause 5 or 10
seconds after starting the emulator before issuing the create terminal
request, in order to prevent this, but often this wait isn't long enough.

Re: .93

That's really strange; I can't picture how that could be happening unless
the creation message got corrupted somehow (pointer going berserk during
startup, maybe?).  It's on my list of things to look at (a.k.a. QAR system).

				-- Bob

    RE: -.2
    
    I tried putting the call the CHILD as the very first thing in the file. 
    I even put an artificial delay (DCL WAIT) after the call so it didn't
    try to do anything else in the decw$login file.  It didn't help.  It
    still ignores position and title information.
    
    I'll let you know if I stumble on to any more info.
    
    -Max

$ !  Try this:
$ !  This works on my 14mb VS200/GPX 99% of the time, but sometimes
$ !  when the system is VERY busy (like a DOCUMENT job is running
$ !  positional and title info is lost.
$ !  By the way I have removed the SET WORK/QUOTA line from
$ !    SYS$MANAGER:DECW$SYLOGIN.COM
$ ! I'm running VMS V5.2-42N
$ 
$ newsession == -
"child/image=sys$system:loginout.exe/detach/nopassword/shrink/page=32/pause=5"
$
$ wait 00:00:05
$
$ newsession/ititle="Pippa"/title="Pippa ��� �1982"/x=0/y=0
$             
$ newsession/ititle="Simon"/title="Simon ��� �1984"/x=50/y=75
$
$ newsession/ititle="Daniel"/title="Daniel ��� �1986"/x=100/y=150
$
$
$ exeunt_1:                                                            
$ exit                                             
  

    Well, I tried adding the /PAUSE qualifier and a DCL WAIT and the
    results are still very undeterministic.  When I logged in this morning,
    it worked fine (without the above changes).  I made some changes to my
    DECW$TERMINAL_DEFAULT.DAT file (changed the color) and logged out. 
    When I logged back in, it ignored the window position info again.
    
    The suggested changes in -.1 don't seem to make the behavior any more
    reliable for me.
    
    I'm running on a VAXstation II/GPX with 16Mb of memory. VMS version
    V5.1 and CHILD V13 (I think).
    
    -Max
    

/PAUSE doesn't help you too much, because it doesn't pause until AFTER
it tries to create the terminal.

The FIRST call to CHILD from DECW$LOGIN.COM (and only if called from
DECW$LOGIN.COM) generally does three things:

	1 - Start DECW$TERMINAL.EXE in a detached process

	2 - Tell DECW$TERMINAL to create a new terminal

	3 - Create the new process.

(Outside of DECW$LOGIN.COM, usually only steps 2 and 3 are performed.)

The problem here is related to delay between 1 and 2.  If 2 happens too
soon after 1, something goes wrong.  I wish I remember the dates, but it
was a recent version where I changed the delay between 1 and 2 from 0 to
5 seconds.  Five seconds is apparrently not long enough.

I have just put up a new version of CHILD.EXE that will allow you to
define the logical name or symbol "CHILD_INIT_PAUSE" to an arbitrary
number of seconds to wait.  Try"10" and see if the problem goes away.

    RE: -.1
    
    ALRIGHT!!!!!!
    
    We installed the latest version of CHILD today and I tried setting
    Child_init_pause to 10.  Everything works great!
    
    Thanks for all the help.
    
    -max
    

In my DECW$LOGIN.COM, if CHILD commands are entered after SPAWN commands, CHILD
seems to ignore /PAGE, /X,/Y, and other qualifersthat can change the appearance
of the window to the user.  Here is my DECW$LOGIN.COM

$        CHILD/IMA=SYS$SYSTEM:LOGINOUT/PAU:10/NOPASS/x=180/y=725/PAGE=7 -
         /process="LAT"/ititle="LAT"/title="LAT"/INPUT=SYS$UPDATE:VWSLAT.COM
$
$        CHILD/IMA=SYS$SYSTEM:LOGINOUT/PAU:10/NOPASS/Process="VTX" -
         /ititle="VTX"/title="VTX"/INPUT=SYS$UPDATE:VTX.COM/shrink
$
$        CHILD/IMA=SYS$SYSTEM:LOGINOUT/PAU:10/NOPASS/Process="DECALC+" -
         /ititle="DECALC+"/title="DECALC+"/INPUT=SYS$UPDATE:DECALC.COM/shrink
$        SPAWN/NOWAIT/INPUT=NL:/PROCESS=MAIL RUN SYS$SYSTEM:DECW$MAIL
$        SPAWN/NOWAIT/INPUT=NL:/PROCESS=CALENDAR RUN SYS$SYSTEM:DECW$CALENDAR
$        SPAWN/NOWAIT/INPUT=NL:/PROCESS=CLOCK RUN SYS$SYSTEM:DECW$CLOCK
$        SPAWN/NOWAIT/INPUT=NL:/PROCESS=NOTES NOTES/DISPLAY=DECWINDOWS
$ exit

If, for example, my first child command comes after any of the spawn commands,
the page size will be 24, the /X,/Y, and /(i)TITLE qualifiers will be ignored.
I can reproduce this.  The version of Child is dated 24-feb-1989.

Alan

See .98, I think this is the same problem.

    RE -.1
    
    It may be a related problem, but not exactly the same.  Using the
    CHILD_INIT_PAUSE symbol definitely helps.  I tried to spawn my clock
    and mail processes before starting the first DECTERM and even with the
    symbol set, it ignored the window characteristics.
    
    Basically, starting the first DECTERM should be the very first thing in
    your DECW$LOGIN.COM and set the CHILD_INIT_PAUSE symbol to something
    like 5 or 8 (8 seems to work more reliably).
    
    Max

The busier your system, the larger CHILD_INIT_PAUSE will need to be.

By the way, it looks like this problem will be fixed in some future
release of DECTerm (and CHILD), but because it required changes in
DECTerm as well as CHILD, you'll have to wait.

re Note 111.98 by 7130::LOMICKAJ:

> I have just put up a new version of CHILD.EXE that will allow you to
> define the logical name or symbol "CHILD_INIT_PAUSE" to an arbitrary
> number of seconds to wait.  Try"10" and see if the problem goes away.

Can it be either a logical name OR a symbol?

Bob

Well, yes.  I use the VAXC "getenv()" routine to look up the value of
CHILD_INIT_PAUSE, and VAXC implements getenv() searching both the usual
logical name tables, and the DCL symbol table.

I don't know which it searches first, but no matter where you define it,
getenv() is pretty good at looking it up.

Granted, this doesn't do much to clear up the new user's confusion over
which is which, but at least in this case it doesn't matter.  I suppose
you could use a symbol that's local to DECW$LOGIN.COM.

    re: 111.90
    
    Is the logical name RELEASED_TOOLS defined on PRNSYS (6.986)?

The other day while perusing the CHILD directory on PRNSYS::, I noticed a 
CHILD.EXE what I suspect is for VMS v4.  (I don't remember the exact name of
the image file)

I have a Workstation-I w/ 2mg of memory and a RD52.  As you can see, VMS v5
is out of the question.  Currently, I'm using this system as a Reverse LAT 
using VWSLAT and with DQS, a printer server.

I would like to use CHILD for v4 to create a detached process at boot time
to create and start the VWSLAT process, thus having the system come up auto-
matically as a lat at boot time.

Currently, I am having problems getting to PRNSYS:: with 

%DIRECT-E-OPENIN, error opening PRNSYS::RELEASED_TOOLS:[CHILD]*.*;* as input
-RMS-E-FND, ACP file or directory lookup failed
-SYSTEM-F-UNREACHABLE, remote node is not currently reachable

or

%DIRECT-E-OPENIN, error opening PRNSYS::RELEASED_TOOLS:[CHILD]*.*;* as input
-RMS-E-FND, ACP file or directory lookup failed
-SYSTEM-F-INVLOGIN, login information invalid at remote node

Can you help or redirect me.  Thanks in advance.
Alan

My boss has just sent me the following message concerning CHILD....

*********************
Alan, after carefully reviewing the CHILD documentation, I found this
tool/hack to be very difficult for the average workstation user
to learn. I do not see any advantages of this tool that you can't get
out of DECwindows. I also have security issues and problems with
spawning processes all over the LAVc. I am therfore removing this
from our support portfolio. Any questions regarding this tool by
users are to ber directed to the notes files. Anyone who uses this tool
is on there own. We will not perform any updates to this tool.
*********************

The documentation that I provided was the HELP library.  I tried to convince
him of the advantages and of course what CHILD can do with examples and his 
response to me was.....

*********************
Alan, I don't need and editorial on a tool/hack that has limited and
unclear documentation, no formal support and it can not be used by
all persons with ease in the LAVc. As I stated we will not continue
support for this tool nor will we perform updates. If anyone wants to
use it they can at their own risk and they can research their own
problems in the notes file. We have enough of work to do without
introducing tools that do not have support or proper documentation.

If you look in the Product Architecture under the infrastructure chapter
you will not see Child as a recommended tool. Please refer to the Product
Archtitecture for the recommended tools and products.
*********************

Could someone please provide an explaination on what is involved to create
a process, be it an image, command procedure, or at the DCL prompt, in the 
context of a DECTerm window with the same functionality of CHILD?

Also, what is the future of CHILD with my bosses concerns in mind?

Thanks,
Alan

	Have people run CHILD in their own process. And inform your boss
	that DEC lives on "unsupported" software.. How else would we get
	our work done??

	Sounds like all too much management to me..

							mike

Sounds like a typical computer operations manager to me. The un-informed.

;-)

Jeff

... and how many times a day does he say "Hrumph, hrumph..." :^)

/Harley

Regarding .106 and .107, PRNSYS:: was sidelined for a couple of days,
but is back now - with RELEASED_TOOLS: defined like it should be.

Regarding .108 ff

1. Just about everything CHILD does can be done using some combination
of calls to SYS$CREPRC, LIB$SPAWN, DECW$TERM_PORT and/or a 
SYS$QIOW with IO$M_SETMODE.

You can use CHILD yourself by putting a @CHILDINSTALL in your LOGIN.COM.
You can decode CHILDINSTALL.COM to try to speed it up - but mostly you
get stuck at the (slow) SET COMMAND command.

2. Go for autonomy.  The projects I work on are based on the worlds
largest LAVC.  Personally, I don't want to have to ask any Natzi party
system manager for anything, so I keep a "LAVC Just Say No" poster in
my office, and run stand-alone off an RD54.

3. Can you ECO the infrastructure chapter of the "Product Architecture
Document", whateverthehell that is?  This would piss him off royal, and
make him support CHILD.

4. Can you think of a good reason why their failure to accept CHILD
will force you to slip your project schedule?  This tends to make
people listen.

5. I think CHILD is fairly well documented thank you, and I'm insulted
that it's been called a "hack".  So it has lots of options!  A beginner
usually only needs to say "$ CHILD" and it does the right thing.  Anybody
that understands the VMS RUN command and the SET TERM command ought to
be able to pick up CHILD in no time.  You manager obviously didn't
understand it, but wouldn't understand anything that had lots of
options.  I bet he doesn't own a VCR.  (Sorry to get personal, but he
called my code a "hack"!)

6. The DECTerm group has recognized that the capabilities of CHILD do
NOT otherwise exist in DECWindows, and intend to include CHILD-like
capabilities in a future release.

7. Have you considered interviewing for a new manager?

    Jeff, 
    
    
    I think everybody that has used CHILD recognize that this tool is
    great. 
    
    I must say, that my group, and the LAVc I'm taking care of, has
    field-tested the hidden area solution in Europe, in Valbonne more
    precisely.
    Without CHILD, being in a hidden area would be a _*REAL*_ pain of the
    neck. With it, it just makes the whole stuff working like a charm, and
    very transparent to the user.
    
    A bit of customization, and everything  starts up automagically; a
    decent environment of work is set up in less than 3 minutes.
    
    Now, today, I honestly think that if CHILD wasn't existing, it should
    be invented.
    
    
    Best Regards,
    Pierre.

re .113

>5. I think CHILD is fairly well documented thank you, and I'm insulted
>that it's been called a "hack".  So it has lots of options!  A beginner
>usually only needs to say "$ CHILD" and it does the right thing.  Anybody
>that understands the VMS RUN command and the SET TERM command ought to
>be able to pick up CHILD in no time.  You manager obviously didn't
>understand it, but wouldn't understand anything that had lots of
>options.  I bet he doesn't own a VCR.  (Sorry to get personal, but he
>called my code a "hack"!)

Here's an excerpt from JARGON.TXT. I agree that the term "hack" is somewhat
un-complementary, but I agree with defs 1-5 of hackers :^)

HACK n. 1. Originally a quick job that produces what is needed, but
   not well.  2. The result of that job.  3. NEAT HACK: A clever
   technique.  Also, a brilliant practical joke, where neatness is
   correlated with cleverness, harmlessness, and surprise value.
   Example: the Caltech Rose Bowl card display switch circa 1961.
   4. REAL HACK: A crock (occasionally affectionate).
   v. 5. With "together", to throw something together so it will work.
   6. To bear emotionally or physically.  "I can't hack this heat!" 7.
   To work on something (typically a program).  In specific sense:
   "What are you doing?"  "I'm hacking TECO."  In general sense: "What
   do you do around here?"  "I hack TECO."  (The former is
   time-immediate, the latter time-extended.)  More generally, "I hack
   x" is roughly equivalent to "x is my bag".  "I hack solid-state
   physics."  8. To pull a prank on.  See definition 3 and HACKER (def
   #6).  9. v.i. To waste time (as opposed to TOOL).  "Watcha up to?"
   "Oh, just hacking."  10. HACK UP (ON): To hack, but generally
   implies that the result is meanings 1-2.  11. HACK VALUE: Term used
   as the reason or motivation for expending effort toward a seemingly
   useless goal, the point being that the accomplished goal is a hack.
   For example, MacLISP has code to read and print roman numerals,
   which was installed purely for hack value.
   HAPPY HACKING: A farewell.  HOW'S HACKING?: A friendly greeting
   among hackers.  HACK HACK: A somewhat pointless but friendly
   comment, often used as a temporary farewell.

HACKER [originally, someone who makes furniture with an axe] n. 1. A
   person who enjoys learning the details of programming systems and
   how to stretch their capabilities, as opposed to most users who
   prefer to learn only the minimum necessary.  2. One who programs
   enthusiastically, or who enjoys programming rather than just
   theorizing about programming.  3. A person capable of appreciating
   hack value (q.v.).  4. A person who is good at programming quickly.
   Not everything a hacker produces is a hack.  5. An expert at a
   particular program, or one who frequently does work using it or on
   it; example: "A SAIL hacker".  (Definitions 1 to 5 are correlated,
   and people who fit them congregate.)  6. A malicious or inquisitive
   meddler who tries to discover information by poking around.  Hence
   "password hacker", "network hacker".

HACKISH adj. Being or involving a hack.  HACKISHNESS n.

The hack I put in to implement CHILD_INIT_PAUSE was coded incorrectly.

When it worked at all, it worked by fluke.  The pause was in the wrong
place.  If you were once or are still experiencing symptoms of missing
window titles and other options on your first DECTerm, you need a new
version of CHILD.

This new version defaults CHILD_INIT_PAUSE to 10 seconds.  Note, the
pause only applies to the first DECterm created by DECW$LOGIN.COM.

    Re .115: Sign seen in the MIT AI Lab circa 1984:
    
    "Hacking mail? New mailroom hours are 9-11 and 3-4."

	The latest version of child is not linked for 5.1 and decw sdc vers.
	Can I get that one?

    I just updated to V14 from about V10 or so.  After reading the new
    help and .TXT files, I cleaned up my startup files to eliminate
    the old precautionary wait loop stuff (apparently taken care of in V13).
    
    Now, my DECW$LOGIN.COM file contains four CHILD invocations (which
    used to work, and which I lifted verbatim by 'including' the original
    file and deleting the garbage from my old special startup file), and 
    a spawn of the Calendar. On starting, the system seems to be going 
    OK - it starts the SM; beeps (the problem?); starts the Calendar;
    starts FileView; and that's that.  The DECterms should have appeared 
    in place of the single beep in the sequence. 
    
    Any quick ideas?
    
    Thanks...Gary

    Any ideas

    If you have any log files anywhere, you will probably see an error
    concerning a VAXC RTL ident mismatch.  The newest versions of both
    VWSLAT and CHILD were apparently linked on a 5.2 system, and will
    not run on a 5.1 system.  I had to restore older versions to our
    5.1 systems, but the new versions work just fine on our 5.2 systems.

               Dave

    Thanks Dave.
    
    Jeff - any chance of providing the current set of CHILD product
    for use on a 5.1-1 system?
    
    Gary

I'm sorry  -  I upgraded PRNSYS to VMS V5.2 and didn't realise that
this would create a problem for V5.1 users.  I was out for a few days
and didn't see these notes until now.  The latest CHILD and VWSLAT are
now available in their usual places, linked on a VMS V5.1 system.

    Jeff -
    
    This is wierd!  I installed the V5.1 version, and the following
    happens:
    
    DECW$LOGIN.COM has events in this order -
    	Create DECterm "H"
    	Create DECterm "R"
    	Create DECterm "X"
    	Create DECterm "N"
    	Start Calendar
    
    What happens is -
    	DECterm "H" starts and hangs with watch cursor     
    	I wait for something else to happen
    	I give up and do a SHO SYS in DECterm "H"
    	Screen background changes from login to normal grey
    	DECterm "R" starts and hangs with watch cursor
    	I wait for something else to happen
    	I give up and do a SHO SYS in DECterm "R"
    	DECterm "X" starts and hangs with watch cursor
    	I wait for something else to happen
    	I give up and do a SHO SYS in DECterm "X"
    	DECterm "N" starts and hangs with watch cursor
    	I wait for something else to happen
    	I give up and do a SHO SYS in DECterm "N"
    	Session Manager starts
    	FileView starts
    	Calendar Starts
	Watch cursor changes to arrow
    
    The calls to Child, and the order of the calls is the same as when
    I started using Child at release 10 or so.
    
    Help...Gary

Remove the "/DECTERM".  CHILD is waiting for DCL's outstanding read to complete,
so that it can complete it's SET TERM operation that set's DECTERM-like 
characteristics.  (That's what /DECTERM means.)  VMS has a restriction that
prevents you from changing the terminal characteristics of a terminal while 
there is a read pending.

The /DECTERM is not needed for detached processes that run LOGINOUT, since VMS
will override them anyway.  Perhaps you meant "/DECWINDOWS"?

Also, you can remove the /PAUSE, it's not needed once you get rid of the
/DECTERM.  The pause is to allow time for the process to be created before
CHILD tries to assign a channel in order to change the characteristics.  If
you don't try to change the characteristics, you don't need the pause.

If you have trouble getting any files from PRNSYS::RELEASED_TOOLS:,
check you network database.  As of today, PRNSYS has moved to 5.199.

    I have a disappearing window problem using the following command.

	$ Child/Decterm/Detach/x=350/y=140/page=46-
		/setup=DecW$Terminal_Default.Dat-
		/Image=Sys$System:Loginout-
		/NoPassword-
		/Pause-
		/Title="Long Window for LSE and NOTES" -
		/Ititle="Long Window"

    If I use ACCOUNTING to look at the process created it says that it
    exited with "Error in device name or inappropriate device type."  If I
    remove /NOPASSWORD it works but I have to login of caourse and that
    isn't what I had in mind.

    I updated CHILD system wide yesterday because I wasn't sure what version
    was installed and I am running DECwindows on VMS V5.1.

    Any suggestions?

Don't say "/Decterm".

A lot of mysterious "SYSTEM-F-IVLOGNAM" errors from CHILD come from
having XUISSHR installed.  If you have XUISSHR installed, you MUST use
"CHILD/DECWINDOWS" to get CHILD to do the right thing.

To find out if this is your problem, do a SHOW LOG UISSHR, and if it's
pointing at something unusual, try using /DECWINDOWS.  (It can't hurt
you anyway.)

    
    Could anybody tell me how to create a DECterm with input focus already
    enabled, using de CHILD utility?
    
    				Thanks in advance, Xavi

As as been discussed somewhere at a "fairly high temprature", DECTerm
enforces a policy of not allowing applications to assign input focus to
terminals, either at creation time, or via control sequences (such as
CSI & x, which does this on a VT330).  Is there anything in V2 to
alleviate this problem?  Bob?

I got around to incrementing the release number.  CHILD release 15 is
now available in PRNSYS::RELEASED_TOOLS:[CHILD]*.*, and has been
submitted to the software tools clearinghouse.  This release contains
two new features over the previous releases on PRNSYS:

	1 - The algorithm to choose between VWS and DECWindows was changed
	slightly, so that it will NOT default to VWS if the sysgen parameter
	WINDOW_SYSTEM is not set to 2.  This eliminates the problem where
	users of XUISSHR were seeing lots of "invalid device name" errors
	from CHILD if they forgot to say /DECWINDOWS.

	(CHILD used to use VWS by default if it called UIS$PRESENT and
	got a TRUE value in return.)

	2 - CHILD will now work more like SPAWN, in that if you specify
	a command on the command line, and do NOT specify /INPUT, the
	created subprocess will exit after that one command is executed,
	and not continue reading from SYS$INPUT.  If a command is not
	specified, it will read from SYS$INPUT as usual.

	- The /INPUT qualifier has changed so that it no longer require a
	parameter.  /INPUT will arrange for the created process to
	continue reading from the created terminal after the completion of
	any command given on the CHILD command line.  /INPUT may be
	specified to get back the old behavior.

Note that #2 is an INCOMPATIBILITY with the previous releases.  Use
CHILD/INPUT to get the old behavior, which was actually a bug.

Note that the last toolshed release was quite some time ago.  New to the
toolshed is the CHILD_INIT_PAUSE hack, and the /WAIT qualifier.

This release contains an updated HELP file as well.

             <<< BULOVA::DOCD$:[NOTES$LIBRARY]DECWINDOWS.NOTE;4 >>>
         -< DECWindows - Please do a DIR before starting a new topic! >-
================================================================================
Note 1069.0                                                            2 replies
VNOTSC::GERHARD "George 'Papa Doc' Bush"              9 lines   6-JUL-1989 04:22
--------------------------------------------------------------------------------
Hi,

    does anybody happen to know where I can CHILD copy from since PRNSYS::
    seems not to exist anymore (at least it has been unreachable for a long
    time)?

    Many thanks in advance.

    /ga
================================================================================
Note 1069.1                                                               1 of 2
QUARK::LIONEL "Free advice is worth every cent"       5 lines   6-JUL-1989 07:32
--------------------------------------------------------------------------------
    PRNSYS changed its network node address some time ago.  I'd bet that
    your system's node database is seriously out of date.  Ask your
    system manager to keep it current.
    
    				Steve
================================================================================
Note 1069.2                                                               2 of 2
5319::LOMICKAJ "Jeff Lomicka"                          1 line   6-JUL-1989 09:43
                           -< It's in the MILL now >-
--------------------------------------------------------------------------------
See note 111.125 which announced the PRNSYS address change to this conference. 

             <<< BULOVA::DOCD$:[NOTES$LIBRARY]DECWINDOWS.NOTE;4 >>>
         -< DECWindows - Please do a DIR before starting a new topic! >-
================================================================================
Note 1073.0                      Where's CHILD?                          1 reply
VNOTSC::GERHARD "George 'Papa Doc' Bush"              8 lines   7-JUL-1989 07:45
--------------------------------------------------------------------------------
Hi all,

	does anybody happen to know where I can copy the CHILD utility from
	since PRNSYS:: seems to be gone (it's unreachable for a long time)?

	Many thanks in advance.

	/ga
================================================================================
Note 1073.1                      Where's CHILD?                           1 of 1
WSINT::MCLEMAN "There can only be but one..."         3 lines   7-JUL-1989 08:56
--------------------------------------------------------------------------------
Gee, this has been stated at least a half dozen times in the past two weeks.

PRNSYS has changed addresses. Get your net database updated.

Re: .131

>As as been discussed somewhere at a "fairly high temprature", DECTerm
>enforces a policy of not allowing applications to assign input focus to
>terminals, either at creation time, or via control sequences (such as
>CSI & x, which does this on a VT330).  Is there anything in V2 to
>alleviate this problem?  Bob?

No, the last I've heard the DECwindows (de facto?) policy is that applications
don't grab the input focus when they start up.  In principle I could have
implemented CSI & x, but... I didn't.

				-- Bob

I would like to run certain programs on various remote nodes.
Currently I do this by spawning them as subprocesses within
a child-created decterm job.  I would like to do this directly---
that is without creating any decterms at all---but I can't seem
to convice either run/detach or child to do it for me.  I have
read all of the help file and, silly me, I can't figgure it out!
Can any one suggest what I need to do since I assume child can
do this?

P.S.: I DID do a dir of the replies to this note, but I didnt
see anything that seemed to apply.

Use the same CHILD command as you use now, but specify "/DEVICE=" and
"/INPUT=" in addition to everything else.  "/DEVICE=NL:/INPUT=NL:" comes
to mind as a possibility.  (Of course, if you already have /INPUT on a
file, then leave it that way.)

Perhaps if you sent me a working example that includes the terminal
emulator, I could find a way to make it work without.

Well, in the help file you have as an example:

  CHILD/IMAGE=SYS$SYSTEM:PHONE.EXE/DETACH

That works fine.  On the other hand, if I want to have a regular window, vis:

  CHILD/IMAGE=SYS$SYSTEM:DECW$CALC.EXE/DETACH

it doesn't work.  I tried

  CHILD/IMAGE=SYS$SYSTEM:DECW$CALC.EXE/DETACH/DEVICE=NL:

and

  CHILD/IMAGE=SYS$SYSTEM:DECW$CALC.EXE/DETACH/DEVICE=decw$display

to no avail.  It may be that what I am trying to do doesn't make
sense.  Still it seems like it should work...

Duhhhh.. On the other hand this DOES work:

  CHILD/IMAGE=SYS$SYSTEM:DECW$CALC.EXE/DETACH/DEVICE='f$trnlnm("decw$display")'

Should child be translating this for me?

My first guess is that the programs you are starting require the
SUPERVISOR mode  services of a command language interpreter (I.E.,
DCL).  RTL routines such as  the CLI$ routines, and LIB$SET_LOGICAL,
among others, require that a CLI be  present.  Such programs cannot be
run with /IMAGE= or with RUN/DET, but instead, you have to run
LOGINOUT.EXE and convice LOGINOUT to start your program for you.

I should mention this in the help file.  For this reason, the only
truely useful image to execute is /IMAGE=LOGINOUT.EXE.  You can never
tell, by looking at it, wether or not a particular program is going to
call any of the offending RTL routines.

By far the easiest way to accomplish this is with the SPAWN command. 
The SPAWN command, and the equivalent CHILD capability for starting
subprocesses, will start LOGINOUT in a subprocess, and feed it a command
line to execute.  The seqence:

	$ define decw$display ....
	$ spawn run xbiff

would work from most anywhere.  One way to get such a sequence started
is to run with /IMAGE=LOGINOUT.EXE and /INPUT be a  command file that
spawns each of the interesting applications, and ends by just  running
something itself - something that doesn't exit.  This would be fine for
the calculator, XBIFF, calender,  Tetris, and stuff like that, but VAX
Emacs tends to want a lot of resources, and  is unhappy if too many
subprocess have to share deductable quotas.  GNU is  likely the same
(if not more so) so you most likely want to start Emacs as a  separate
detached job.

If you really want to start an image as adetached processes, the best
way I know of to  hide a command line is in the process name, and
convince your LOGIN.COM to use the process name as a guide.  For
example, here is how I start VAX Emacs from DECW$LOGIN.COM:

$!
$!	Force the default process name to be in use, so that CHILD/PROC
$!	will work for detached jobs.
$!
$ set noon
$ set proc/name="''f$edit( f$getjpi( 0,"USERNAME"), "TRIM")'"
$ set on
$!
$!	Start a few processes and subprocesses
$!
$ spawn/nowait/input=nl:/proc=decw$mail @dua0:[lomickaj]dwmail.com
$ child_init_pause := 10
$ CHILD/shrink/PAGE=40/x=122/y=0 -
	/image=sys$system:loginout.exe/nopass/detach -
	/PROC="@EMACS"/ititle=EMACS/TITLE="Emacs editing window" -
	/custom="*.fontSetSelection: 0"


Note the use of process name "@EMACS".  At the end of my LOGIN.COM, I
have the following: 

$ IF F$EXTRACT( 0, 1, F$PROCESS()) .NES. "@" THEN $ GOTO nochild
$	define/user sys$input sys$output:
$	'F$EXTRACT( 1, 20, F$PROCESS())'
$ nochild:
$ exit

This causes the process name "@EMACS" to execute the command "EMACS". 
Note there is a short limit on the length of a process name.  You can,
of course, put a SGE :== "GNU/THIS/THAT/ANOTHERTHING FFO BAR" in your
LOGIN.COM, and start with process name "@SGE".

Now, regarding the difference between doing a

	$ CHILD/DEVICE='f$trnlnm("DECW$DISPLAY"')/IMAGE=x/DETACH

and

	$ RUN/OUTPUT='f$trnlnm("DECW$DISPLAY"')/DETACH x

These are ALMOST the same - the difference being that CHILD will set the
INTERACTIVE bit for the process, but RUN, in this case, will not.  This
difference can be significant if "x" is LOGINOUT.EXE.

And no, CHILD does not translate the /DEVICE before sending it to
SYS$CREPRC.  You have to do that yourself.

The following example shows how to answer VINO::WITHROW's question, and
note that THIS DOESN'T REQUIRE CHILD!

$!	VINO.COM
$! the closest analogy to XGNU I have is decwriter
$! I start this with:
$!	run/detach/authorize/input=VINO.COM/output=nl: -
$!		/error='f$trnlnm( "DECW$DISPLAY")' sys$system:loginout.exe
$ run/detach/authorize/input=NL:/output=NL:/error='f$trnlnm( "DECW$DISPLAY") -
	/proc="@MCR DECWRITE" sys$system:loginout.exe
$ spawn/nowait run [.decw]xcalc
$ spawn/nowait run [.decw]dwtetris
$ run [.decw]xbiff
$ exit

Note my LOGIN.COM has "R :== $" and the aforementioned "@" process name hack.

The RUN commands here COULD have been CHILD commands.  You could start
this command file with:

$ CHILD/DETACH/NOPASS/INPUT=VINO.COM/IMAGE=SYS$SYSTEM:LOGINOUT.EXE/DEVICE=NL:

but since RUN is supported, use that instead.

Some of the tricks and reasons why this works is that: 

	- If CHILD is told to start LOGINOUT, it places the translation of
	  DECW$DISPLAY in the ERROR parameter to SYS$CREPRC.  This
	  causes LOGINOUT to define DECW$DISPLAY for you.   With RUN you
	  do this yourself with /ERROR=.

	- CHILD allows you to say /NOPASSWORD.
	  The equivalent in RUN is /AUTHORIZE.

	- CHILD always sets the INTERACTIVE bit.  RUN doesn't.  For
	  these programs, I don't think this matters.

I now use the following and it works!

$ run/deta/auth/inpu=nl:/outp=nl:/erro='f$logical("DECW$DISPLAY")'-
  /proc="@xemacs" sys$system:loginout.exe

I can also use child to do this, but it seems as though the /shrink type
options don't apply to the window so created, right?

    I would like to do the following:
    
    log into decwindows and have it :
    
    1. create a terminal window ,set host to another node and log in
    2. repeat 1. for 3 additional nodes.
    
    I have used child to get the terminal windows BUT haw can i set
    host from them automaticle.
    
    
    I know you can't put passwords and usernames in txt files but what
    i did was create a small C program called set.exe that contains
    the names and passwords. I want to run this program which creates
    set1.com,set2.com and set3.com which look like
    
    $set host node
    username
    password
    
    then after all setions are connected delete set*.com.
    
    my decw$login.com looks like this

    $! DEC$wlogin.com.COM 
$!
$! create terminal window without autologin
$!
$ set def user4$:[john.decw.child]
$ @childinstall  ! instal child for me only right now
$ set def sys$login
$ child/image=sys$system:loginout.exe/detach/nopassword/proc="system2"-
    /title="system1"/ititle="system1"/shrink 
$ child/image=sys$system:loginout.exe/detach/nopassword/proc="system2"-
    /title="system2"/ititle="system2"/shrink 
$ child/image=sys$system:loginout.exe/detach/nopassword/proc="system3"-
    /title="system3"/ititle="system3"/shrink 
$!
$!    
$ spawn/nowait/proc="clock" mcr decw$clock/shrink ! shrink is a test
$ spawn/nowait/proc="calendar" mcr decw$calendar

    
    does any of this make sence???  I am not a GOOD programer but do
    now a little C.  Is there any way I can do this??
    

    is the a way log into decwindowns and have all your sessions and
    applications started and then the session paused.
    
    I.E come into work log in and go get coffie!!!!
    
    
    without leaving terminal open.
    
    

Having passwords in a C program is not much different than having them
in a text file!  Have you considered proxies?  They were invented to handle
your problem!  Suggest you do a dir/tit=full feature to find a note
I posted that will help you using proxy access.  You can easily cause
terminals to be started automatically on other systems that way...

>I can also use child to do this, but it seems as though the /shrink type
>options don't apply to the window so created, right?

It is as your surmise - all the window and terminal related qualifiers
apply to the created DECTerm, not to any subsequent applications run
there.  If XEMACS has a "start iconized" qualifier, you will have to
give that as part of the process name/command line.

Does child work under decwindows v2 eft currently availiable?
Paul H.

CHILD SHOULD work under V2, but if it doesn't work, you replace the call
to "decw_term_port" with a call to DEC$TERM_PORT, recompile, and it
should work better than ever before.  I'm not running the V2 stuff yet,
so I haven't been able to do this myself.

A previous note in another topic gives the workarounds for VAXC V3.0.

    Works a treat.
    
    	Also, VWSLAT works.
    
    		Interesting note, the only thing I have any problem
    with todate, was NOTES V2.   (Get it a note on notes?...  Oh
    Nevermind), and that was just some sort of widget warning.  If anyone
    is interested I can try and capture the text to this tomorrow, 
    it still came up and worked though.
    
    		Lou "*sigh* Yes I do windows" Northern

The widget warning problem with NOTES is discussed in the - surprise - 
CLT::VAXNOTES_BUGS conference.  Oddly, I haven't seen the problem at all.

			Steve

    We have the latest version child (well, it was the latest a couple of
    weeks ago) installed on a V5.1 cluster.
    
    When I (or anyone else) tries to execute child we get:
    
    $ CHILD
    Creating DECTerm controller
    Failed to create DECTerm controller
    %SYSTEM-W-NOSUCHDEV, no such device available
    %SYSTEM-F-IVLOGNAM, invalid logical name
    
    
    ie. Child times out whilest waiting for the DECTerm controller to
    appear.
    
    The funny thing is that when I have the SAME child.exe in my directory
    and point a copy of child.cld to the .exe in my directory it all works
    fine.
    
    I'm baffled (and everyone things that I'm some sort of DECwindows guru
    so they all come to me with their problems).
    
    
    The other unusual thing is that this cluster only recently went to V5.1
    from V4.7 and did so by booting from a backup of our other cluster, which
    has no problems with child, so it doesn't seem to be a VMS problem.
    
    
    
    Jeff, someone, anyone please help!!
    
    
    
    Stephen.

Re: .151

Sounds pretty strange.  One possibility is that DECW$DISPLAY isn't defined
properly, or that it's pointing to a display that isn't in the security
database.  Another possibility is that you need to increase some SYSGEN
parameters afte upgrading to VMS V5.1.  Neither one of these things would
account for why CHILD works differently when you run the *same* .exe in
your own directory.

				-- Bob

running child on decwindows V1 (5.2-1 of vms), I want to be able to specify
a big font (like the big one that decwindows uses), but am unable to figure
out how to specify a font name that works (they seem to be ignored).  what
do I need to do?

I start VAX Emacs with a big font using the following command.  The font
selection is in "/custom".

$ CHILD/shrink/PAGE=40/x=122/y=0 -
	/image=sys$system:loginout.exe/nopass/detach -
	/PROC="@EMACS"/ititle=EMACS/TITLE="Emacs editing window" -
	/custom="*.fontSetSelection: 0"

Yesterday, I was running VMS V5.2 and the associated DECwindows on my 
VS2000/GPX.  Today, I installed CHILD, and began to try using it to 
set up an environment.  I was issuing lots of CHILD/X=?/Y=? commands to get
a feel for position.  After each window was created, I logged it out.  I got
up to creating DECterm 13, and the parent process crashed.  At one point I 
decided to quit the session.  This caused my system to hang (did not try to 
gain entry via DECnet) with a blank screen.  

I halted it and rebooted, and started getting lots of "2DB821C" messages in
the OPCOM window.  Round about the third call to CHILD, the system started to
have wierd problems.  

I halted and rebooted again.  Now, I log in a session, and get it started, but
the digital logo and start session dialog box stay on the screen.  If I start a
second session, the logo and box go away, and I get all the icons for both
sessions in one icon box.

I'm really at a loss as to what I did wrong.  ANY guesses are appreciated.

							-JP

and, by the way, the reason why I ask this here is that system CHILD 
installation is the only thing I can think of that changed.  I reworked my 
DECW$LOGIN.COM, but things are messed up even when I start a SYSTEM session.

						     
							- JP

Well, I rebooted a few more times, created sessions, quit them , and now things
are back to normal.  I guess that is the software equivalent of banging it on
the cabinet a few times.  I still would like to know what's up?

			-JP

    Has something happened to this conference as i could have sworn
    i entered a reply to this note concerning command line recall (and
    got a reply as well)!!! I notice that there is a gap in the new
    note creation from 22-aug to 28-aug???
    
    Anyway my question (that i thought i had asked) was about the lack
    of command line recall in CHILD windows (does that click with anybody)?
    and now i have another one: 
    
    in my decw$login.com i have four child commands
    
    	child/decterm/ititle=c1/title="child_1"
    	child/decterm/ititle=c2/title="child_2"
    	child/decterm/ititle=c3/title="child_3"
    	child/decterm
                                              
    
    what actually happens is i get four windows ( and four icons) the
    titles for the four windows are correct ie "child_1", "child_2",
    "child_3", "DECterm 4" BUT the icon titles are "C1", "C2", "C3",
    "C2"! It aapears that the last child decterm window is given the
    icon title from the last window to get going as C2 takes the longest
    to start up (i am just surmising here!)

        re .158
        
>>    Has something happened to this conference as i could have sworn
>>    i entered a reply to this note concerning command line recall (and
>>    got a reply as well)!!! I notice that there is a gap in the new
>>    note creation from 22-aug to 28-aug???
        
        The conference was missing for a bit, and when it came
        back some of it was missing.  Try checking the notes
        first entered after the gap, there may be an explanation
        there.
        
        Dan

    re .159
    
    There was nothing obvious
    
    Gerry

	Hi, I've just started using Child yesterday morning. I got it to work
just fine, positioning my icons using Ix and Iy. Then in the afternoon we
installed V2 of DECwindows, and Child still works, but I can't get it to 
position the icons.

	Below is my child command and my wm defaults.

$ Child -
        /Detach -
        /Decterm -
        /Privilege -
        /Image=Sys$System:LogInOut.Exe -
        /Pause=3 -
        /NoPassword -
        /Title="Ruatha Hold" -
        /ITitle="Ruatha Hold" -
        /Process="Ruatha Hold" -
        /X=0 -
        /Y=150 -
        /IY=5 -
        /IX=0
$!
$ Child -
        /Detach -
        /Decterm -
        /Privilege -
        /Image=Sys$System:LogInOut.Exe -
        /Pause=2 -
        /NoPassword -
        /Title="Benden Weyr" -
        /ITitle="Benden Weyr" -
        /Process="Benden Weyr" -
        /X=240 -
        /Y=150 -
        /IY=3 -
        /IX=0

*sticky:        0
*zooming:       1
*expandiconfocus:       1
*default.geometry:      157x530+912+153


I have a narrow Icon Box that is positioned on the Right side of my screen, and
runs down the side. What I want to do is position my decterm windows in the 
third and fifth icon postion. What happens is they get placed in the very first
position, Ix = 0, Iy = 0, and are underneith by banner icons.

Thanks for any help,

	James.

	I think in V2 the icon box resource is in pixels, and no longer
	in "icon box positions".  So you have to multiply the old values
	by 32.

	Dan

Per discussion going on elsewhere in this conference...

A new version of CHILD is available that allows the "command" parameter
to be specified even when the /NOCOMMAND qualifier is provided.

What this means is that I think you can give the following command line
line to the session manager's customization.  (I don't have V2 yet, so I
haven't tried this):

	CHILD/NOCOMMAND/NEWTERM=(SYS$INPUT,SYS$OUTPUT,SYS$ERROR) "RUN VWSLAT" 

This will cause CHILD to issue the "RUN VWSLAT" command in the SAME
PROCESS as that running CHILD, rather than creating a new process.  The
/NEWTERM quailifier means that the created terminal will be assigned as
these three logical names.  The net result is a single-process no
command-file solution to starting terminal-based applications from the
session manager.

PLEASE let me know if this works as I've claimed.

PRNSYS::RELEASED_TOOLS:[CHILD]*.* is the full kit.  If you have the
latest one already, the only file you need is CHILD.EXE.  (CHILD.C if
you are interested in the sources.)

        re .-1
        
        What happens with
        
        CHILD/NOCOMMAND/NEWTERM=(SYS$INPUT,SYS$OUTPUT,SYS$ERROR) "RUN foo"
        
        after "foo" terminates?  Will the terminal disappear or
        be left at a DCL prompt?  What logicals/symbols will be
        defined?
        
        Dan

>        What happens with
>        
>        CHILD/NOCOMMAND/NEWTERM=(SYS$INPUT,SYS$OUTPUT,SYS$ERROR) "RUN foo"
>        
>        after "foo" terminates?

The logicals are defined in the process logical name table with
LIB$SET_LOGICAL, which put's them in supervisor mode.  As a result,
when the program exits,you get a DCL that already has channels open on
the original terminal, but every program you run from it sees the new
definition.  This means that your issue commands in the original window,
but get the output in the other window.  Pretty ugly indeed.  You are
advised to make the next command a "LOGOUT".

I'll look into putting the logicals in user mode when they are specified
this way, but $CRELNM is a lot harder to use than LIB$SET_LOGICAL, and
I'm pretty laze whenit comes to CHILD changes these days.  Should
somebody be interested, the fix can be made in line 87 of CHILD.C.

Defining the logicals in user mode would probably do no good, since they'd get
deleted when CHILD ran down, and before `RUN foo' began.  One of the drawbacks
of LIB$DO_COMMAND, I'm afraid.

Of course, CHILD could create SYS$SCRATCH:mumblefrotz.COM, containing the user-
mode DCL definitions and the command, and execute that instead.  Kinda (!) ugly,
though, particularly if `command' was actually `@file...'

DELETE 'F$ENVIRONMENT ("PROCEDURE")' as a first line is a neat trick to keep
those temporary procedures from clogging the directory synapses.

#ken	:-)}

The other alternative, then, is to figure out a way to get DCL to use
the new definitions, and throw out the old ones.  Is this possible?

(For CHILD, I'm perfectly happy with the "log out afterwords" solution. 
In the particular case of using this in the V2 session manager, this is
the case anyway, no?)

    I experienced a "ident-mismatch" for vaxcrtl while attempting to
    start up CHILD. When I tried to compile NEWTERM.C I found there
    were two symbols that were undefined:
    
    UIS$C_TERM_END_OF_LIST 
    UIS$C_TERM_COLOR
    
    Everything else compiled without a problem. Am I missing something?
    
    - Russ

       
       
       	Some of you might want to just re-install the latest version if
       	you don't have a current version of CHILD. This bit me. When I
       	updated my DCLtables, I was all set.
       
       							mike
       
       	Nice job Jeff.

It should run anyway.  They come from UISUSRDEF.H, which comes with VWS
when you install the full VWS kit.  CHILD runs on both DECWindows and
VWS, so the development kits of both are referenced.

The requesite definitions are:

	PRNSYS> search sys$library:uisusrdef.h uis$C_term
	#define UIS$C_TERM_END_OF_LIST 0
	#define UIS$C_TERM_COLOR 1

    Jeff, thanks for your help. It turns out that the uisusrdef.h installed
    on our cluster did not have the two missing symbols. When I used
    uisusrdef.h from another cluster it all worked fine. Seems our system
    manager needs to straighten out a few things on our end.
    
    Again, thanks
    
    Russ

Hi,
I am running a recent version of CHILD, (how do you tell for sure?)
The following is from ANAL/IMAGE:

        Image Identification Information

                image name: "CHILD"
                image file identification: "V1.0"
                link date/time:  8-SEP-1989 10:06:42.29
                linker identification: "05-05"
  
I am running VMS 5.2, DW 1.0.

The symptom I get is the following:  After running CHILD even once after
booting, the LOGIN screen maintains the colors and background pattern of
the session most recently logged in.  Another session logging in (whether
it uses CHILD or not) will set up its own colors, and the LOGIN screen will
have those colors after the session is quit.

Any ideas?  Nothing is run with privs, and the most common invocation
is CHILD/DETACH/IMAGE=SYS$SYSTEM:LOGINOUT.EXE...

Thanks,
Kevin

This happens if the individual DECterms are stopped before the DECterm
controller is stopped.  The session manager doesn't locate the process
to STOP if the process doesn't have any windows open, but it doesn't
put the regular background up if there are any clients open, windows or
no.  It's a DECWindows bug, not a CHILD bug, and it's fixed in VMS
V5.3.  A workaround is to STOP/ID the DECterm controller process before
quitting your session.

There may be better work-arounds.

I have read all 171 replies to the child question and still the union 
between my mainframe and my Workstation remains infertile.... 

I have copied the latest version and installed it locally. (It must me 
local because the system manager does not like children)  

my log file looks like any of the earlier ones and it follows.


$!=============================================================================
$!
$! Global Sylogin command procedures of all V5 VMS systems 
$!
$! Donot change this procedure, but change the Site_Login.Com procedure.
$!
$!=============================================================================
$!
$! Set initial conditions for conditional execution
$
$ SET Noon
$ Set NoControl  =	Y
$
$ Verify	 =	F$Verify("")
Installing CHILD for this process
   "CHILD" = "DISK229:[BINGER.WORK.DUNCAN]CHILD.EXE;1" (LNM$PROCESS_TABLE)
Installing CHILD for this process
%DCL-I-SUPERSEDE, previous value of CHILD has been superseded
   "CHILD" = "DISK229:[BINGER.WORK.DUNCAN]CHILD.EXE;1" (LNM$PROCESS_TABLE)
Creating DECTerm controller
Failed to create DECTerm controller
%SYSTEM-W-NOSUCHDEV, no such device available
Identification of created process is %X21a0a6da
Process 0x21a0a6da terminated with status 0x1bc:
%SYSTEM-F-NOLOGNAM, no logical name match
  BINGER       job terminated at 26-OCT-1989 16:31:43.96

  Accounting information:
  Buffered I/O count:          106      Peak working set size:  1809
  Direct I/O count:             75      Peak page file size:    6264
  Page faults:                9600      Mounted volumes:           0
  Charged CPU time:     0 00:00:04.23   Elapsed time:     0 00:01:17.45


Will the union between my workstation ever be fruitful...

	Regards,

		Stephen

Re: .174

I think you need to define DECW$DISPLAY to point to the workstation where
the window should be created (GYPSC, let's say).  In VMS V5.2 (DECwindows V1):

	$ define decw$display gypsc::0

In VMS V5.3 (DECwindows V2):

	$ set display/create/node=gypsc

Do this before running CHILD.

				-- Bob

In ALL version of DECWindows, you must use the $ SET DISPLAY/CREATE form
for defining DECW$DISPLAY.  CHILD will not work properly with a
"node::0" definition of DECW$DISPLAY.  It MUST translate to a WSA device.

I'an confused about CHILD...

if I enable my security so that it allows acess from node::fred and node::bill

.. and then on node <node> as user FRED I do 
Set Disp/create/node=<my_workstation>
Child/Detach/Nopassword 

then I get up a window logged into my account

BUT!

if I do the same as user BILL
... then I get up a window that prompts me for Username:

??

(the accounts FRED and BILL have the same uic, privs, and Uic)

    CHILD is a great tool!  I, though, am having a problem with remote
    CHILD terminals.  Two separate users wish to create remote terminals
    on the same workstation device.  The users are non-privileged. 
    The first user successfully creates a DECTerm window running an
    ALLIN1 application with the following command sequence:
    
    	$ set display /create /node=FRED
    	$ child	/page=24 /focus /pause=5 /priority=4 -
    		/newterm=sys$command /decterm /line /insert -
    		/setup_file=decw$setup./dat -
    		/ititle="Allin1" /title="Allin1" -
    		/input=allin1.com
    
    where ALLIN1.COM contains -
    
    	$ define /user sys$input sys$command
    	$ define /user sys$output sys$command
    	$ allin1

    The second user executes a similar CHILD command file, but gets:
    
    %SYSTEM-F-NOPRIV, no privilege for attempted operation
    
    when executing the CHILD command.

    
    Any help is ghreatly appreciated!
    
    pj

>    		/setup_file=decw$setup./dat -

Does it really say this?  Note the misplaced slash.

Actually, the first thing I would check is the protection on CHILD.EXE. 
Sometimes it goes in with the wrong protection.

>           <<< Note 111.177 by VANISH::BAILEY "SS$_end_of_tether" >>>

>if I enable my security so that it allows acess from node::fred and node::bill
>
>.. and then on node <node> as user FRED I do 
>then I get up a window logged into my account
>
>if I do the same as user BILL
>... then I get up a window that prompts me for Username:

Check the LOGIN.COM for a user specifid definition of CHILD

>
>if I do the same as user BILL
>... then I get up a window that prompts me for Username:

... but if user BILL has default priv BYPASS then it all
works as expected  (ie I dont get asked for username/password)

    Peb
    
    1do a real login as the user, just for me. Still happen?
    2 When you do a SET WATCH on the files on the userdisk, what gets opened
    with BYPASS that isn't opened without?
    
    Andy

	Re .177, here's my guess:

>> if I enable my security so that it allows acess from node::fred and node::bill
>>
>> .. and then on node <node> as user FRED I do 
>> Set Disp/create/node=<my_workstation>
>> Child/Detach/Nopassword 
>>
>> then I get up a window logged into my account

	Does the terminal controller process created by this have
	username fred?

>> BUT!
>>
>> if I do the same as user BILL
>> ... then I get up a window that prompts me for Username:

	Is the terminal device that gets created by this owned by
	the controller process, i.e., by a process with username
	fred?

	Does user bill have the privileges to "take away" the
	terminal device from username fred?

	My guess is that it couldn't take over the device like that,
	and so the window was left not logged in, resulting in the
	username and password prompts ...

>> ... but if user BILL has default priv BYPASS then it all
>> works as expected  (ie I dont get asked for username/password)

	... but that with BYPASS the process with username bill
	had no problem taking the device away from the process
	with username fred.

	Dan

    Whoops.... the slash was a typo
    
    The protection of SYS$SYSTEM:CHILD.EXE is (RWE,RWED,R,RE)... BTW,
    the user is not a group member of SYSTEM.  CHILD was installed via
    "@CHILDINSTALL SYSTEM".
    
    Thanks for your response!
    pj

    Well, I don't know really where to put this note either in the
    'dual-headed' topic, or in the CHILD topic. This is my problem.
    
    Using VMS V5.3 SSB.
    
    I have a dual-headed VAXstation 3100/GPX, and when I have remote
    child-created windows on display 0, if I set my display to screen 1 and
    do another CHILD, I loose all my CHILD sessions (well, the ones that
    were on the screen 0).
    CREATE/TERMINAL works fine.
    
    Any info upon request.
    
    
    Regards,
    Pierre.

I think this belongs in the CHILD note.  It SHOULD work.

Have you fetched the latest CHILD to see if the problem is still there? 
PRNSYS::RELEASED_TOOLS:[CHILD].

Hi,

Child is great I'm sure everyone agrees! 
Someday could child be enhanced to specify icon colors (to match windows)?
If there is a way now let me know.. I tryed every combo of ??iconBox???
  thanks steve

    Can anyone explain the following pilot error when using CHILD:
    
    VMS 5.3, latest version of CHILD.  I can start up VWSlat via CHILD
    if I invoke the following command procedure from a DECterm window:

    $ CHILD/SHRINK/PAGE=24/PROC="VWSLAT" -
        /ITITLE="VWSLAT"/TITLE="VWSLAT control terminal" -
        /pause=10/nopassword -
        /image=sys$system:loginout/page=7/input=sys$login:vwslat.com

    This is VWSLAT.COM:

    $ define/user sys$input sys$output
    $ run sys$system:vwslat.exe
    $ logout
    
    If, however, I try to start it up from within the session manager
    by defining an application as @SYS$LOGIN:VWS_CHILD.COM, it runs
    fine for a short time (which seems to be directly proportional to
    the value I use for the /PAUSE switch) and then dies without displaying
    any error.  By setting the /PAUSE to some ridiculously high number
    (like 120), I can actually use VWSlat to log sucessfully onto another
    system, but after the time expires, both the session and controlling
    windows disappear.
    
    I'm sure that I'm missing something about what the differences are
    in context between starting a process from the session manager vs
    a DECterm, but I'll be damned if I know what they are.  Any clues
    for the clueless??
    
    Al
    

I'd use CREATE/TERM.  However, you probably want to do a /DETACH (or whatever
the corresponding parameter is in CHILD.  The restriction on /DETACH is that
you cannot specify a /INPUT (see example below, which works around this).

	- Dave
-----------------------------------------------------------------------
There is a new CREATE/TERMINAL command in DECwindows V2 (VMS V5.3) that performs
much the same function as the unsupported CHILD utility.  The following will
give guidelines on how to set up a VWSlat terminal using the new command, and
have that terminal activated whenever the sessions starts up.

1 - Under the Customize pull-down of the Session Manager window, select
Applications Definition and add an entry.  I call mine "LAT Terminal" and the
command line associated with it is:

	CREATE/TERM/DETACH/PROCESS="Foo"/WINDOW_ATTRIBUTES=(ICON_NAME="Lat",
		INITIAL_STATE=ICON,TITLE="VWSlat",X_POS=10,Y_POS=625,
		COLUMNS=80,ROWS=12)

2 - Under the Applications Menu pull-down of the Session Manager window, add
the above entry to the Applications Menu.

3 - Under the Autostart  pull-down of the Session Manager window, add the above
entry to the Autostart list.

4 - Edit the user's LOGIN.COM, so that the first few lines include:

 $  If f$getjpi("","PRCNAM") .eqs. "Foo" then @runlat.com
 $  If f$getjpi("","PRCNAM") .eqs. "Foo" then exit

5 - Create RUNLAT.COM that looks like this:

 $! RUNLAT.COM - command procedure called by LOGIN.COM to run a lat terminal
 $!
 $define/user sys$input sys$command
 $run sys$system:vwslat.exe
 $logout

    Thank you, that works - at least, sort of.  The terminal window
    that is created is resized to 80X24.  There is probably a renegade
    SET TERM/INQ doing this, but it's likely to be in familiar territory
    and I should be able to fix it.
    
    Al
    

Actually, if you just add the qualifier "/WAIT" to the original CHILD
command that you were using from the command line, it will work fine
from the install applications menu.  This solution is somewhat cleaner
than the /DETACH approcah, in terms of documentation and
understndability, but it does burn an extra (idle) process slot for the
duration of the VWSLAT session.

As to why this works:

Consider what happens when you LOGOUT the window from which you issued
the CHILD command that started VWSLAT.  Notice that VWSLAT and all of
it's connected sessions disappear.  This is because CHILD, as well as
CREATE/TERMINAL, creates subprocesses instead of real processes.  The
process you invoked from the applications menu was CHILD, which in
turn invoked VWSLAT, and having completed it's task, logged itself out.
(An took it's children along).

/IX and /IY work fine for me, but the units has changed to pixels
instead of "small-icon-size" units.  Multiply all your numbers by 16.

Can someone point me to the latest CHILD kit?  It doesn't appear on 
PRNSYS::RELEASED_TOOLS:[CHILD]*.* as earily notes suggested.  eg:

 AKO539> dir PRNSYS::RELEASED_TOOLS:[CHILD]*.*
%DIRECT-E-OPENIN, error opening PRNSYS::RELEASED_TOOLS:[CHILD]*.*;* as input
-RMS-F-DEV, error in device name or inappropriate device type for operation


Thanx,

...Ed

The files are there, and easily accessed by anybody on the network that
has updated their network database since last July.  Many, many people
continue to get the kit there, and if there is any problem, I insist
that it is a problem local to your own node.

I checked the network database AKOV11, and PRNSYS is correctly listed there. 
Perhaps you were copying from some other node?

Thanks Jeff,

  You were correct.  It appears my workstation's ENET database is way behind.

...Ed

    I've persused all 196 replies to this note and I can't seem to find an
    answer to my seemingly simple question:

    Is it possible for CHILD to log into a remote account?  For example, I
    have an account on node X (my workstation), but I also have an account
    on node Y and I usually use CHILD to create a decterm and then do a SET
    HOST  to node Y and then log in.  I didn't see any qualifiers like
    /REMOTE_NODE= or the like, so I ask you is there a way to do this?

    Thanks,
    Dale

       
       
       
       	Nope.. That would be a major security hole.
       
       						mike

    There's a kind of way to achieve what you want if the remote node is
    running VMS V5.3 or better (specifically if they are running DECwindows
    V2). I have an application in the Session Manager called "DECterm on
    <nodename>", which is defined as "@sys$login:<node>_terminal". This
    file is:
    
$ subrem = "submit/remote"
$ subrem <node>::remote_terminal
    
    On <node>, remote_terminal.com is:
    
$! copyright (c) 1989 digital equipment corporation.  all rights reserved.
$	on error then continue
$	system = f$trnlnm("sys$cluster_node") - "::"
$   create/terminal -
        /application -
        /nobroadcast -
        /detatch -
        /display=buryst::0 -
        /insert -
        /line_edit -
        /type_ahead -
		/window=(rows:32,columns:80,initial_state:icon,-
		title="Remote terminal on ''system'",-
		x_position=0,y_position=345,icon_name='system')   
    
    Sounds complicated, but it works well. You'd be advised to have a line
    like the following in your remote node's login.com to avoid lots of
    unwanted printout.
    
    $ if f$mode() .eqs. "BATCH" then define sys$print nl:
    
    Hope this helps.
    
    Keith

Re: Note 111.199 by BURYST::EDMUNDS 

>    There's a kind of way to achieve what you want if the remote node is
>    running VMS V5.3 or better (specifically if they are running DECwindows
>    V2). I have an application in the Session Manager called "DECterm on
>    <nodename>", which is defined as "@sys$login:<node>_terminal". This
>    file is:
>    
Thanks for comfile Keith. I'll give it a try.  Fortunately, the remote node
IS running V2 DECwindows.  Obviously, the session manager has been enhanced
to allow the use of this kind of functionality...looking forward to trying
it.

Dale

I always just said CHILD "SET HOST KALVIN", and answerted teh username
prompt that came in from Kalvin.

    Just installed the latest version of CHILD, but when I try and run it,
    I get the following error:

%DCL-W-ACTIMAGE, error activating image VAXCRTL
-CLI-E-IMGNAME, image file $1$DUA4:[SYS33.SYSCOMMON.][SYSLIB]VAXCRTL.EXE
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image

    We're still running VMX 5.1-B (please, no flames :-)), so obviously, I
    need to relink either VAXCRTL or CHILD to make compatible with our
    version of VMS.  Any recommendations?

    Thanks,
    Dale

You need to relink CHILD.

--PSW

    We're trying to create a window, within an application, which will
    run another application.  We're using the LIB$SPAWN command and
    the only way we can get it to run CHILD is using the /WAIT qualifier
    within the CHILD.COM.  In other words:
    
    SPAWN @CHILD.COM 
    
    Where CHILD.COM is:
    
    $ CHILD/WAIT/DECTERM/LINEEDITING/INSERT/TITLE="VTX"/ITITLE="VTX"/-
           /PROCESS="VTX"/X=300/Y=756/PAGE=24/WIDTH=80 "VTX"

    Without the /WAIT, it fails.  With it, it works, but the process
    that run the CHILD.COM waits until the CHILD process is done.  Any
    suggestions on how I can get the best of both worlds??
    
    - Mike

    Try to "SPAWN /NOWAIT @CHILD.COM".  That is, call LIB$SPAWN with the
    NOWAIT flag set.