Well, after Alan's comment about bug-spray <g> I opened a call with IBM here, and they gave me a PMR number, so you might be hearing from them too.
Thanks, Shimon ---- Original message ---- >Date: Wed, 19 Aug 2009 09:32:14 -0400 >From: Colleen Brown <brown...@us.ibm.com> >Subject: Re: FLIST on SFS, *HEADER ignored >To: IBMVM@LISTSERV.UARK.EDU > > I'm checking into this. I don't have an answer yet > on why it was done the way it was done. There were > two developers who worked on that design one of > which is still around. I have sent him a note > asking if he remembers. I haven't heard back from > him yet. I will let you know when I do. > > Colleen M Brown > IBM z/VM and Related Products Development and > Service > >Alan To IBMVM@LISTSERV.UARK.EDU >Altmark/Endicott/i...@ibmus cc >Sent by: The IBM z/VM Subject Re: FLIST on SFS, >Operating System *HEADER ignored ><IBMVM@LISTSERV.UARK.EDU> > >08/18/2009 10:46 AM > >+---------------------------+ >| Please respond to | >| The IBM z/VM Operating | >| System | >| <IBMVM@LISTSERV.UARK.EDU> | >+---------------------------+ > > On Tuesday, 08/18/2009 at 09:41 EDT, Shimon Lebowitz > <shimon...@gmail.com> > wrote: > > I don't use FLIST much on the 'desktop', but it is > very useful > > when embedded in applications with the PROFILE and > ONE > > options, and sometimes USE too. > > I am developing something today, and am surprised > to see that apparently > > (if I am understanding correctly what I see) the > *HEADER statement > > in the profile is ignored when FLIST is displaying > the files of an SFS > > directory. > > Aha... the thlot pickens... > > Even running plain vanilla FLIST, the header > disappears for SFS. > > For a disk: > > q disk b > > LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS > USED-(%) BLKS LEFT > BLK TOTAL > > XPXX 1A1 B R/O 20 3390 4096 366 > 1358-38 > 2242 3600 > > > > flist * * b > > gets this on the first line: > > LVL 0 - B 1A1 3600 BLKS 3390 R/O 38% > FILE 1 > OF 366 > > > > But for an accessed directory: > > q accessed w > > MODE STAT FILES VDEV LABEL/DIRECTORY > > W/A R/O 338 DIR XPOOL:77731619. > > > > flist * * w > > gets this: > > LVL0 XPOOL:77731619. > > > > Is this documented? a bug? > > It works as coded. :-) I looked at the code and it > very specifically > bypasses the header build procedure for SFS > directories. There is nothing > in the HELP about this exception. > > The code was most recently touched by the Y2K > updates in 1998 with APAR > VM61389. Oddly enough, that APAR was only supposed > to cause FLIST to > display dates according to your virtual machine's > DATEFORMAT setting. > There seems to be support in there for a 2-line > header to be dynamically > built if needed, apparently to accomodate long > directory names, so I don't > know what the issue might be. > > Colleen could give a better answer, but I would have > my bug spray at the > ready... > > Alan Altmark > z/VM Development > IBM Endicott