× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Intranet Question
  • From: "Stone, Brad V (TC OASIS)" <bvstone@xxxxxxxxxxxxxx>
  • Date: Tue, 31 Aug 1999 17:06:41 -0500

Woah... hold on Mark.

If it's an intranet application, I would seriously look into duplicating the
error checking using Javascript.  I only made it half way through your idea
below and said to myself "I wouldn't want to maintain that!"

Use the strengths of HTML and Javascript for the client, and the AS/400 for
the database.  In the long run, it will be much easier.  If you need some
Javascript examples, let me know.  Javascript is a pretty easy language to
implement.  

Note, this is JavaSCRIPT, not Java.  Purely interpreted scripting language
used to insert in your HTML file.

If you can do as much error checking up front before writing data, then you
will save many headaches.  Trust me, I've had to work on the back end of an
intranet application, which still isn't live.  It is/was not very fun.
There could have been a little more time put into the interactive error
checking of the web page using Javascript instead of the months working out
crap on the back end.  Needless to say  Iwould have loved to have develope a
pure AS/400 application instead of a web/nt/sql to AS/400 system, but that's
the way the ball bounces.

Bradley V. Stone
BVS/Tools
http://www.bvstools.com



> -----Original Message-----
> From: Allen, Mark [mailto:ALLENMA1@Mattel.com]
> Sent: Tuesday, August 31, 1999 2:20 PM
> To:   MIDRANGE-L@midrange.com; 'RPG400-L@midrange.com'
> 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 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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.