RE: Externalize DB/IO (was What Counts as Technically Slick?)

It's been a few years but I am pretty sure Lawson is "modularized"?

Seems like MACPAC was too, but I think they did it in subroutines in each
program???

-----Original Message-----
From: owner-midrange-l@midrange.com
[mailto:owner-midrange-l@midrange.com]On Behalf Of rob@dekko.com
Sent: Tuesday, April 10, 2001 1:58 PM
To: MIDRANGE-L@midrange.com
Subject: Re: Externalize DB/IO (was What Counts as Technically Slick?)



Isn't software from Lawson supposed to be completely modularized in this
manner?  The UI programs, be they 5250, browser, C/S, whatever, call
external programs to handle all validation and whatnot?  Is there someone
on the list
1)  Using Lawson,
2)  Not 5250 only
If so, what is your opinion of their modularity?

Rob Berendt

==================
Remember the Cole!



                    booth@martinvt.com
                    Sent by:                   To:
MIDRANGE-L@midrange.com
                    owner-midrange-l@mi        cc:
                    drange.com                 Subject:     Re: Externalize
DB/IO (was What Counts as Technically
                                               Slick?)

                    04/10/01 01:02 PM
                    Please respond to
                    MIDRANGE-L






This is far too simplistic an answer.  If business rules find a validation
error then the information needs to travel to the user interface.  For
real separation we can not accept a solution that requires green-screen
involvement

We know that our end-game involves user interfaces from many platforms and
many methods, including green-screen, browser, Java, Windows, Linux, and
all sorts of appliances yet to be made generally available.   Cell phones
and Palm Pilots are not going to ever handle a 5250 data stream.

We've got to keep looking.  There's an answer somewhere.




_______________________
Booth Martin
Booth@MartinVT.com
http://www.MartinVT.com
_______________________




Douglas Handy <dhandy1@bellsouth.net>
Sent by: owner-midrange-l@midrange.com
04/10/2001 12:39 PM
Please respond to MIDRANGE-L


        To:     MIDRANGE-L@midrange.com
        cc:
        Subject:        Re: Externalize DB/IO (was What Counts as
Technically Slick?)
Nathan,

>To implement multi-field validation, I'd need a broader interface between
>the two modules.

My point exactly.  The sample program was too simplistic to be a real
wrold
example, which makes it useless for comparison purposes (IMHO).

>The dbMsg field
>could have been a multiple occurring data structure to hold the maximum
>number of error messages possible.

I'd rather just send them as messages to the external program message
queue of
the UI program.  That is one of the beauties of the error message subfile.

>It could be supplemented with an array
>of indicators to highlight multiple fields on the screen.

And herein lies the rub, as you are losing some of the separation you are
striving to obtain.  Just how do you propose this array of indicators gets
mapped to the fields?  I'm not saying it can't be done; I just want to see
how
you suggest doing it in a real life setting.  In fact, that is my real
motive
for responding.  I *want* to see how others handle this when separating
the UI
from the business logic and DB I/O.

Actually, I don't even use indicators anymore.  I prefer to use
program-to-system fields to set display attributes, and set the cursor
location
by dynamically retrieving the DSPF format's field locations via APIs at
run
time.  All of that is encapsulated behind service program routines which
make it
a single subprocedure call for me to add a message to the subfile, set the
display attributes, and position the cursor (if it is the first error). No
indicators involved.

I may be able to extend this logic and with proper naming conventions,
accept DB
field names back from the business logic handler then make my other WS
handling
routines deal with it.

I just wanted to know how you handle it, since it appeared to have been
production code rather than something thrown together for the posting.

>Only after testing the concept, and after doing
>some "reuse by copy" for another application, did it grow on me.

Years ago I tried setting up service programs to encapsulate the I/O to
some
commonly used master files.  This was on a CISC system, and before the RPG
IV
redbook.  I got it to work.  When it was all said and done, it didn't seem
like
it had bought me any real, tangible benefits.  Perhaps I just did it
wrong.

Don't get me wrong.  I'm a big fan of service programs and subprocedures
in
general.  At the time I played with externalizing the DB access, the
concept of
using web-facing or whatever technology as an alternative UI was not part
of the
equation.

This alters the balance somewhat, and I can see where externalizing the
I/O is
good positioning.  What I need though are solid examples of how best to
integrate that with existing UIs without going backwards (e.g. losing
cursor
positioning or field highlighting) while keeping it at least as
maintainable --
and preferably better.

Doug
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---




+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---