| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 595.1 | logicals, symbols, or (ungh) files | BAXTA::PFISTER_ROB | Are we having fun yet? | Tue Nov 10 1987 09:01 | 5 |
| You could pass parameters by route of symbols or logicals, or if
worse comes to worse, write stuff to a file in one procedure, and
read it back in by the other.
Robb
|
| 595.2 | | UFP::MURPHY | I'm not a hacker, but play one on TV | Tue Nov 10 1987 09:45 | 4 |
| You could also quote the parameter string and pick them apart later.
(In other words, pass everything into P1 and use F$ELEMENT to extract
the separate parameters).
-Rick
|
| 595.3 | call from another procedure | NACAD::SITLER | | Tue Nov 10 1987 16:37 | 34 |
| re .0:
(Is PARSEC::JACKSON (COMMAND_PROCEDURES note 494.0) your alias?)
I'm a bit confused. You say that the command procedure in question is part
of a package and that it is not acceptable to alter the code. Yet you want
to pass it more than 8 values as *parameters*. Assuming that it now
solicits 10 responses *interactively*, making those responses *parameters*
would involve changing the code. Perhaps you mean that it is not acceptable
to change the "feel" of the procedure to an interactive user, but you would
nonetheless like to parameterize the inputs.
I would suggest having your BASIC program write *another* command procedure
that calls your procedure and passes it the desired inputs. This calling
procedure would look something like this:
$!CALLER.COM -- call MYPROC.COM with particular inputs
$!
$! created by <BASIC-program> on <date>
$! <any other comments you care to include>
$!
$
$ @MYPROC
<response-1>
<response-2>
.
.
.
<response-10>
$ exit
CALLER.COM can be invoked (@), or SPAWNed, or SUBMITted to BATCH. If it is
SUBMITted, and you wish to run MYPROC from a sub-directory, you'll have to
include a line "$ SET DEF [.<subdir>]" in CALLER.COM.
|
| 595.4 | Can't feed SYS$INPUT => SYS$INPUT | CHOVAX::YOUNG | Back from the Shadows Again, | Tue Nov 10 1987 21:54 | 8 |
| Re .3:
I do not believe that a command procedure can feed input to another
command procedure in this manner. This is how a command procedure
would send input to an image, but I do not think that it will work
for another command procedure.
-- Barry "one who has tried"
|
| 595.5 | SPAWN or SUBMIT | NACAD::SITLER | | Tue Nov 10 1987 22:42 | 4 |
| re .4:
Oops. CALLER.COM will not work as planned if you invoke (@) it. But it
*will* work if you SPAWN or SUBMIT it.
|
| 595.6 | P9:== ??? | LEPTON::HIRST | Lean, Mean, Fast | Wed Nov 11 1987 03:59 | 12 |
| If you actually build the symbol names within the procedure
$ count=1
$ foo=p'count
could you build p9 outside the call
$ p9:==par_no_9
Just a thought
Steve
|
| 595.7 | Reply from the "Alias" | PARSEC::JACKSON | | Wed Nov 11 1987 22:24 | 21 |
|
Re: .3
Gregg (PARSEC::COTE) and I (PARSEC::JACKSON) work together, hence
the similar notes in both the HACKERS and the COMMAND_PROCEDURES
conferences. Let us consider this efficient coverage.
To explain not wanting to run *interactively*, we are writing an
application that will gather the user's inputs and use those inputs
to execute the LAVC add (satellite) function. This will all be
transparent to the user. Because this software is a layered
product, it is unacceptable to modify the existing code.
Re: all
Thanks for all of your help. I have found, from your info, that
the DCL command SPAWN/INPUT=<filename> does work. Is there any
reason that this should not work in BASIC?
Debora Jackson-Gerfen
|