Re[2]: "extract" command enhancement (subfiles and BIFs)

[pcunnane@xxxxxxxxxxxxxx]

     John,
     
     My own personal problem with subfiles is how difficult it is to code 
     one that encapsulates all the nice list functionality.  For example, 
     if you want "Position to:" functionality, you need SFLPAG=SFLSIZ.  If 
     you want to be able to select multiple records on different pages, and 
     page back and forth at will without losing these selections, you 
     either code SFLSIZ>SFLPAG, or handle it manually.  And don't get me 
     started on reliably positioning the list, and positioning the cursor 
     in the list.
     
     I agree with you that it is cheapest to code the same subfile code 
     every time, but my experience is that this doesn't always provide an 
     optimal solution to the business problem.  It may be just a personal 
     quirk, but I think that the look-and-feel of a program is important - 
     especially if (as in my last job) the programs were for sale.
     
     I've said it before - if UIM were easier to code, it would have 
     answered a lot of my prayers.  It handles all the boring stuff like 
     actually displaying the data and managing user input, leaving the 
     business logic to the programmer.
     
     As to KISS, I wholeheartedly agree, but not at the expense of 
     functionality.
     
     ____________
     Paul Cunnane
     The Learning Company


______________________________ Reply Separator _________________________________
Subject: RE: "extract" command enhancement(subfiles and BIFs)
Author:  John P Carr <jpcarr@tredegar.com> at InterNet
Date:    21-09-99 4:35 pm


     
>Dan:
>I definitely agree with you and Booth about subfiles.  The whole display 
>file sewer is based on memorizing arbitrary arcane reserved words.   Seems 
>like a verb to do something like clear the subfile would make more sense 
>than setting on an indicator and writing to the control record, though.
     
Having watched this thread and numerous others over the years and having 
taught "Subfile techniques"  many times,   I have to wonder if half the 
problem with subfiles is that we
get too fancy too many times.    I might ask;
     
Does your shop have iron clad type standards as to how many lines on a SFL 
page?
Does your shop have iron clad type standards as to Page at a time or not? 
Does your shop have iron clad type standards as to the format names?
Does your shop have iron clad type standards as to the indicators used? 
Does your shop have iron clad type standards about which keywords are used? 
Does your shop have iron clad type standards  etc etc etc etc
     
If the answer is no to these,  then you will have to learn every dialect and 
every keyword of the subfile sublanguage.
     
If you had subfile "Parts"    (Like the above standards)  you would have 
very little choices also.
     
If you use page at a time sometimes,  load all other times,   SFLROL 
sometimes, sometimes not,
Different Format names for each program/department/development team,    If 
which indicators used are up to the programmer to decide each time,   
Well then you may have to learn alot of nuances of subfile design.
     
Personally,   I never think about 99% of the above,  each program looks 
*SAME as the previous one.     Indicators are same everytime, keywords are 
same everytime, format name are same everytime.   
     
Variety may be the spice of life,  but it cost more.
     
Don't crucify me now,  thoses are just my observations.
BTW,  I know how to and have written multiple SFL's on a screen at one time, 
controlling roll keys with them,   and I know alot of obscure SFL facts like 
"If you code an error indicator on the write statement of the SFL data 
format,  it will turn on when the SFLPAG size is reached"     and others(Gee 
that would make a good trivia question),   So my point of view isn't out of 
ignorance of SFL's   it comes from "Business bottomline"  bang for the buck. 
Most of the time the fancy stuff doen't add to the business value it just 
looks fancy.
     
KISS
     
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---