RE: Interactive logic-style question

[Bob Cagle <bcagle@xxxxxxxxxxx>]

Jon, I did think of moving the check for initialize last, but I don't think it's as easy to read.   Moving it to before the loop is an easy enough change though; makes sense.

Nathan:  Not sure I understand the *SRVPGM suggestion for screen I/O.  I agree with Chris, wouldn't that be overkill for just one screen?  The idea of a service program is for it to be used in multiple places, why would I create a service program that's specific to this one display file that I'm only ever going to use from this specific controller?

Note: I do understand the thinking behind a service program for the database: encapsulating business logic, etc.

(p.s. It's a whole other discussion, but I don't understand why some people are so opposed to using special characters (@, #, $) in variable names?)

Thanks

Bob Cagle
IT Manager
Lynk, Inc.

-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Jon Paris
Sent: Tuesday, April 21, 2015 7:46 AM
To: Rpg400 Rpg400-L
Subject: Re: Interactive logic-style question

The only thing I would add to Nathan's approach (and I would have said the same thing about your original RPG III version) is that if performance is an issue then always test the initialize last. 

Personally I would also have called the init routine before I began the loop and have it set the first action.  


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Apr 20, 2015, at 8:27 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

> Bob,
>
> As far as style is concerned, my only objection would be the use of 
> the # character as a variable prefix. But I understand that each shop 
> has their own naming conventions, and I don't expect others to have the same as mine.
>
> As far as structure is concerned, it's well formed; much better than a 
> lot of alternatives.
>
> Regarding performance, we're talking very few microseconds to evaluate 
> a "when" condition. Contrast that with most web application 
> environments which "route" browser requests to appropriate "servers", 
> whether they be Java servlets, or scripts running under interpreted 
> environments, you will find a comparatively HUGE amount of overhead in the latter.
>
> Your structure for dispatching requests based on #WrkMode could be 
> viewed as the "controller", following a Model/View/Controller design 
> pattern. Bind your controller to a *SRVPGM which implements procedures 
> to handle screen I/O, then bind that *SRVPGM to another *SRVPGM which 
> implements database I/O. Now you have an application that implements a 
> very maintainable MVC design pattern.
>
> Nathan.