A colleague of mine just pointed out that the HPSTREAMEDBY variable now
contains not only the job/session name, but the job/sess number too.  With
that in mind, you could then create a file named FILE### (HPJOBNUM) that
contained the variable contents of HPSTREAMEDBY in the first job.  Any
downstream jobs launched would then query HPSTREAMEDBY for the job/sess
number that streamed it, and then be able to locate the FILE### created by
the streaming process.

Ray Shahan

> -----Original Message-----
> From: COLE,GLENN (Non-HP-SantaClara,ex2) [SMTP:[log in to unmask]]
> Sent: Thursday, May 24, 2001 4:31 PM
> To:   [log in to unmask]
> Subject:      Re: Passing HPSTREAMEDBY from one job to another.
>
> Ray writes:
>
> > Mary streams the job MYREPORT  which is job 111.  MYREPORT then creates
> a
> >  file FILE111 (file name + jobnum).
> >
> >  MYREPORT streams NXTREPORT, but how would NXTREPORT know to read the
> file
> >  FILE111?  Even if NXTREPORT tried to read the job queue (to see
> MYREPORT's
> >  job number), MYREPORT may have already finished.
> >
> >  So, in order for NXTREPORT to read a file known to be created by
> MYREPORT,
> >  MYREPORT would have to create the same file name for NXTREPORT to read
> every
> >  time (hence, a job pair).  The file name that MYREPORT creates is
> MYFILE,
> >  and NXTREPORT always reads MYFILE.
> >
> >  The problem with the job pair is that Sue may stream MYREPORT right
> after
> >  MARY, and then MYREPORT.SUE may overwrite the data in the  file MYFILE
> for
> >  NXTREPORT prior to NXTREPORT reading that file to process data from
> >  MYREPORT.MARY.
>
> Then Wirt:
>
> > In this case, your jobs named MYREPORT would create uniquely named files
> in
> > an MPE group that is totally devoted to nothing else other than holding
> your
> > created files: FILE111, FILE112, FILE113, etc. You might call this
> group,
> > "IN".
>
> Perhaps it would be useful to combine these techniques into one.
>
> That is, MYREPORT can write "FILE111" (etc.) to a message file.
> When NXTREPORT is launched it would (destructively) read the
> message file, process the named file, and quit.  So the message file
> is always the same name, but its contents are unique.
>
> Alternatively, NXTREPORT could *always* have a read hanging on
> the message file, so that as soon as MYREPORT writes the record,
> NXTREPORT would begin processing the file.  NXTREPORT could also
> check for "*STOP" (or some other trigger) to know when to terminate
> gracefully.  In this scenario, MYREPORT would *not* submit NXTREPORT;
> the latter would always be running.
>
> The advantage to the about two techniques is that they are
> relatively simple to implement.  The disadvantage is that
> they are not quite as robust as Wirt's suggestion.  Under
> the above scenario, if NXTREPORT aborts (or the system goes
> down) before FILExxx is processed, then the report is "lost."
> Wirt's suggestion is more robust, since IN.FILExxx is not
> purged until processing of FILExxx is complete.
>
>
> Of course, as we've seen from this thread, there are as many
> solutions as there are programmers.
>
> --Glenn
>
> P.S.  Some allowance would need to be made for job numbers that
>       exceed four (4) digits.  (FIL vs FILE, left-truncate job#,
>       use HFS-named file, or whatever)
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

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