Re: Intranet Question -- RPG400-L

Take your current editing and place it in a new program
(service program modules would be preferrable but not
mandatory). Now your green screen applications can
call this "validation" program. Then use RPG CGI
programs (or Net.Data macros) to handle your web
applications. They can call this same "validation" program.
Your validation code resides in one place, both environments
can use it. Now you don't have any delays or workfiles or
other things to break. CGI programs have gotten a bad
rep that is undeserved. One person can write procedures
to "wrap" the C-API calls to aliviate that complexity. Writing
the other RPG programs becomes very easy.

Joe Teff


----- Original Message -----
From: Allen, Mark <ALLENMA1@Mattel.com>
To: <MIDRANGE-L@midrange.com>; <RPG400-L@midrange.com>
Sent: Tuesday, August 31, 1999 2:20 PM
Subject: Intranet Question


>We are in the process of bringing up our first (for this site) intranet
>application.  We have it getting data from the AS/400 already.  However,
>this application expands on a current green-screen 300 based module.  We
>would like to populate the existing AS/400 database for this module with
the
>data from the intranet application.  There are basically only 2 green
screen
>programs where data can be entered/changed in the existing AS/400 database.
>Would like thoughts/comments/concerns/ideas from anyone who has already
been
>down this road.
>
> These 2 green screen program do "lots" of edit checking/verification
>that we do not want to replicate in the intranet application.  The
direction
>we were thinking of taking was:
>
> 1.  Data is entered in intranet application and a record
>is written to the AS/400 to a new WORK file and waits for a
>pre-set time (say 5 seconds???).
> 2.  A trigger (on ADD record only) is attached to this
>new WORK file.
> 3.  That trigger program does the editing (basically
>takes the existing edit program and instead of screen input, reads
>from file)
> 4.  If edit passes, 400 database is updated, record
>updated in the new WORK file with a status field = GOOD.
>5. If edit fails, no update to 400 database is done, record in new WORK
>file with a status field = BAD and an error desctiption
>field describing what edit failed.
>  6. Intranet application after waiting pre-set time,
>reads the record it wrote to the new WORK file and does the
>following:
>
> A.  If Status is GOOD updates/writes to the intranet
>applications database and deletes the new WORK file record
> B.  If Status is BAD, redisplays intranet screen to
>user with the error description field and deletes the new WORK
>file record
> C.  If Status is blank (meaning 400 has not
>processed) it the intranet application gives message to the user that it
>was unable to update the 400 database at this time, leaving the record in
>the work file, so it can be updated later (haven't
>figured this part out yet, maybe have a program in nightly processing that
>reads thru any records left in the new WORK file with
>status = blank).
>
>
>A couple of reasons we want to keep populating the 400 database.  Other
>facilities access these files and there are a number of 400 based
>reports/queries against this database.
>
>
>Mark Allen
>MIS Manager
>Mattel-Murray
>allenma1@mattel.com
>
>+---
>| This is the RPG/400 Mailing List!
>| To submit a new message, send your mail to RPG400-L@midrange.com.
>| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
>| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner/operator:
david@midrange.com
>+---
>

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