RE: Free format sql, was: Nice trick for easy viewing free-form RPG and embedded SQL

I'm Rob, not Ron.  Basically I am not a big fan of externalizing I/O 
because it's been my impression that a bulk of the people who are enthused 
about it are the ones who write the external I/O routines.  Not the 
consumers of the routines.

I'd rather write a program that does something like
FMyFile....
 /free
  read(e) MyFile;
  Dow %status(MyFile)=ReadOk;
    // process the data
    read(e) MyFile;
  EndDo;
  Select;
  When %status(MyFile)=EOF;
    // Ok, don't worry about this one
  Other;
    // Oh darn!!!
    ...
  EndSl;

Than a program that does something like
/free
Select;
  When OpenInventoryData()=Cool;
    Select;
    When GetInventoryData(Key1: Key2...)=Cool;
      MyField1=GetBalance();
      MyField2=GetWarehouse();
...
Some externalizing gurus might say you wouldn't have a GetInventoryData. 
Instead the keys would be on the GetBalance, etc.  Then what, does it read 
a record for each field requested?  I'm not expecting an answer.  It's 
just a sample of how externalizing may raise more questions than it 
solves.

Oh, there's the popular myth that if I change a file structure then I do 
not need to worry about it if I've externalized.  My counter is that a 
popular package changed the size of their key field and all the rest of 
their fields.  So if I have a program
D MyItem         s            15a
D ItemDesc       s            30a
I still have issues.  Now, if I've LIKEd these fields off of an external 
data structure I'm better off.  I still have to compile though.  (And 
maybe redesign any 5250 screens to change the layout, etc).  Then again, 
isn't using an external method supposed to hide from your developers what 
the name of the actual physical file is?  If so, how would they know 
file(s) to use in the data structure(s)?

Rob Berendt