|
From Al Macintyre > From: Art@link400.com (Art Tostaine, Jr.) > > I have a new customer who we are developing an AS/400 application for. > He has grand plans for a web site that will interact with the data on the 400. > He is not automatically considering serving the web pages from the 400. > He has considered buying another AS/400 to serve the pages using > WebSphere Commerce Suite, but that is not definite. Something to consider here is that different models of AS/400 are optimized for different types of operations. If your customer has an extensive ERP or other business operations package, then how that package is designed will dictate the model of AS/400 that is best for the performance & security & user friendliness & so forth for that package. Many packages have not kept up with security needs, so they in esssence force the AS/400 security to be at such a low level that it would be criminally negligent to connect it directly to the internet. Thus it makes sense to have one high security AS/400 model optimized for internet access & a separate AS/400 model optimized for core business operations. Security on AS/400 is not a hardware issue but owner decision settings, which are often dictated to some degree by combination of software aquired & corporate culture. > Since I am the developer for the AS/400 application, I have to answer > questions from web companies who are trying to make proposals to my customer. > One of the questions that I can't answer so well is how will the web > developers get data from the AS/400. Some know of the 400, others don't. > Most know it runs DB/2. This sounds like you are not an experienced developer for this area. Are you planning on writing custom code or connecting a bunch of established packages? Have you discussed with the customer the trade-offs between custom code & standard packages? There are plenty of developers who are experienced in both the 400 & web applications. Why are you & your customer hiring those that are not specialists in the work to be done? > The web developers have to be able to enter data into our system. > For instance, they will do all of the programming to accept an order, > then they will have to create an order and pick ticket on my system. Is your customer not already in business with a system to process orders? One of the activities that brought down many of the initial dot coms was that they thought in internet terms "If we can accept customer orders, we will make oodles of money" when the reality was that to stay in business you have to be able to process those orders & get the right merchandise delivered on time. You need to analyse what software system your customer is now using to process orders & see what hooks it has that make web connections practical, which means that you need software specialists in that system, including a business analyst. Some software systems were not designed with e-commerce in mind & the challenge then becomes does the company want to convert to a package that is e-commerce friendly, or invest in the best that is available with that package. You will need to sign up for whatever internet list is associated with users of whatever package that is. > They will have to receive an order# back from the 400. > They will also have to get data from the 400 to show order status, etc. > How should I tell them to connect? There are a large number of software tools for communicating between 400 & web site ... you need to research pros & cons of them to select which one makes sense for your customer. I have been to several seminars extolling various products & for the applications we are in, I thought the best of breed was Seagull & Lansa, but our web meister instead decided the solution was for him to learn some new programming languages that do queries of 400 data & then send that data to the web site through security windows arranged with the ISP. His main problem so far has been his unfamiliarity with where we keep some data in which fields of which files & who is the right person (me) to ask about that. I recently updated a bunch of BPCS literals (message member files used to label data base fields) so as to simplify his task. > I'm aware of the Asna product. > The app that we are writing is written using Lansa. One of the web > companies bidding is using the Lansa product, so there are no problems. > I'm interested in options that are more "standard". > These web guys are talking about using things > such as Cold Fusion, etc. A big problem for you is that there is no such thing as a "standard" since the computer scene changes so rapidly. What you should be looking at is stuff that IBM is committed to support for some time to come & stuff that works well with Lansa. Have you taken your customer to the Lansa web site which has connections to many other customers using web sites connected to Lansa http://www.lansa.com (check Spotlight) so that you start with stuff that works especially well, instead of buying into stuff that might not. > Art Tostaine, Jr. > CCA, Inc. > Jackson, NJ 08527 You might also want to check the archives of the eCommerce Discussion List http://www.year2000.com/ecommerce Al Macintyre ©¿© MIS Manager Green Screen Programmer & Computer Janitor of BPCS 405 CD Rel-02 running on AS/400 V4R3 http://www.cen-elec.com Central Industries of Indiana--->Quality manufacturer of wire harnesses and electrical sub-assemblies +--- | 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 mailing list archive is Copyright 1997-2025 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.