HP3000-L Archives

July 1996, Week 1

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:
Larry Byler <[log in to unmask]>
Reply To:
Larry Byler <[log in to unmask]>
Date:
Wed, 3 Jul 1996 19:28:45 GMT
Content-Type:
text/plain
Parts/Attachments:
text/plain (21 lines)
Jim Killam ([log in to unmask]) wrote:
: We have run into a situation where we have a batch job (this job is always
: running) that launches a couple of son processes (say A and B). If A finds or
: causes an error, the value of HPCIERROR (if I remember that is what it is
: called) is set, but then B is processing and checks the value of this
: variable and finds an error has occured (because of A) and while they are not
: related, thinks it has an error and does some type of error handling. Rather
: than sharing this system variable, is anyone aware of a way to let A and B
: have their own unshared value for HPCIERROR (Or any system variable)?
 
The short answer is No.  All CI variables are shared throughout the
job/session tree.  However, it should be relatively straightforward to
concoct a co-operative naming convention which would keep Proc A and Proc B
from tripping over each other's variables.  It could be as easy as
PROCAVAR1 and PROCBVAR1.
 
But if you're referring specifically to HPCIERROR (or any other HP
pre-specified variable), the above scheme won't work.
 
-Larry "what! me CI?" Byler-

ATOM RSS1 RSS2