First: Sorry for the delay in my response to this thread.

>I'm having a bit of trouble following this, so let me restate what I think
>you mean, to see if I've understood or misunderstood. 
>
>You have a application whose menus build and submit job streams. Instead of
>streaming the jobs this way, you want to have an existing job stream, which
>you can stream, that are exactly the same as the application builds. Is
that
>about right? 

That is correct and the application is EMACS.

>Now, do you still need help with this? While I know MPE, I am just learning
>Linux and still a newbie. But I can still provide some analogies between
the
>two that might help. We have nothing native to MPE that is like cron, that
>will always automatically stream jobs at certain times. We have a robust
>scheduling facility, and you can easily write job streams or command files
>which will automatically stream jobs. You can even have your system
>automatically stream such a job at startup, or schedule such a job to run
>daily or weekly or whatever you need. But there's no cron or crontab. 

I've been in the *NIX-bussiness for a looong time and a linux-nerd from the
very beginning. I like the analogies.

>Our [log in to unmask] is where the outputs normally go, our "stdlists", rather
>Like the mail program for croned jobs. [log in to unmask] is, very much unlike
>cron, where the text of a job stream lives, between the time that it is
>streamed, and when it finishes run. We can stream a job to run at any date
>and time (although 'now' is the default), and the existing job stream file
>is essentially copied there, at that time. 
>
>Yes, you can, in various ways, raise priorities, or even just stop the
>spooler, so that a streamed job will sit, not running, and you can examine
>the [log in to unmask] I  imagine that you have been given several ways to do
>this. 

I'm banging my head at those files: The [log in to unmask] yells "PRIVILEGED FILE
VIOLATION" whatever I do to try to peek at them (and yes - I am logged in as
manager.sys).
Any suggestions on how to wrestle the info in a readable form from those
files?

>Others probably explained much of this. I hope that you will keep this
>thread going on the 3000-L. We could do with just such a discussion. 

I've received some interesting suggestions/ideas that I'm trying out just
now (but so far without any luck). I'll surely let the list get the "cream"
of my findings at a later time.

>Greg Stigers 
>http://www.cgiusa.com

Regards,
Søren Brandbyge, LEGO Direct

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