HP3000-L Archives

June 1997, 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:
Ted Ashton <[log in to unmask]>
Reply To:
Ted Ashton <[log in to unmask]>
Date:
Tue, 17 Jun 1997 11:06:04 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (93 lines)
Thus it was written in the epistle of Bruce Jamieson,
> 'Morning
>
> >Greetings
> >
> >Probably someone else on the net will have an answer for you, but I've only
> >questions.  Are you running the perl program from inetd or as it's own job?
> >Are you making a seperate connection to the port for each MPE/POSIX command
> >or do you connect and send a string of commands?  I'm looking for reasons that
> >the environment might be getting reset.
>
> Ok - the program can be run from the command prompt or as a job - I haven't
> hooked it in to inetd.  The "server" sits on a certain port and listens for
> connections from a client.  The client doesn't have very many smarts built
> in and is a user/batch interface that accepts multiple commands, performs
> some parsing, then sends it to the server.  The server is session based -
> it'll take
> as many commands as you want and return the output/set variables locally.  An
> example session might be:
>
>         Client> setvar name     # remotely sets a variable "name" to the value
>                                 # of the local variable "name"
>         Client> mpeexec script  # Run a script/program of some kind
>         Client> getvar phone    # Set the local variable "phone" to that of the
>                                 # remote variable
>         Client> exit
>
> That is an over simplified answer - the weird part is that the environment
> variables were being set ok when the server was run from the command prompt -
> now, as a batch job, variables just don't stay "set" - the setvar command
> works, but the variable isn't set!
>
> The server is using: system("callci setvar varname varvalue") - to execute MPE
> commands.
>
> Does this give you any ideas?

Bruce,
  Well, it gave me a place to start testing.  I played around with a perl
script until I think I've found a fairly simple example which shows the
problem.  P'raps I'm doing something wrong, though.  I created a script, which,
in my unbounded creativity, I called "X":

system('callci showvar varname');
system('callci setvar varname \"varvalue\"');
system('callci showvar varname');

Running this from my session, I have:

:perl X
showvar varname
        ^
Variable not found in variable table. (CIERR 8106)
VARNAME = varvalue

which is what I would expect.  I created a job which simply did the same thing
in batch mode and got the following:

 1
 2 JOB XX,ASHTED.SYS,ASHTED.
 3 Priority = DS; Inpri = 14; Time = UNLIMITED seconds.
 4 Job number = #j994.
 5 TUE, JUN 17, 1997, 11:00 AM.
 6 HP3000  Release: C.55.00   User Version: C.55.00
 7 MPE/iX  HP31900 C.05.08  Copyright Hewlett-Packard 1987.
 8 All rights reserved.
 9 STREAMED BY ASHTED.SYS (#S205) ON LDEV# 25
10    STREAM DATE:   TUE, JUN 17, 1997, 11:00 AM
11 :perl X
12 showvar varname
13         ^
14 Variable not found in variable table. (CIERR 8106)
15 setvar varname "varvalue"  >U2E005F.ASHTED.SYS
16                                    ^
17 Unexpected character found in string. (CIERR 9815)callci: error opening redirection file
18 showvar varname
19         ^
20 Variable not found in variable table. (CIERR 8106)
21 :EOJ
22 CPU sec. = 7.  elapsed min. = 1.  TUE, JUN 17, 1997, 11:00 AM.

So, first, are you getting similar symptoms in your $STDLIST?  And, second,
does Mark have any wisdom for us on the subject?  I'm afraid it's beyond me.

Ted
--
Ted Ashton ([log in to unmask]), Info Serv, Southern Adventist University
          ==========================================================
Neither in the subjective nor in the objective world can we find a criterion
for the reality of the number concept, because the first contains no such
concept, and the second contains nothing that is free from the concept.
                                        -- Dantzig

ATOM RSS1 RSS2