RE: dRE: No Subroutines (was Re: Debugging many subprocedures)

>> John's code snippet is a perfect example of a procedure imitating a
>> subroutine. I personally would never do a validation subroutine as a
>> procedure, there is no advantage. Nothing is declared locally to the
>> procedure, all variables are global to the module.

>How do you separate your business logic from your display logic, then? 
In many cases we have not, yet. We have well over 40 million lines of legacy
code. 

>How to you write your business logic (and by all accounts, validation is 
>business logic!) so that it can be re-used from both your GUI display and 
>your green screen?
We have very little GUI (web) interaction with our business, what
interaction we do have we have built service programs and SQL stored
procedures. Over time we are migrating our lagacy business logic to
subprocedures within service programs.

>> If I have three procedures in a module and they each have to validate
parms,
>> then all of the parms to those procedures have to be global, or I can
pass
>> the parms to the validate procedures, or I can use 3 subroutines within
the
>> scope of the respective procedures to validate its parms locally. So a
>> subroutine becomes sub-sub procedure local to it's parent sub procedure.

>Which fields do you validate in each subprocedure?  How do you determine 
>that?
In a new/redesigned display program the display processing for each screen
is in one procedure. So if I have 3 screens I have, at least, three
procedures. Within each of these there would be a subroutine which would
call other, external, procedures to validate, populate, ect... the fields. 

>Is there a reason you need to validate more than one field, or a set of 
>related fields, in a single subprocedure?

No. In the case of a display all fields on that display would be validated
through external procs where available/approprate.

Duane Christen



NOTICE: This electronic mail transmission may contain confidential
information and is intended only for the person(s) named.  Any use, copying
or disclosure by any other person is strictly prohibited. If you have
received this transmission in error, please notify the sender via e-mail.