Find A Way Of Passing SYS$INPUT To Command File

[Robert Atkinson]

I've got an interesting problem to tackle. Basically, I want to pass input from SYS$INPUT to a command file in the same way you would pass it to an executable such as SYSMAN.

The structure would look something like this :-

$!
$ @MENU

A
B
C
D
$!
$ EXIT
$!

MENU.COM would then take the A,B,C,D input and use it to create a text file and draw a menu.

I can't think of a way to get the information from the outer layer into the inner layer. Using things like 'TYPE SYS$INPUT' just hangs the command file at that point waiting for input, rather than reading it from the executing procedure.

What I'm ultimately trying to avoid is writing the menu data to disk, so that it can be read in by the menu procedure. Maybe there's a way of using PIPE to put the information into memory and then passing that into the procedure.

Any thoughts on the above would be useful to have.

Rob.

[The Brit]

Hi Rob,
Not sure if Im understanding you correctly. If all you want to do is read from the terminal then use;

$ Read sys$command

i.e. command file "testing.com" contains;

$!
$ Read sys$command test
$ show symb Test
$!
$ exit

then

$ @testing
Data: testing
TEST = "testing"
$

The symbol "test" can then be written out to your command file for execution.

Dave

[Hein van den Heuvel]

No, Robert wants the lower procedure to read the data lines provided in the higher procedure.
If instead of '@menu' he could use 'run menu' then that would happen.
But a lower command file will try to read the data lines from that lower command file itself.

Looks like this has changed with OpenVMS 7.1-2, and 'fixed' to no longer work at all in 7.2
http://h71000.www7.hp.com/wizard/wiz_5813.html
http://h71000.www7.hp.com/wizard/wiz_4810.html

No it is a bit hard to reason when DCL would read local, or above.

Robert, if menu.com had for example a help construct using
$ TYPE SYS$INPUT
hello world
$ EXIT

Where would you want that data to be read from? How would DCL know?
(Maybe because TYPE is an image?)
You'd almost want an @xxx/INPUT right?

I tried a few logical name assigns to see if I could use a logical name to point to the original stream, but no luck so far... Probably because that file is closed while the lower file runs right (I used to know this stuff... It's been too long! :-).

btw... there is something else odd going on in Alpha 8.3:

------- x.com -------------
$read sys$input x
aap
$show symbol x
$read sys$input x
$show symbol x
$show symbol x
$type sys$input
$show symbol x
$show symbol x
------------------------

This will read 'aap' as expected.
But the next read will not get an EOF, but actually read the command "$show symbol x"
As opposed to TYPE which gets an EOF and types nothing, leaving the 2 lines to execute.

Hein.

[Robert Atkinson]

Apologies guys. It was a difficult problem to describe, and didn't come over very clearly.

There'a a current utility called ZMENU. It can be run like this :-

$!
$! TESTMENU.COM
$!
$ ZMENU

^Option1 ^Option2
^Option3 ^Option4

$ exit
$!

The text in the command file is passed to ZMENU.EXE and interpretted to display a menu on screen. The text can also be passed in a file by running '$ ZMENU MENU_DATA.TXT'

I've written a new version of this that uses the TPU editor to interpret and display the menu.

Running 'EDIT/TPU/SECT=MENU MENU_DATA.TXT' will perform the same function as above. What I'd like to do is replicate the 'on the fly' functionality that ZMENU handles.

The end procedure would look like this :-

$!
$ MENU

^Option1 ^Option2
^Option3 ^Option4

$ exit
$!

Somehow, I need to get the text in the command file into the TPU editor. The MENU verb could be a command file that captures the text somehow, writes it to a file, then passes that to TPU.

The problem I have is writing something that can capture the input.

I DO NOT HAVE ACCESS TO A 'C' COMPILER, before someone starts to give me code.

This may not be possible at all, but I thought it was an intriguing problem and might get people in the group thinking.

Rob.

[Robert Atkinson]

Hein, reading through your post, I think you are right. The '/input' would be the perfect way to resolve the problem but not likely to be available.

The reason I started looking at PIPE to capture the required info is because it appears to read input in a similar way to other EXE's. How to get everything working together is another matter.


> As opposed to TYPE which gets an EOF and
> types nothing, leaving the 2 lines to execute.

I think TYPE may have some specific code in to handle data passed from the command file. We know that as soon as it find the dollar, it stops reading and starts interpreting again, so I reckon this is built into the code.

Rob.

[Robert Atkinson]

Actually, I take that back. '/input' still wouldn't work, as it implies a file, and the data is in the command procedure, not a file.

We almost need some sort of DECK that will allow data to be passed, like this :-

$!
$ @MENU
$ DECK
^A
^B
^C
^D
$ EOD
$ EXIT
$!



$!
$! MENU.COM
$ TYPE /OUT=SYS$TEMP:MENU.TXT SYS$INPUT
$ MENU SYS$TEMP:MENU.TXT
$ EXIT
$!


Unfortunately, DECK doesn't seem to pass data into '@xxx' as it doesn't deem it to be "a command that requires input".

Let me have a play with PIPE and see if that will work.

Rob.

[Shilpa K]

Hi Robert,

Is your requirement to capture the data typed at the command prompt and write it in the same way to a file MENU_DATA.TXT? Then, use this file as an input to execute 'EDIT/TPU/SECT=MENU MENU_DATA.TXT'?

For example, if you type:
A
B

The output of the file MENU_DATA.TXT be as below?
$ type MENU_DATA.TXT
A
B

Regards,
Shilpa

[Robert Atkinson]

Not at the command prompt, but within a command file.

[Robert Atkinson]

Right, I think I've got it.

Due to a quirk of PIPE taking input to the first part of the PIPE command, rather than the last part (trust me on that one), I've come up with this.

It has the downside that even if you pass a pre-created file to MENU, it will still create an empty file as part of the PIPE command, and I have no way of deleting the file afterwards because the input filename has to come at the end of the verb.

It could be improved by having two verbs, one that expects a file to be passed, and one that creates the file from SYS$INPUT on the fly.

Anyway, here it is :-

$!
$ MENU :== PIPE CREATE SYS$TEMP:CHOICE_MENU_'PRCPID'.TXT ; DEFINE/USER/NOLOG MYMENU SYS$TEMP:CHOICE_MENU_'PRCPID'.TXT ; -
DEFINE /USER /NOLOG TPU$CALLUSER 'F$ENV("DEFAULT")'ZSCROLL.EXE ; -
DEFINE /USER /NOLOG SYS$INPUT SYS$COMMAND ; -
EDITA/TPU/NOINIT/COMMAND='F$ENV("DEFAULT")'CHOICE_MENU.INI/SECT='F$ENV("DEFAULT")'ZMENU.TPU$SECTION
$!
$ MENU MYMENU
TEST 1
^A
^B
^C
^D
$!
$ SH SYM CHOICE*
$!
$ MENU TEST.TXT
$ SH SYM CHOICE*
$!

By the way, the utility will soon be available on the Freeware sites, as soon as I've put it into a decent package with some notes.

Rob.

[Hein van den Heuvel]

Hmmm,

TPU does not have a way to specify the main input that I can find, other than SYS$INPUT.
Once you redefine that to SYS$COMMAND it can not at the same time be seen as the original sys$input.. the command file. So that's a major challenge.

I tried some PIPE and $CREATE/MAILBOX workaround, but in the end it seems a temporary file was most simple and efficient.
Unless I read your pip stream wrong it seems you are in fact also going that direction.

So why not KISS and move those data lines to be with the CREATE , and not need a pipe At all?

Rough outline below...
Hein.


$MENU :== EDITA/TPU/NOINIT/COMMAND='F$ENV("DEFAULT")'CHOICE_MENU.INI/SECT='F$E
NV("DEFAULT")'ZMENU.TPU$SECTION
$!
$CREATE SYS$TEMP:CHOICE_MENU_'PRCPID'.TXT
TEST 1
^A
^B
^C
^D
$!
$ DEFINE /USER /NOLOG TPU$CALLUSER 'F$ENV("DEFAULT")'ZSCROLL.EXE
$DEFINE /USER /NOLOG SYS$INPUT SYS$COMMAND ;
$ MENU MYMENU
$!
$ SH SYM CHOICE*
$!
$ MENU TEST.TXT
$ SH SYM CHOICE*
$!