Fwd: environment variable handling under UNIX

[arthur kogan]

Hi Robert,

what you said about the variable set by the child process not being visible to
the parent process is the way UNIX works and there is nothing you can do about
it.

Note that there are 2 ways of calling one UNIX script from another. You can call
it by
...
myscript2
...

This creates a child process strarting up a new shell. Anything set in myscript2
gets lost when it terminates and is not available back in myscript1.

The second way is to "dot" or "source" the child script (depending on the type
of shell you are using), as in
...
. myscript2
...

This does not create a new shell to run myscript2, but runs it in the current
shell. Therefore anything set in myscript2 is visible to myscript1 in the
statements after the call to myscript2.

Now, UNFORTUNATELY when you run a command from a QUICK screen, it only uses the
first type of call, i.e. it starts a new shell and therefore anything done there
is not visible. What I would suggest in this case is the use of "COMMANDCODE"
function (check it out fully in the manual). The basic idea is you "run command"
with "on error continue" option. This lets you terminate the command with exit
codes other than "0" (i.e. success) without causing error in the screen after
completion of the command. You can therefore exit the command with various exit
codes signifying the required conditions and get this information back to the
calling screen using the call to "COMMANDCODE" function (which will return the
exit code). You can then base logic in the screen accordingly.

The second problem is easier. The simple solution to the problem of setting a
value in a QTP and accessing this value in the following quiz, is to run the
quiz from within the qtp, e.g.

qtp << !!XX
exe myqtp.qtc
...
quiz << !!YY
exe myquiz.qzc
...
!!YY
...
!!XX

In this case quiz is a child of qtp and therefore has access to everything that
is set in qtp. Note that you can call a UNIX script instead and have a number of
programs called from there, all of which would be qtp's children (or
grandchildren really).


Gee, that was a long one...

I hope this helps.

Regards,

Arthur Kogan
Westpac Financial Services
Sydney, Australia

EDISR@dteenergy.com wrote:

> Subject: environment variable handling under UNIX
> Date: 06 Aug 98 13:47:04
> From: "Robert Edis" <EDISR.DECO.COM>
> To: ph_list
>
> G'day all
>
> We are converting are PowerHouse 6.10e1/VMS/Rdb system to PowerHouse
> 7.33/UNIX/Oracle 7.3.4.  We currently use the GETSYSTEMVAL and SETSYSTEMVAL
> in
> many areas of our code and worked out long ago that to be reliable the value
> had to be a VMS Logical in at least the LNM$JOB table.  Now we are moving to
> UNIX we have found that using an environment variable does not always work.
> A
> child process can 'see' a variable created by its parent but not the other
> way
> around.
>
> Here are some examples of how we use logicals in VMS:
>
> 1.
> QUICK screen calls a DCL script
> DCL script runs a 3GL program that returns a result (exit(n))
> DCL script creates a JOB logical based on result and exits back to the QUICK
> screen
> QUICK screen then does a GETSYSTEMVAL to read the logical value.
>
> 2.
> QTP request reads an input parameter and assigns value to a logical using
> SETSYSTEMVAL
> Subsequent requests (and maybe QUIZ reports too) use CHOOSE SYSTEMVAL ....
> to
> read the logical.
>
> Now the question: does anybody out there know how we can successfully
> reproduce this in a HP/UX environment where LOGICALs don't exist?
>
> We have already thought of using temporary files to store the values but
> this
> will require a lot of rewriting and testing of code.
>
> Your input will be much appreciated thanks
>
>
> Robert Edis (Blue)
> Technical Consultant
> Michigan, USA
> (VAX/VMS, ORACLE Rdb, PowerHouse 4GL)
> = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
> Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
> powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
> This list is closed, thus to post to the list, you must be a subscriber.



= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.