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

> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of rob@xxxxxxxxx
> Sent: Tuesday, July 19, 2005 12:07 PM
> To: RPG programming on the AS400 / iSeries
> Subject: 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 

Sorry about that Rob,  that 'n' is to close to the 'b'.  :-)

> 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;

Here's my take:

  /free
    monitor;
       StartList(Key1:key2);
       dow GetNextRecord();  
          //process data
       enddo;
    on-error *all;
       //oh crap, now what?
    endmon;


> 
> 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.

As I see it, the real decision here is, how to communicate errors?
Here's some ideas:
  
  // option 1
  if GetRecord(key1:key2);  
        myfld1 = GetBalance();
  else
      myfld1 = *ZEROS;
  endif;

  //option 2
  if not GetBalance(myfld1:key1:key2);
      myfld1 = *ZEROS;
  endif;

  //option 3
  monitor;
    myfld1 = GetBalance(key1:key2);
  on-error *ALL;
    if GetException() = RECORD_NOT_FOUND;
        myfld1 = *ZEROS;
    else;
        //oh crap some other exception what do I do?
    endif;
  endmon;

  //option 4, GetBalance returns 0 if record not found.
  myfld1 = GetBalance(key1:key2);

Since myfld1 gets set to *ZEROS if the record is not found in all the above 
options, then it would seem that option4 makes the most sense, particularly if 
all you usually get out of the file is the balance.

It gets harder when setting myfld1 to *ZEROS isn't the right answer.  If the 
record is often not in the file, then the GetRecord() idea might be best.  If 
the record should be there, then maybe having a exception thrown by the I/O 
service program is not a bad idea.  But it would be nicer if RPG's monitor 
worked like CL's MONMSG.

> 
> 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)?
> 

Ah but you wouldn't need to change anything except the service program that 
does I/O if the file I/O was properly externalized.

So the vendor changed some field sizes.  Unless you _need_ to use the larger 
size, all your routines can simply continue to deal with the smaller size.

You wouldn't want to use a file to define an external DS in anything other than 
the I/O service program.

If you really want to get a DS back from the I/O service program, then simply 
define a DS template without reference to the physical file fields in the 
prototype member for the I/O service program.  The DS becomes simply a part of 
the "contract" between the service program and its callers without being tied 
to the actual structure of a given file.  

Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121