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

I agree with John.  The biggest problem that I've run into is changing parm
lists for subprocedures.  Now, after getting into Java and OO, this makes
more sense to do, and I'm not sure why I didn't do it in the first place.
It does make sense.  I'd option to simply pass a pointer to a DS as the only
parm.  

Its how we've done standard calls for a while, using external DS's.  We just
have to make sure the DS on each end matches up.  

Brad

> -----Original Message-----
> From: John Taylor [mailto:john.taylor@telusplanet.net]
> Sent: Tuesday, April 10, 2001 1:34 PM
> To: MIDRANGE-L@midrange.com
> Subject: Re: Externalize DB/IO (was What Counts as Technically Slick?)
> 
> 
> My .02
> 
> 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 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
> +---
> 
+---
| 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
+---