Re: Intranet Question

Mark,

We built an internet application where (known) clients can order goods.  The
price calculation is rather complex and we did not want to duplicate it.  So
the server application (running on an NT server) writes a record to a
specially designed AS/400 file.  This file contains client-id, item-id,
number ordered, price and discount.  The server application fills client-id,
item-id and number ordered and writes the record.  The trigger program
attached to the file calls the price calculation and fills the price and
discount.  The server application rereads the record and has the price and
discount.  Works great and takes no noticeable time (I saw the programmer
who built the server program enter values in a grid layout and the prices
changed as soon as he changed values).

Calling the trigger is part of writing the record, so if your application
gets to the statement after the write, the trigger has already been called.
So there is no need for a delay.

Joep Beckeringh


----- Oorspronkelijk bericht -----
Van: Allen, Mark <ALLENMA1@mattel.com>
Aan: <MIDRANGE-L@midrange.com>; <RPG400-L@midrange.com>
Verzonden: dinsdag 31 augustus 1999 21:20
Onderwerp: 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
+---