Re[4]: "extract" command enhancement

     I understand the SET* function approach, it's just not as cool as the 
     left-hand-side syntax!
     
     The problem with the operational descriptors is a really painful one.  
     It would be way cool to have set/get routines to which a date, time or 
     timestamp could be passed, and have the routines figure out how to 
     handle them.  Hans, any chance of useful operational descriptors any 
     time soon?
     
     I'm not sure I agree with you on returning success/failure codes; that 
     way lies the Windows API.  I am a big fan of structured exception 
     handling in other languages, although I haven't quite got my head 
     around condition handling in ILE yet.
     
     ____________
     Paul Cunnane
     The Learning Company
     


______________________________ Reply Separator _________________________________
Subject: Re: Re[2]: "extract" command enhancement
Author:  dhandy@isgroup.net (Douglas Handy) at InterNet
Date:    21-09-99 12:11 pm


Paul,
     
>     I don't think there's a way to code a procedure that will allow 
>     functionality like...
>     
>          EVAL %subdtz(DateField:*M) = 12 
>     
>     ...or is there?  If so, I want to know about it!!
     
You can come close enough.  Just code procedures like
     
  SetMonth( DateField: Month )  
     
or whatever.  Its arguably not quite the same as being able to write 
left-hand side expressions, but it gets the job done. 
     
A full set of GetXXX and SetXXX functions would not take much time to 
code in a service program.  And as Hans points out, then you can use 
it immediately, even if you are supporting V3R2 code, as I do. :(
     
I still wouldn't mind if the BIFs get added, because I think Hans & Co 
could add all of them in pretty short order without using up too much 
of a $100 upgrade budget.  But I won't wait around for them.  This 
stuff is too easy to add ourselves.
     
The only problem with doing your own SetXXX procedures for d/t/z parts 
is you must know the field format.  This is because you can't use VALUE 
or CONST on the d/t/z field since you need to pass it by reference.  
The BIFs would not have this limitation since it can determine the 
field format at compile time.  (Too bad Rochester can't give us 
operational descriptors on anything but character fields!)
     
In general, I like to code SetXXX() type procedures to return a 
success/fail return code.  Then in the procedure you can do a TestD to 
make sure the format is OK, and validate the range of what you are 
trying to set.  Then you can use the subprocedure in an expression to 
condition code when it fails instead of blindly using CallP and assuming 
it worked.
     
Doug
+---
| 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
+---