RE: TRYING undestanding new AS Iserv

We have just done this to our General Insurance package. We have layered both the display and data base functions by replacing the device dependant verbs (EXFMT,READ, CHAIN etc.) with functions which perform the requested operation and return buffers, or accept buffers. In fact the request code to the DB interface is the RPG verb! The beauty of this approach is that it doesn't matter where the data comes from, it will be processed by a single set of business rules.

(I recently heard a story of one of our customers who hired the Gen-X websters to build a web quotation. They did it. The web quote was $129.88. When the client accepted the quote, the back-end AS400 invoiced the client for $143!  The AS400 was the correct price (of course!).Layering enables our debugged code of 15 years to not be re-written. For the display function we actually invoke an RPG program either on the same AS400 or another AS400 by using MQ Series to manage the transportation. We can also use MQ Series to transport the same buffers to an NT and we currently are at the prototype stage with a Visual Studio solution for the presentation layer to a Browser. We have also recently developed a way of creating XML structures to form  the screen buffers. It's quite neat and the XML syntax/structure can be used by both the browser and the 5250 display program.

I am now writing a tool to automatically layer our software based on rules established with prototypes.

We have the benefit of having written our system according to strict programming standards. I would hate to try to do this sort of work on some of the spaghetti I've seen in the RPG world. Having strict programming standards allows us to write a tool to convert the programs. Otherwise one is faced with the need to go into hand-to-hand combat.

The beauty of the layering is that the calling program doesn't care where the buffer comes from, be it EDI, on-line, browser interface, card input(!). By the same token, it doesn't care where the data record comes from. It could be the DB on the same AS400, a DB2 db on another AS400, or on an Oracle db on some other box. It's the ultimate in plug and play. This is the only way to keep up with the rapid development of PC tools. Although I must say Interpretive Basic has come a long way in the past 20 years going by how some of the scripting processing works in the web world. We used MQ because its supported on about 35 different platforms and it works a treat. The Red book was all I needed to get the thing going.

The only way to keep up is to be flexible. The only way to be flexible is to hide the specifics in APIs. Yeah sure there's a bit more overhead, but cpu cycles are cheaper than human cycles.

-----Original Message-----
From:   Scott Mildenberger [mailto:Smildenber@Washcorp.com]
Sent:   Thursday, 26 October 2000 4:22
To:     'MIDRANGE-L@midrange.com'
Subject:        RE: TRYING undestanding new AS Iserv

Dan,

Client/Server apps are non-interactive.  I know there are tools that put a
GUI on green screen apps but I don't know for sure if the workload is then
non-interactive, I would assume so but just not certain.  And your right, if
all your interactive apps were converted to be a non-interactive workload
then you can get the same horsepower for less money.  An idea that I have
had in the back of my mind is converting all our green screen apps so that
the presentation layer is removed from the business logic.  The business
logic would run as batch jobs using data queues (or some other mechanism) to
communicate with the programs that just present the data to the user.  The
first step would make all of the presentation layer green screen programs,
the benefit is that the application looks and acts just like it did before
but now most of the processing is done in 'batch jobs' that pass the display
buffer back to the display programs.  At that point, it would be easy to put
a GUI or Web front end on the programs as it would only be presenting the
data to the user.   The back end would still be the same program performing
the business logic.  I have been considering working out the details and
starting to do any new development with this model and then slowly
converting existing apps but just haven't got around to it.

Scott Mildenberger

> -----Original Message-----
> From: D.BALE@handleman.com [SMTP:D.BALE@handleman.com]
> Sent: Wednesday, October 25, 2000 10:37 AM
> To:   MIDRANGE-L@midrange.com
> Subject:      TRYING undestanding new AS Iserv
>
> Regarding "interactive"...
>
> Please educate me (again?) on what does and what does not constitute
> interactive as far as a user using a display/keyboard/mouse (in other
> words,
> *not* what I consider a traditional "batch" job).  I.e., is a
> Client/Server
> app considered to be an interactive task on the AS/400?  Other examples?
> And,
> if I'm on the right path, is there a tool that converts a AS/400 green
> screen
> interactive task to a GUI of some sort and makes it a non-interactive
> task?
>
> *AND*, if I can convert all interactive tasks so that they become
> non-interactive as far as the AS/400 is concerned (can't bring myself to
> call
> it batch), does that happen to translate that I'd be able to get more
> overall
> horsepower for less money, i.e., don't have to buy much interactive CPW?
> (Of
> course, did I just increase my costs on the client side with more required
> hardware and/or software?)
>
> I thought I'd heard all this before, but it was rather moot in my previous
> environments.  Now I'm in a shop that's considering a major upgrade,
> consolidating several AS/400s into one LPAR box.  And so I wondered if
> this
> should be looked at before any decision is made.
>
> Dan Bale
> IT - AS/400
> Handleman Company
> 248-362-4400  Ext. 4952
>
>
+---
| 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
+---