Thanks to all.
I have gotten some really good pointers and ideas both through this list and
by direct mail.
So now it's time for the hard work.
I have implantet a few rounding comments below.

Regards,
S.Brandbyge LEGO Direct

>-----Original Message-----
>From:  Roy Brown [SMTP:[log in to unmask]]
>
>Søren Brandbyge wrote:
>> Hi All
>>
>> Hope you will bear with a newbie (both to this list and to MPE),
>> but I'm stuck with a problem:
>>
>> I have some applications that via the answers to some menu- and
[...snip a lot ...]

>Before they run, the jobs will be of the form Innnnnnn.IN.HPSPOOL
>
>where n is a digit, and there might not be seven of them. I'd put I@, which
is
>how we express it in MPE, but your email software would think [log in to unmask]
>was some pesky email address (see?).
>
>You'll need PRIV mode to see them. Log on as MANAGER.SYS (password issues
>here - is it just you and the HP3000, or are there other people involved?
>Anyway, if there is a Sysadmin for it, and you aren't it, get him/her to
log
>you on).
>
>Then you can grab them. (I take it you are working with Reflection, or
>ScreenJet, or some other terminal emulator on a PC, and not a direct HP
>terminal?) Then you can work with them on your PC, and port them back, or
>whatever you want to do.
>
>Given the way the HP3000 works, the fact that you have to wait for each job
to
>finish before loading the next is less likely to do with job naming
>conventions, or having a single 'job description' file, than it is to do
with
>how the jobs run. (Though we should never overestimate the ingenuity of
>preceding programmers).

As I've been told, the issue is both naming convention and the fact that the
jobs are immensively greedy (very badly programmed indeed).

>
>In other words, it would be fine to line up all the jobs in advance, ready
to
>run, and the job inputs (we call them $STDINs) wouldn't conflict. But if
you
>ran them all at once, maybe they would conflict, because (a) they'd fight
over
>the data or (b) job B genuinely needs to run after job A because it uses
the
>output from it, or needs the data as updated by job A.

Some locking occur and some clashes of filenames is known to happen.

>
>All the usual stuff you'd know from U**X - (b) nobody can do anything
about;
>(a) can often be due to sloppy coding, and is fixable/avoidable, but
probably
>not within your operating parameters.

All apply ;-)

>
>But it could also be reason (c) - historically, multiple jobs would impede
one
>another for machine resources (not data). So the decision was made to run
them
>sequentially, a decision that might not be so valid with today's more
powerful
>machines.
>
>How you find out which it is is a whole other stack of bricks, of
course....
>
>After the jobs have run, their output and the STDLISTs (job listings
showing
>how they ran) might be in [log in to unmask], especially if you can suspend
>printing. They won't be PRIV there, and so are easier to get at, but there
>will be a lot of stuff shown that is a result of running the jobstream, so
it
>will be much harder to pick out the original commands. Also, the jobs may
have
>SET STDLIST=DELETE in them, in which case there won't be any such output.
>
>I'd go for IN if I were you.

Yes - indeed. "IN" is the way.
I can se now, that I have 3 types of jobs wreacking havoc. 2 of the types
seem to be fairly simple to handle and the last type I have to investigate
further.

>
>Lots of luck, and sorry about (and for) the people who only read the first
16
>characters (after Re: [HP3000-L]) of the subject....
>
>> I have considered using priorities and a controlling stream to
>> serialize the jobs, but with often more than 30 jobs to be
>> serialized, its not simple and it don't address the tedious task of
>> entering the same data over and over again.
>>
>> Does anybody have an idea or perhaps a hint about where I could find
>> some info?
>>
>> Thanks in advance
>> Regards,
>> S.Brandbyge, LEGO Direct
>>
>
>-- 
>Roy Brown
>
>Posting with the OEnemy, tamed by OE-QuoteFix
>http://jump.to/oe-quotefix

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