> -----Original Message-----
> From: Søren Brandbyge
> >-----Original Message-----
> >From:        Tom Emerson
> >> -----Original Message-----
> >> From: Søren Brandbyge
> >> I have some applications that via the answers to some menu- and
> >> input-fields, auto-builds and streams some jobs for me.
> >[...] there is only a single parameter that differentiates the jobs.
> >
> >VESoft makes a product called "streamx" which is designed to
> solve exactly
> >the problem you're describing[...]
>
> Yes "streamx" could do something like what I want. But it's somehow an
> "overkill".
>
> In *NIX it's a piece of cake to locate a job, either through
> "crontab" or in
> the "at" spool-directories or in "whatever-tool-spool-directory" the
> job-info has been stored as a plain file containing either a
> copy of the
> program-to-be-run or a parameterfile or both.
> Peeking this info and crafting recurring jobs is very very simple.

As others have noted, submitted-but-not-executed jobs are kept in the
directory IN.HPSPOOL with a filename of I#######.

> What I'm looking for is to get hold of the same info within
> the MPE-system.
> It _has_ to record the job-info somewhere, but where is it
> and what's been recorded?

I think I'm stumbling over what you are calling the "job-info" -- by this,
do you mean the actual contents of the "stream" file, or just certain
parameters used by the program(s) contained in the job?  In MPE, "job info"
generally refers to information about a specific job, such as the job
number, the originator [the user.account used to submit the job] as well as
the user.account where the job actually "does the work" [these aren't always
the same] -- none of this, however, refers to any content of the job (run
proga.group.account; start-date=1/1/2002; etc)

From your description, I'm making the assumption that the "job-info" that
you are looking for is the values you entered in response to your
applications and menus -- if thats the case, then it is entirely possible
(though unlikely) that the application itself has the entire
"job" --hardcoded-- within it.  I know MCBA used to do this -- you would
enter the start and end dates for a report (for instance) and the program
would build the "entire" job based on a template stored within the program
itself -- since the program had complete control over what was placed in
each line of the job to be submitted, it was trivial to simply insert the
start and end dates as needed.

If the application doesn't store the job in memory, then you would have to
look within the application's support files [of talk to the vendor or dredge
up the source if this was built in-house] to find the original job.  I'm
guessing [if this is how the program works] that the job "template" has some
special "tags" or tokens of some sort that the application program is
looking to replace -- in this regard, it is EXACTLY the same as STREAMX, its
just that the format of the "tokens" may be different.

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