Ray,

        That's what I was saying with "Part of the HPSTREAMEDBY variable value
available to the created job shows the job number of the originating job.
So, the created job would be able to figure out the "job pipe" file name.
Plus it would be unique for each originating job."  yesterday morning, hence
the whole model I put forth to solve the problem.  I apologize if it was not
stated clearly.

Thanx,
  Jonathan (Jon) M. Backus, MPE-CSM ~ President
  Tech Group ~ 15 Catawba Place ~ Hagerstown, MD ~ 21742-6515
  Email: [log in to unmask] ~ AIM: JMBackus
  Vmail: 301.988.0614 ~ Fmail: 301.714.1854
  Web: www.TechGroupMD.com


-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]]On
Behalf Of Shahan, Ray
Sent: Thursday, May 24, 2001 5:53 PM
To: [log in to unmask]
Subject: Re: Passing HPSTREAMEDBY from one job to another.


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 *

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