HP3000-L Archives

August 1996, Week 5

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Michael L Gueterman <[log in to unmask]>
Reply To:
Michael L Gueterman <[log in to unmask]>
Date:
Thu, 29 Aug 1996 16:33:50 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (52 lines)
Jeff,
 
  Overall, the "high level" sounds great, but I have a question
concerning your definition of a "local variable" below:
Define a script local CI variable:
----------------------------------
 
A variable created in the context of a UDC or command file (i.e, a script) via
a SETVAR command or setvar() function.  This
variable is accessible only within the script that created it. Specifically,
it is not inherited by "children" scripts, nor is it accessible to processes
run from the script.  There are no permissions defined for script local
variables: the script can create it, read it, write it and delete it.  Script
local variables are implicitly deleted when the script that created them exits.
 
Script parameters are treated like script local variables except they cannot
be deleted.  This allows a script to change the value of a parameter.  (Note
parameters are always pass-by-value.)
 
For the remainder of this document "local variable" will refer to a script
local CI variable as described above.
 
 
Unless I'm misunderstanding, then you could not programmatically create
a "local variable", would that be true?  Here is a 'true life' scenario
that "local variables" (maybe defined differently :) would help:
 
1.  A father process (program a) creates multiple child processes (program b).
    All variables created (currently) by 'program b' are accessible to all
    processes from it's father on down each process tree branch.
2.  Unless 'program b' is specifically coded to create 'uniquely named'
    variables (maybe by using it's PIN), the usage of those variables by
    any of the 'children' is suspect.
What would help here is the ability for a process to create a "process tree
localized" variable that would be available to the process that created it,
and any of "its" subsequent children.  If a subsequent child process creates
a "like named local variable", it would start the process anew from that point
forward.  Any "process tree localized" type variables created by peer processes
would be unavailable.
  This situation comes up daily for my major client.  The ability to do "local
variables" in the script would be handy, but its programmatically where I can
see the most use for it currently.  Not to seem pushy, but how about a similar
functionality for FILE equates?
 
Regards,
Michael L Gueterman
Easy Does It Technologies
email: [log in to unmask]
http://Editcorp.nwinfo.net
voice: (509) 946-6179
fax:   (509) 946-1170

ATOM RSS1 RSS2