× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Re[2]: "extract" command enhancement (subfiles and BIFs)
  • From: Colin Williams <Williamsc@xxxxxxxxxxxxxxxxx>
  • Date: Mon, 27 Sep 1999 10:29:35 +0100

I haven't tried UIM yet, is it difficult to code then?

>>> -----Original Message-----
>>> From: pcunnane@learningco.com [mailto:pcunnane@learningco.com]
>>> Sent: Wednesday, September 22, 1999 2:46 PM
>>> To: RPG400-L
>>> Subject: Re[2]: "extract" command enhancement (subfiles and BIFs)
>>> 
>>> 
>>>      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
>>> +---
>>> 
+---
| 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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.