[Info-vax] MPA105: and RWAST'd

[Bob Koehler]

In article <b117ef30-6fdf-49f4-a8a5-a0ae099a4e8a at h7g2000prf.googlegroups.com>, Jojimbo <jjgessling at gmail.com> writes:
> 
> $ feob 563,grp104/match=and | -
>   (read sys$pipe line ; define/job/nolog search_result &line)
> $ get = f$trnlnm( "search_result", "lnm$job",,,)
> $ loc = f$locate("_PRT", get)
> $ show sym get
>   GET = "563 GRP104_BLUE_PRT   0  OPERATOR   08/01/2011
> SORT AND PR
> $ size = f$extract( loc+4, 4, get)
> $ sho sym size
>   SIZE = "   0"

   Since the above script only reads one line from the pipe, it is
   limited to finding the data or not in the first record.  Is that
   really what you're doing?  Or are you piping into a loop that
   reads until you found the record?

> This seems to work fine and the right record is found and the the
> desired data is found.  (feob is a symbol for a command that produces
> the data records).  The end of the batch log has the usual accounting
> information but the job does not really complete and remains in a
> RWAST state.  In SDA doing "show proc/channel/index=batch_job_index
> shows:

   The RWAST for the parent process is probably due to the subprocess not
   exiting.  In this case it won't show up as a parent process channel
   issue.  

> There is a subprocess of this batch job that is in RWMBX state.  In
> SDA the "show proc/chan" displays no channels marked as busy and two
> channels for a device MPA105:   From DCL, "show dev/full MPA105:"
> shows the Owner process as the batch job.

   I'd prefer that you'ld shown that output, but I think we can figure
   this out based on what you said.

> 
> $ open/read input MPA105:
> $ again:
> $ read input line
> $ show sym line
> $ goto again

   There's the clue.  It looks like the parent process is not reading 
   the rest of the data from the pipe after it finds the data it wants.
   Pipes are written as a variation of the mailbox driver, and they have
   a finite size.  If they get full and a process tries to write to
   them that process goes into RWMBX.  So the subprocess has more data
   to write than what the reader took plus the size of the pipe.
   
> I'm wondering why there were no busy channels.  And what is MPA105
> anyway?  Why did the batch log look like the job had completed?

   I think MPA105 is the pipe device.  A mailbox device would have
   been an MBA.  The output at the end of the batch job is a part
   of the process of winding down a batch job.  That much got done
   successfully, but actually winding down the process tree got hung
   because of the full mailbox.

>  And
> most important is there some sysgen parameter (or UAF quota) that I
> need to adjust to get this to complete normally?  DEFMBXBUFQUO? or
> something else?

   You just need to change the script you took that snippet out of so
   that it empties the mailbox.  I would pipe into a second script that 
   loops until the correct record is found (unless you know the data is
   always in the first record), then copies sys$pipe to nla0:.  That will 
   cause the subprocess to wait on the soon empty pipe, but it can and 
   will go away when the batch job is done.

   Or, if you can tell when the feob is done writing by looking at the
   content, or counting the records, then just loop over reads that
   throw away the remaining data until done and let the subprocess exit
   by reaching the end of the script after emptying the pipe.