parsing a response line from sysfiletree - REXX

I am bulding on Steve Swift's solution by parsing for the position of
the file attributes:

Parse value subword(stem.n,1,4) substr(stem.n,pos(subword(stem.n,
4), ,
stem.n)+length(subword(stem.n,4,1))+2) with date time size attrs
filename

In
Message-ID:<9e9f7cb4-4bb7-457c-a026-ee9e7b0f9fa4@c58g2000hsc.googlegroups.com>,
regli <raeegli@gmail.com> wrote:

>I am bulding on Steve Swift's solution by parsing for the position of
>the file attributes:
>
>Parse value subword(stem.n,1,4) substr(stem.n,pos(subword(stem.n,
>4), ,
> stem.n)+length(subword(stem.n,4,1))+2) with date time size attrs
>filename

Since the output of SYSFILETREE seems to be fixed column,
would this be a better solution:

parse var stem.n ymd hms siz att . 38 fnm

Or, bite the bullet and do it in two lines. I would guess it
would still take less processing than multiple SUBWORDs:

parse var stem.n ymd hms siz att fnm
fnm = strip(fnm,"L")

--
Arthur T. - ar23hur "at" intergate "dot" com
Looking for a z/OS (IBM mainframe) systems programmer position

Arthur T. <arthur@munged.invalid> wrote:

> Since the output of SYSFILETREE seems to be fixed column,
> would this be a better solution:
>
> parse var stem.n ymd hms siz att . 38 fnm

You need to adjust the fixed column depending in whether you use the default
date/time format or "T" or "L".

One thing that does seem fixed is the width of the 'size' column. Goodness
only knows what will happen when files get so big that the column isn't wide
enough.


--
Jeremy C B Nicoll - my opinions are my own.

On Jul 6, 2:45 pm, Arthur T. <art...@munged.invalid> wrote:
> Since the output of SYSFILETREE seems to be fixed column,
> would this be a better solution:
>
> parse var stem.n ymd hms siz att . 38 fnm
>

Here is the SysFileTree output of a directory with pretty large files.
NOTE the filesize of big.bin.

----------
2008-07-06 15:39:39 3197704724 A---- D:\VirtualMachines\Virtual PC
\big.bin
2008-02-14 16:07:25 1220875776 A---- D:\VirtualMachines\Virtual PC
\Ubuntu 7.10 LAMP.vhd
2008-01-07 15:13:12 4088370176 A---- D:\VirtualMachines\Virtual PC
\Windows 2000 P1.vhd
2007-12-24 23:04:45 27136 A---- D:\VirtualMachines\Virtual PC
\Windows 2000 P2.doc
2008-07-04 15:37:25 198252032 A---- D:\VirtualMachines\Virtual PC
\Windows 2000 P3.vhd
2008-07-05 20:31:27 3207351296 A---- D:\VirtualMachines\Virtual PC
\Windows 2000 P4.vhd
2008-01-24 20:38:56 802379264 A---- D:\VirtualMachines\Virtual PC
\Windows 2000 P5.vhd
2008-04-14 12:20:20 1156884480 A---- D:\VirtualMachines\Virtual PC
\Windows 2000 P6.vhd


Here is the corresponding directory listing:

Directory of D:\VirtualMachines\Virtual PC

07/06/2008 03:39 PM <DIR> .
07/06/2008 03:39 PM <DIR> ..
07/06/2008 03:39 PM 123,456,789,012 big.bin
02/14/2008 04:07 PM 1,220,875,776 Ubuntu 7.10 LAMP.vhd
01/07/2008 03:13 PM 4,088,370,176 Windows 2000 P1.vhd
12/24/2007 11:04 PM 27,136 Windows 2000 P2.doc
07/04/2008 03:37 PM 4,493,219,328 Windows 2000 P3.vhd
07/05/2008 08:31 PM 3,207,351,296 Windows 2000 P4.vhd
01/24/2008 08:38 PM 5,097,346,560 Windows 2000 P5.vhd
04/14/2008 12:20 PM 5,451,851,776 Windows 2000 P6.vhd

8 File(s) 147,015,831,060 bytes


Clearly, SysFileTree is unable to handle files larger than 100GB. As
you can see, the file "big.bin" is not handled correctly. Therefore,
I expect fixed columns, especially the field size to change SOON and
become variable, or at the very least larger, in order to fix this
bug. Terrabytes are after all nothing special anymore. Using subword
should hopefully keep the code working once the bug is fixed.

On Jul 6, 3:38 pm, Jeremy Nicoll - news posts
<jn.nntp.scrap...@wingsandbeaks.org.uk> wrote:
> Arthur T. <art...@munged.invalid> wrote:
> One thing that does seem fixed is the width of the 'size' column.  Goodness
> only knows what will happen when files get so big that the column isn't wide
> enough.

We were thinking along the same lines.

Jeremy Nicoll - news posts wrote:

> One thing that does seem fixed is the width of the 'size' column. Goodness
> only knows what will happen when files get so big that the column isn't wide
> enough.

Indeed it does shift eventually. I have encountered this at one time.

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/

My last proposal which performs actually quite well. Much better than
the subword solution:

parse var stem.n ymd hms siz att . 1 (att) +(length(att)+2) fnm

Steve Swift wrote:
> Parse value subword(stem.n,1,4) subword(stem.n,5)
> with date time size attrs filename

The trick we discussed here earlier to do it in a single instruction is
to reparse the input up to the first word of the filename. In this
case, we know ATTRS will contain characters that can't occur in any of
the previous words (either a letter or two consecutive hyphens), so we
can streamline the reparsing and skip straight to it:

Parse Var stem.n date time size attrs filename . ,
0 (attrs) (filename) +0 filename

How the performance compares, as always, will depend on the platform.

¬R

Glenn Knickerbocker wrote
> Parse Var stem.n date time size attrs filename . ,
> 0 (attrs) (filename) +0 filename

That does not work correctly if the filename begins with one or more blanks
(which is perfectly valid on a Windows system), viz:

---------------------
/* parstest.rex */

/* "file" has 5 blanks at the start */
file=' abc.xyz'
string='2008-07-02 12:10:00 1000 ADHRS '||file

/* following does not give the right answer */
parse var string date time size attrs filename . ,
0 (attrs) (filename) +0 filename
say 'file: "'filename'"'

/* following works correctly */
parse var string date time size attrs 0 (attrs) +7 filename
say 'file: "'filename'"
---------------------
E:\>parstest
file: "abc.xyz"
file: " abc.xyz"'

-- from CyberSimian in the UK