-v processing

Bruce Easton bruce at stn.com
Wed Jun 10 11:06:36 PDT 2009


Dennis Malen wrote Tuesday, June 09, 2009 11:25 PM:
> 
> The following now works:
> 
> 14  -------- - - - - - - -
> nextsel~ If: ww="" and 3 lt dt
>        Then: lookup -  k=dt   i=B -ng
>  15  -------   -   -   -   -   -   -   -   -   -   -   -   -   -
>        ~ If: ww=""    'and 3 lt dt
>        Then: msgbox "See1:"<cn;   goto chckcn
>  16  -------   -   -   -   -   -   -   -   -   -   -   -   -   -
> chckcn2~ If: 3 ge dt and 3 le dy
>        Then: select
> 
>  50  -------   -   -   -   -   -   -   -
> chckcn ~ If:
>        Then: lookup clx  k=8    i=A -nx
>  51  -------   -   -   -   -   -   -   -
>        ~ If:
>        Then: msgbox "See2:"<clx(38)<cn
>  52  -------   -   -   -   -   -   -   -
>        ~ If: clx(38) ne cn
>        Then: msgbox "See3:"<clx(38)<cn;end
>  53  -------   -   -   -   -   -   -   -
>        ~ If:
>        Then: ww(1,*,g)="y";goto chckcn2
> 
> Comments:
> 
> 1. I don't know why I need "and 3 lt dt" on line 14. That is 
> the only way it works.
> 
> 2. Also the menu line for the report does not have to 
> identify "In". Works the same with or without it.
> 
> 3. The concept of what was done above is that we did not 
> allow the program to go to the "select" line until the record 
> was also equal to the value of cn.
> 
> 4. We overlooked the fact that line 15 should not have 
> included "and 3 lt dt".
> 
> 5. I also needed a conditional subroutine that checked for 
> the value of cn before the first record was allowed to go to 
> line 16. After we found the first record that possessed the 
> value of cn, we would then populate the value of ww (line 53) 
> so that the program would not revisit this subroutine.
> 
> Dennis Malen
> 516.479.5912 
> 

Dennis - for your comment #2 above, I think you might 
have just been lucky with how your key field (for your 
lookup dash lookup) coincides with the file's record 
numbers if you see no difference (or maybe you're not 
lucky, but things just appear good).

The lookup dash technique as posted by Nancy at:
http://www.vss3.com/tips/tip_9.htm
(as noted by Walter Vaughn back on Friday),
does specify that the index is to be used on the
command line.  And in doing so, along with the 
appropriate lookup dash(es) used in the program, 
allow the report request to work in a very 
specific way.  Just as important as moving the 
record pointer to a desired spot in the file 
(from its current location) is doing so in a way 
that will not bypass records that should be 
considered. 

Consider the following processing:

  1  -------   -   -   -   -   -   -   -   -   -   -   
         If:

       Then: 'find all recs with fld 1 ge '242'

  2  -------   -   -   -   -   -   -   -   -   -   
         If:

       Then: show "@Reading rec#"<@rn

  3  -------   -   -   -   -   -   -   -   -   -   
         If:

       Then: gg(6,.0,g)="242"

  4  -------   -   -   -   -   -   -   -   -   -   
         If: 1 lt gg

       Then: lookup - k=gg   i=A -ng

  5  -------   -   -   -   -   -   -   -   -   -   
         If:

       Then: select; show "@Value for Rec#"<@rn<"="<1

  6  -------   -   -   -   -   -   -   -   -   -   
         If:

       Then: end

Notice the first show statement.  This shows the order 
of records read/considered prior to the neato 
fancy-nancy-like lookup being executed.

If I run this against the test file below
(see ===test file===), with a command line as such:

/appl/fp/dreport test5 -f test -v testsel -u -y nnn -a
(no index specified and notice that the last 
record in the file is lower than what we are looking for)

then we get:
Reading record 1
Value for Rec# 1 = 642
Reading record 2
Value for Rec# 6 = 410
Reading record 7
Value for Rec# 6 = 410
Reading record 6
Value for Rec# 6 = 410
Reading record 6
Value for Rec# 6 = 410  and then we are caught
in a ppp (perpetual processing problem)

so here we found only two of the three values, 
but then got into an infinite loop (output phase 
still sitting there saying - 'hey - give me somethin'!'

if I change the last data record to be say 242
instead of 20 (see ===test file=== below), 
then running again, I get: 

Reading record 1
Value for Rec# 1 = 642
Reading record 2
Value for Rec# 8 = 242

and the program does terminate normally, but 
what happened to records with values 410 and 500??
Well looks like the combo of moving the pointer 
around and filepro continuing to try to process 
in record-number order cause those records to 
never be read - so no matter what kinds of other 
tests I put in processing, I'd never select them.

So I'm thinking that enough of your file's 
key data is coinciding with their record number 
order to give you the impression that it is 
working OK.   And maybe in this one instance, it
is selecting all the records you think it should, 
but if you deleted some records and added new ones 
with your key field values varying across your 
selection threshold, then I think you'll find 
yourself in one of the two scenarios I described 
above.

Using the technique as it should be, with the 
index on the command line:

/appl/fp/dreport test5 -f test -ia -v testsel -u -y nnn -a

the results are what they should be to grab all values
ge 242:

Reading record 2
Value for Rec# 8 = 242
Reading record 6
Value for Rec# 6 = 410
Reading record 4
Value for Rec# 4 = 500
Reading record 1
Value for Rec# 1 = 642

with normal exit.

===test file==='s data:

     Rec#      Field 1 Value
--------------------------------
          1            642
          2              2
          3             16
          4            500
          5             27
          6            410
          7             29
          8             20 (then changed to 242)
      ***** END OF FILE *****


***ALSO, Dennis, you mention in a subsequent post that, 
"We are in the process of modifying many other formats to take advantage of
-v now that we can implement auto processing."

For those reports, if the typical subset of data needed is 
significantly smaller than the entire file, and can very well 
not be at the end of the file (in the look-dash index order), 
then you should be applying the look - -i[index] -nl 
lookup as well to skip quickly to the end of the file 
(also shown in Nancy's tip).

Bruce

Bruce Easton
STN, Inc.
  


 
 



More information about the Filepro-list mailing list