Announcement Announcement Module
Collapse
No announcement yet.
As400 / Internet - Setup from scratch Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • As400 / Internet - Setup from scratch

    On Wednesday, February 17, 1999, 02:42 AM, Neil Holley-Williams wrote: We have a legacy RPGIII/RPG400 (some COBOL) application running on AS400 which we would like to make available thru' the Internet. We have not tried this before, and don't know where to start What are the steps we need to examine/plan for to enable us to do this from scratch ?
    There are at least 50 correct answers to your question. The easiest IMO is to use the 5250 gateway provided free with all releases starting with V3. The 5250 gateway translates the 5250 datastream into HTML. This allows you to put your apps on the web without any reprogramming. The problem with 5250 gateway is that it is ergonomically challanged. Generally the screens look pretty bad. Substitutions from third parties are available: Webulator, Jacada, and others. The Java based products do a sensational job. David Abramowitz

  • #2
    As400 / Internet - Setup from scratch

    check out milleraviation.com
    ......
     

    Bob Hamilton TEXAS BUSINESS SYSTEMS 736 Pinehurst Richardson, Texas 75080

    Comment


    • #3
      As400 / Internet - Setup from scratch

      On Wednesday, February 17, 1999, 02:42 AM, Neil Holley-Williams wrote: We have a legacy RPGIII/RPG400 (some COBOL) application running on AS400 which we would like to make available thru' the Internet. We have not tried this before, and don't know where to start What are the steps we need to examine/plan for to enable us to do this from scratch ?
      A question near and dear to my heart, Neil. To my way of thinking, there are four basic strategies:
      1. Use a 5250 gateway product (also known as a screen-scraper). As David suggested, there are several out there.
        • Advantages: No modification of the existing application. No additional client-side software.
        • Disadvantages: Cheap ones are ugly. You are stuck with your gateway vendor's UI standards. Your users are still locked into the monolithic paradigm (the server decides which panel will display next, not the user).
      [*]Modify your programs to output HTML code.
        [*]Advantages: You have control over the output. No additional client-side software. Modifications to the programs require little or no application knowledge.[*]Disadvantages: You lose the old 5250 functionality. All programs are modified. Your RPG programmers have to learn HTML.[/list][*]Split your user interface from your business process, connecting them via data queues.
          [*]Advantages: You have control over the output. You can have both 5250 clients and HTML clients talking to the same server program. Modifications to the programs require little or no application knowledge. Your HTML programmers don't need to know RPG, and vice versa.[*]Disadvantages: All programs are modified. You need to develop the data queue middleware. Clients need simple application software (not as thin a client).[/list][*]Re-engineer your application to true client/server.
            [*]Advantages: This is the first step towards O-O. You can begin to develop reusable servers. Client applications can call the business functions they want when they want to, not when the server dictates it. You can use multi-threaded designs. Servers can supply data for other client applications.[*]Disadvantages: Requires re-engineering of every application. Any program that does screen I/O must be redesigned for client/server, which requires application knowledge. Clients need application software of light-to-moderate complexity (medium-weight client).[/list][/list]There are lots of options. I'm currently researching what it takes to do the fourth option, and it's not an insignificant amount of work. On the other hand, if you plan on moving to object oriented software, option four is the first step in that direction. Option 1 is probably the best if you simply want to replace green screens with web access. Hope this helps. Joe href="//www.zappie.net">www.zappie.net, a site with potential (and a great personality)

      Comment


      • #4
        As400 / Internet - Setup from scratch

        What a great response Joe Pluta generated. I'd like to elabourate a little bit on item two of Joe's response: "Modify your programs to output HTML code." This means Common Gateway Interface (CGI) programming. I think this is a viable strategy although it is more work than simply enabling 5250 Web access. Conversion of RPG programs to CGI has been well covered in MC's AS/400 NetJava Expert" Midrange Computing will also have an article on CGI programming in the April, 99 issue. To use CGI you will need to install the AS/400's free HTTP Web server and then configure it to enable CGI access. IBM also has an AS/400 library of CGI utilities in the form of ILE RPG *MODULES and *SRVPGMs as well as the source for those modules. That library is called CGIDEVD. I covered the use of the CGIDEVD library in detail in the Aug/Sept 1998 Issue of MC's AS/400 NetJava Expert. The URL for the CGIDEVD library is:http://www.as400.ibm.com/tstudio/wor...arch.mbr/input Also check out www.ibmuser.com:8000/ers/Edward R. Smith developed this AS/400-powered site to provide examples of Internet applications that take advantage of the technologies that are available on the AS/400. Several of the examples because they were published in AS/400 NetJava Expert. There are several RPG CGI examples on Edward's site.

        Comment


        • #5
          As400 / Internet - Setup from scratch

          I happen to know that Brad's CGI article is a great one,since I just finished editing it. Sorry, but it won't be published till April. Brad, the reason why the AS/400 wants you to place all of your CGI programs in one library is for security reasons. I suspect that that is also that same reason for not using initial library lists and such. You could, though, map explicit programs with the EXEC directive that exist in other libraries. I don't believe the AS/400 limits you to one library IBM just suggests that you use one for security measures. The following exec is considered standard. It is used to mask or hide the real name of the AS/400 library and also to follow the industry standard of cgi-bin and the CGI library/directory. Exec /CGI-BIN/* /QSYS.LIB/CGILIB.LIB/* I'm pretty sure that you could use: Exec /CGI-BIN/Whatever/* /QSYS.LIB/OtherLib.LIB/* or even Exec /As400CgiLib/* /QSYS.LIB/OtherLib.LIB/* I don't think there is anyhing magic about the string "cgi-bin." The URL just specifies www.yourDomain.com/As400CgiLib/somepgm rather than the standard: www.yourDomain.com/cgi-bin/somepgm. Realize that it is easy for a user to capture your HTML file and modify the URL tag to the CGI program. If multiply libraries are used for CGI programs then its all too easy for a hacker to modify the HTML to call whatever programs they want. By keeping all the CGI programs in one library it is easier to manage security. Let me know if you play with this other library qualification with Exec as I haven't had the chance to play with it.

          Comment


          • #6
            As400 / Internet - Setup from scratch

            Don, You also answered a question I had for a long time that will also change the way this is looked at. The question I had was if you make more that one HTTP config file, how do you point a browswer to use that specific config file? The answer, as pointed out by Don, is that the port number specifies this. So, I am guessing that if you wanted to split up your CGI programs into different libraries, this could be done with seperate HTTP config files where the MAP and EXEC directives differ. In some of my programs, I sucessfully used my library list functions that were published in the February issue to get around this. In the end, though, I ended up using DDM files and simply placing those DDM files in the CGI directory. This is because it was faster to use our box and DDM files that to actually use the box the data resided on alone. I can't remember the models of the two, but one is slow and one is very fast. HREF="http://prairie.lakes.com/~bvstone/"> SRC="http://prairie.lakes.com/~bvstone/images/sig.gif">

            Comment


            • #7
              As400 / Internet - Setup from scratch

              Yes, you can do that. One method is to use Sockets programming to send an HTTP request header along with an HTML tag that invokes the NT CGI program. Midrange Computing's February 1999 magazine feature an RPG sockets programming article by Jim Barnes titled "TCP/IP Sockets Programming in RPG? Cool?" I would rather suggest, however, so you don't have to be concerned about the HTTP protocol or Sockets programming, that you use Java. No, don't go away, this would be a trivial program to code in Java - far simpler than the RPG/Sockets version. You see Java has a class called HttpURLConnection. To use it you simple say:
              import java.net.*;import java.io.*;import java.util.Date; public class InvokeNTURL{ InvokeNTURL (String url) { URL ntURL = null; try { ntURL = new URL(url); } catch (MalformedURLException error) { System.out.println("URL error: " + error); } try { URLConnection ntConnect = ntURL.openConnection(); ntConnect.connect(); System.out.println(" Type: " + ntConnect.getContentType()); HttpURLConnection ntHTTP = (HttpURLConnection) ntConnect; System.out.println(" Request Method: " + ntHTTP.getRequestMethod()); System.out.println(" Response Code: " + ntHTTP.getResponseCode()); } catch (IOException error) { System.out.println("IOException error: " + error); } } public static void main(String pList) { new InvokeNTURL("http://YourNTDomainName/cgi-bin/ntCGIprogram"); }}
              If the Response Code is "200" then the URL was accessed and your CGI program was invoked. You can use other functions/methods of HttpURLConnection to see the contents of the returns HTML for your NT HTTP server. Now, as to the RPG code, it would be far more complex and I'm not about to code it for you. This is one case where Java is clearly better than RPG. This Java class works; it is not a sample or a snippet -- I have tested it with an MC AS/400 CGI program. You should modify the main function so that the InvokeNTURL does not take a hard coded URL but rather pList0 which is element one of the program's parameter. To execute this from your AS/400 simply.... Tell you what, if you like this, insert another forum message and I'll send you the compiled version of this class and give you the AS/400 installation instructions. That is if Joe Pluta doesn't get to you first.

              Comment


              • #8
                As400 / Internet - Setup from scratch

                Try using the BINARY ftp command before sending the file. Without that FTP may be trying to convert the tab to some ASCII or EBCDIC printable character.

                Comment


                • #9
                  As400 / Internet - Setup from scratch

                  On Tuesday, February 23, 1999, 07:36 AM, Don Denoncourt wrote: Tell you what, if you like this, insert another forum message and I'll send you the compiled version of this class and give you the AS/400 installation instructions. That is if Joe Pluta doesn't get to you first.
                  chuckle No, no, you can handle the Web Server stuff, Don. I haven't gotten a chance to do much AS/400 HTTP yet. I'm busy trying to put together the basic examples for Jo Ann. Joe

                  Comment


                  • #10
                    As400 / Internet - Setup from scratch

                    Yes, IBM's AS/400's HTTP server supports SSIs. To set it up you, first need to specify the AddType directive in your HTTP configuration file. Use the Work HTTP Configuration (WRKHTTPCFG) command:
                    AddType .shtml text/x-ssi-html 8 bit 1.0 
                    Then, you also need to add the imbeds on directive to the configuration file:
                    imbeds on 
                    In a simple test for SSIs, I used the test.shtml file (Figure 1) and a second file called ssitest.html figure 1: <HTML><HEAD>< TITLE>AS/400 HTTP SSI Test</TITLE></HEAD> <Center><H2>AS/400 HTTP Server SSI Test</H2></CENTER> <!--#echo var="LAST_MODIFIED" --> <!--#include file="ssiTest.html" --> <p>This is a part of test.shtml</p> </BODY> </HTML&GT figure 2:<HTML><HEAD><xTITLE>SSI Test</TITLE></HEAD> <Center><H2>SSI Test</H2></CENTER> <p>This is a part of ssiTest.html</p> </BODY> </HTML> Figure 3 shows the text of the resulting page that would be shown in a Web browser
                    AS/400 HTTP Server SSI Test Wed, 27 Jan 1999 18:38:33 SSI Test This is a part of ssiTest.html This is a part of test.shtml

                    Comment


                    • #11
                      As400 / Internet - Setup from scratch

                      The product developers for IBM's HTTP server have finally told me that the user profile specification in the config file does not mean that ALL of the user profile information is used. JOBD is, in fact, ignored by design. This left me with my original problem, but I have since found a suitable workaround. Here is the short version: === What I needed: === * Each server instance to map to a specific library list based on input from the user at the browser (User ID and Password) so that CGI calls would use the proper objects. === What the problem was: === * The HTTP server seems to want CGI apps to reside in a single library. Great for security. Bad for flexibility. === How I solved my problem: === * Created a central "Gateway" program that redirects the user's browser to a specific HTTP instance (differentiated by port #) based on input from the user. The gateway program also sets the library list to what is needed (again based on info from the user) by making calls to the QLICHGLL API. It is necessary to have a unique server instance for each different library because I leave my programs and data paths open- and once they are opened, they are kinda locked in. Anyway, this works very well (and fast.) All CGI calls are funneled through the "Gateway" program and only it is setup for CGI usage. This provides good security. I can post some specifics if anyone needs them.

                      Comment


                      • #12
                        As400 / Internet - Setup from scratch

                        john... I would be curious to hear what method you used to redirect browsers to another URL. This is per the discussion on MC's forum. I have only been able to find one way to do it using META code. Is there a better way? My problem arose from not being able to print a page that was created from a POST operation. So, instead, when the user would hit the 'submit' button on the page, it would send them to a "temp" page where the META code would be built on the fly and automatically redirect them, placing the standard input variables in the query string. Seems like a lot of work for a simple problem. thanks! Bradley V. Stone IT Project Leader Precision Press ================================================== Hi Bradley, I use a directive in the response header. My program returns this: "location:/otherfile.htm". This is how the program redirects to another page. It could just as easily be any other URL such as yet another CGI call. If you use this, be SURE to put at least two carriage returns after the last character in your URL, or else it won't work and you'll be left wondering why. I'll try to find where this is documented and send you the reference. Regards, John Richardson

                        Comment

                        Working...
                        X