OK,

I admit I've been deleting items without reading them, but this one caught
my eye before the delete button could be hit. I don't know how appropriate
this solution is to the problem being discussed, but there is a "workaround"
class solution that is available using file equations and MULTI access.

Consider the following input file:
: print xinfile
Line number 1.
Line number 2.
Line number 3.
Line number 4.
Line number 5.

And the following script:
: print xscript
file zzz=xinfile,old;multi
echo Starting now...
input invar < *zzz
echo !invar
input invar < *zzz
echo !invar
input invar < *zzz
echo !invar
input invar < *zzz
echo !invar
input invar < *zzz
echo !invar
reset zzz
echo All done.

If you execute the script normally, you get the behavior that has been
described:
: xscript
Starting now...
Line number 1.

Line number 1.

Line number 1.

Line number 1.

Line number 1.

All done.

But if you add the following modifications, you get this output:
: file yyy=xinfile,old;multi
: xscript < *yyy
Starting now...
Line number 1.

Line number 2.

Line number 3.

Line number 4.

Line number 5.

All done.

This is works because you're doing exactly what Ted said to do. By using
redirection to the script, you're causing the CI to open the input file. It
will be kept open until the command file xscript completes. Because we've
specified MULTI access, all opens of the file share the same data pointer,
which gets advanced each time someone reads from the file. The input
commands in the example script could be replaced with executions of other
scripts, programs, or whatever suits your fancy.

Hope there's some usefulness in this!

Take Care,
Craig


> -----Original Message-----
>
> Because then the CI would need to either keep a record counter, so that it
> could seek to the correct record of the file or else have kept the fil
open.
> It's that "have kept" part that's what's sticky.  In other words, this
> should work:
>
> :comment get line 1
> :input < myfile
> :comment get next line
> :input << myfile
>
> But if we go that way, then when should the CI close a file it has open?
> The implications of it, by default, keeping open every file it opens are
not
> particularly good.
>
> Ted

* To join/leave the list, search archives, change list settings, etc *
*     please visit http://raven.utc.edu/archives/hp3000-l.html       *