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 Altmark/Endicott/i...@ibmus Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 08/18/2009 10:46 AM Please respond to The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: FLIST on SFS, *HEADER ignored 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
