Re: Interactive logic-style question

On 4/21/2015 11:07 AM, Bob Cagle wrote:

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?

Errrr, maybe? Certainly one reason to utilise a service program is code
reuse, but that's not the only reason. The service program offers us a
level of abstraction that's difficult to achieve in monolithic code.

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

The encapsulation that works for database I/O also works for display
I/O. Imagine some future where you want to have the same business logic
in the RPG program interact with
a) 5250 display
b) Spreadsheet
c) Browser

If the I/O is encapsulated, it's easier to swap out the I/O without
having to deeply rework the logic. That's the general idea, anyway.
Service programs also offer security, error handling, and auditing
functions that are harder to do with in-line code.

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

US EBCDIC handles them just fine, but few other national character sets
do. It's all great when you're a US-only company, but when you're
bought out by a Canadian or Italian company (Chrysler!) and need to
start trading code and data with them, things get messy.