HP3000-L Archives

March 2000, Week 3

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:
"Newton, Tony" <[log in to unmask]>
Reply To:
Newton, Tony
Date:
Thu, 16 Mar 2000 08:32:40 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (97 lines)
If I don't have a resolution in the next couple of hours then I'll give 'em
a call.
Thanx everyone :-)
____
Tony Newton  |  [log in to unmask]
HP Systems Admin  |  (503) 574-5831
Providence Health Plan  |  www.providence.org



> -----Original Message-----
> From: Larry Barnes [SMTP:[log in to unmask]]
> Sent: Thursday, March 16, 2000 6:16 AM
> To:   [log in to unmask]
> Subject:      Re: Job variables
>
> Why not give VESOFT technical support a call?
>
> "Newton, Tony" wrote:
>
> > Hello Jeff,
> >
> > Well, my job executes a command file and if that command file realizes
> that
> > it is not inside of MPEX then it then executes itself again, this time
> > inside of MPEX.  Ie:
> > ======================================== CMDFILE.CMD.SYS
> > parm p1="0" p2="0"
> >
> > setjcw insidempex=0
> > if insidempex=0 then
> >   xeq mpex.pub.vesoft;info="%many \xeq cmdfile.cmd.sys !p1 !p2 \exit"
> > else
> >   PROCESS THE REST OF THE COMMAND FILE
> >   SETVAR GLOBAL TRUE
> > endif
> > ======================================== CMDFILE.CMD.SYS
> > The second time through, insidempex will be 1 and then the rest of the
> > command file will execute.  This is where the "global" variable is set.
> > Once the command file dies the variable has already been set and the job
> > should be able to see it until such a time as it dies.
> > Does this seem accurate so far?
> > ____
> > Tony Newton  |  [log in to unmask]
> > HP Systems Admin  |  (503) 574-5831
> > Providence Health Plan  |  www.providence.org
> >
> > > -----Original Message-----
> > > From: VANCE,JEFF (HP-Cupertino,ex1) [SMTP:[log in to unmask]]
> > > Sent: Wednesday, March 15, 2000 2:32 PM
> > > To:   'Newton, Tony'; [log in to unmask]
> > > Subject:      RE: Job variables
> > >
> > > All user created CI variables are global to the job or session
> > > in which the variable been set.  Any process in a job or session
> > > has full access to any variable created in any other process
> > > inside the SAME job/session.
> > >
> > > A job directly executing a script (or UDC) is doing so in the
> > > context of the same process.  That is, the CI does not create
> > > a new process to execute a script.  Once a job terminates, the
> > > variables created within that job are deleted.  Perhaps, the
> > > scripts you are referring to where executed inside a different
> > > job?
> > >
> > > My comments above pertain to CI variables.  POSIX shell variables
> > > are local in scope unless explicitly exported.
> > >
> > > regards,
> > > Jeff Vance, CSY
> > >
> > >
> > > > I'm troubleshooting a monitoring job that executes numerous
> > > > command files
> > > > and is then supposed to check the results of variables that
> > > > the command
> > > > files set before they died.  The problem I am running into is
> > > > that the job
> > > > does not see the variables that are being set by the command
> > > > files.  I can
> > > > run the command file and after it dies I can still see the
> > > > variables that it
> > > > sets.  Why would it be different with a job?  As I understand
> > > > it, in Unix a
> > > > parent process has to export a variable for its child
> > > > process's to see it.
> > > > Could it be that I am running into something similar (in reverse).
> > >
>
> --
> Larry Barnes
> Director of MIS
> Mitek Corp.
> 4545 E. Baseline Rd.
> Phoenix, AZ 85040
> [log in to unmask]

ATOM RSS1 RSS2