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

We've used Lawson on the AS/400 for a few years, and now we're migrating to
Unix/Oracle.  Most of our users were using the client server interface.
Lawson uses standard i/o routines as well as a technique for insulating
application programming from presentation.  From the presentation side
things were pretty slick.  The same application programs would pass data
back to a presentation manager on 5250 formatted as text and enabling
function keys, or to the GUI client formatted as fields, drop downs, and
buttons.  Their first forays into web-enabling used the same techniques.  I
understand that they've had to refine their substantially complex
environment layer as they've moved to release 7.x and 8.x.  All the work
they've done on the environment layer makes me wonder if they've really
reaped the benefits of modularity.  Also, since application logic is modular
it has to be written for the least common denominator.  Since the same
application is implemented across 5250, Telnet, proprietary client, and
browser it doesn't really use all the functional advantages of the PC or
graphical client.

Initially I hated the very idea of their i/o routines, but that was mostly
due to my traditional AS/400 programming bias.  Supposedly their stuff is
developed through proprietary code generators, which take advantage of the
modular i/o logic.  We have their development tool for the Unix systems and
it's pretty good at whipping up simple program functionality.  Adopting
standard techniques for i/o and application logic requires you to trade off
modularity and fast development for limited functionality.  Here and there
you can run across a specific program that doesn't work very well within the
constraints of the Lawson standard.

Lawson's code doesn't port very well from their more popular platforms to
the AS/400, so you have to ask "What's the benefit?"  They seem to be able
to exploit modular design techniques between Unix and NT on various
databases, but the fact that they're so far behind on AS/400 releases
suggests that they have to do many things over on the AS/400.  Even on the
presentation side they're supporting marginally different versions of the
same PC client for Unix and AS/400 servers.

A fun side effect of their modular database techniques is seeing the horror
in an Oracle DBA's eyes when he or she realizes how this product is
accessing the database.  Lawson does not use standard SQL calls within their
programs.  They've written i/o interfaces to provide modularity between
Oracle, Informix, SQL Server, Solaris, based on their original proprietary
database, LADB.  Every program behaves as though it is accessing LADB.

-----Original Message-----
From: rob@dekko.com [mailto: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
+---