On Mar 25,  2:22pm, Donna Garverick wrote:
> Gavin Scott wrote:
> > 1) What if :LISTF simply did not display large files?
>
> in mulling this over - i've decided (big whoop-tee-doo :-) that this is a
> good way to go.  if listf(ile) encounters a 'too big' file - set
> hpcierr (or is it cierror...or is it both...?).  if you're looking for
> the listf(ile) to fail - then you're probably set up to deal with
> the error.

One problem that someone else thought of is do you want to fail a
job that does LISTF[ile],2 on a large file BUT does not run a program
to process the output?  That is, some customers might to LISTF,1 (or ,2)
in jobs that have nothing at all to do with parsing/extracting the output.

I guess this idea could be augmented by stating that if output is redirected
to disk (via the 2nd arg to LISTF or via CI IO redirection) and you have
a large file then you get the CIERROR.  Gets kind of complicated quickly.

> i think having a whole new listfile option (what number
> *are* we up to now...?) is the better way of handling
> the whole problem rather than trying to retrofit listf(ile),2.

My guess right now is that we will have a new format for LISTF[ile] that
is disk space oriented.  It might contain the following data:

  filename
  file size in bytes and (MB)
  file limit in bytes and (MB)
  ldev mapping (list of LDEVs that the file lives on)
  what else???

Jeff Vance, CSY

p.s.  I plan to respond to several of the very thoughtful replies
on this thread (I've saved every message).  Sometime soon I will be
asking for people who continue to be interested in this topic to
form a working group and we can continue the discussions without
consuming so of the 3000-L bandwidth.

--