Re: Externalize DB/IO (was What Counts as Technically Slick?) -- MIDRANGE-L

John


> Don't rely upon direct parameter passing, or module import/export variables
> between the client and the DB server. Encapsulate the parameters in a data
> structure that can be passed as a single parameter, or shuttled across via
> data queues, user spaces etc.
>
> To begin with, you need to establish a common naming system for all data
> attributes within your system. So you'd have attributes like:
>
> Product_ID
> Product_Desc
> Product_Status
>
> The server and all clients must use this naming system to refer to the
> attributes - no exceptions.
>
> Next, setup a standard data structure that will encapsulate each attribute
> in a common way. Think of this data structure as a composite variable - the
> API Error Structure is similar to what I'm talking about. Example:
>
> AttributeStruct:
>   AttributeID="Product_Code"
>   AttributeValue="ABC123"
>   AttributeSeq="1"
>   AttributeErrID=""
>   AttributeErrText=""
>
> The client is responsible for setting the attribute sequence value before
> passing the attribute to the server. If the server encounters an error, it
> sets the AttributeErrID and associated text accordingly. In this model,
> where each attribute structure provides a vehicle for it's own message
> passing, the server would ignore the AttributeSeq value - it would only be
> used by the client.
>
> However, another valid model would be to take the message passing out of
> each individual attribute, and add it as a standard attribute itself. In
> that case, the server would generate and pass all error messages as a single
> attribute that contained deliminated error messages. As part of this
> packaging process, the server would use the AttributeSeq value to determine
> what order the error messages should be placed in.

The above roughly describes the way I use and it has stood me in good stead 
since
System/38 days.

Scott quite correctly stated that having an additional service program for each
function for each file was not a good idea.  You need to think at a much higher
level.  But the original poster of this thread used the phrase "db server" - in
other words one server program provides the necessary functionality for multiple
files.  Because retrieving messages on the System /38 with CPF version 1 was 
very
slow, I even created my own message PF which is also handled by the "server"
program.  If I need a new message, the server program adds it to my message 
file,
allocating the next message number.  If an error occurs in operations on a db
file, the server will retrieve the appropriate message before returning to the
client.  If the client finds, perhaps in validation, a problem that requires a
message to be retrieved from the message file, it passes the message number to
the server program which passes back the message text.  If the operator presses
F2 over the message, the server will pass back second level text from the 
message
file, etc..  The files are user opened the first time that an operation on them
is requested by the client.  The code for commitment control is the same for 
each
file.  The client, driven by the database which the server has retrieved, tells
the server when to start/end commitment control.  However many files are 
defined,
the same piece of code is used for all files for commitment control and for roll
back if an error occurs.

When the client wants a record from the database, it passes the file name, key,
and action (i.e. read, add, etc.,) using a large data structure.  This parameter
also has the data retrieved (or to be added/changed), message id and text and
much much more.  If I need an extra file, I only have to define it and duplicate
a routine for actually accessing a file and change the file and record names in
the new routine.  The server does not need to understand the layout of a record.
It just passes back the data it retrieves to the client as one lump.  I also
define the record layout in the database - i.e. it defines its own layout.  The
data from all files is passed in the same parameter which is therefore long
enough to accomodate the longest record.

It might not be every one's way of doing it but it requires virtually no
maintenance and has excellent performance.

When I need to add a new UI, e.g. HTML. there is no file I/O code cluttering up
the client program which makes the change much simpler.  I use minimal DDS and
generally put out my own 5250 attributes, or PCL or HTML.  The routine for
putting the attributes into my datastream starts by deciding whether it needs to
put in 5250, or PCL or HTML and puts in the appropriate codes in the datastream
in between the bits of data.  This (oversimplifying it) puts out just one field
which is the data stream.  Even subfiles are built this way.  I only use one
display file and one printer file.  I started adding XML and it was very simple,
but I did not finish this as I could see no use for XML.  The method could
certainly handle a whole variety of interfaces, e.g. WAP, etc..  It could also 
be
used to operate directly on the IFS.



>
> The attribute sequence, of course, has a direct relationship to the order of
> fields on the display file, HTML page etc. The client uses the value to
> arrange the error messages and for cursor control.
>
> If you want to be really hip about it, package this all up using XML.
>
> Regards,
>
> John Taylor
> Canada
>
> ----- Original Message -----
> From: "Douglas Handy" <dhandy1@bellsouth.net>
> To: <MIDRANGE-L@midrange.com>
> Sent: Tuesday, April 10, 2001 10:39
> 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
> +---

--
Best wishes

Rob
________________________________________________________

Erros plc

44 (0) 1844 239 339

http://www.erros.co.uk - The AS/400 Neural Database for the Internet

_________________________________________________________


+---
| 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
+---