Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Determining IP Address

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Determining IP Address

    Pretty much the same. I keep getting sidetracked! Made me wonder about some things though. Why can't you interpret/interrogate the 5250 data stream to revitalize legacy apps? That way you wouldn't need to touch the legacy apps at all. Create a front end to your java app and let it send the required data stream to Java. This may be unworkable, I dunno. Seems like it'd be worth looking into though...

    Comment


    • #17
      Determining IP Address

      Shannon, Sounds like a screen scraper to me. Having tried out some of Joe's ideas it looks to me like "revitalization" is worth while. If you are using DDS for your displays, it seems to me that it would be worth the time to parse the DDS and convert it to a common format that could be extended to take advantage of the "revitalized" interface. I know this would be a lot of work, but overall I bet you would come out ahead. David

      Comment


      • #18
        Determining IP Address

        David, Yah man! It is a screen scraper idea. I was thinking that it might be nice to have a java based screen scaper that could run anywhere. And one which would also be free like Joe P.'s revitalization tools are. That'd let RPG and Cobol shops web enable their apps in a hurry, with no effort on their part except to install the java interface. Of course, the screen scraper vendors such as SeaGull probably wouldn't care to have a free Java screen scraper in the public domain, but there's room for both. Actually, the more I think about this (all of 2 seconds. ha!) the more I think that IBM should provide these tools for free. After all, it's IBM who wants to push everyone to JAVA on the AS/400. Why not provide some tools to allow companies to take baby steps (Baby Steps Bob...), into JAVA by letting them web enable their apps with very little effort? Then provide the tools and pre-written code to help them expand on that and really move towards GUI front ends.

        Comment


        • #19
          Determining IP Address

          There are two problems with a screen scraper: First, where do you put it? That is, where in the stream do you locate the interceptor, and how? For example, if you put it downstream (that is, on the PC side of the emulation) then you won't be able to do the browser interface, and your workstation needs to have 5250 emulation software. And to put it on the AS/400 side, you have to figure out how to intercept the 5250 stream before it gets output to the actual display device, and frankly I have no idea how to do that, or if it can even be done. Second, and perhaps more important, by the time you translate your actual output into a 5250 data stream, you may lose information important to other user interfaces, and you may have to go back to the host to get more. For example, you only get one screen of a subfile at a time; you'd have to make multiple requests to the host to get all the subfile lines. The same is true for a message subfile. There are other issues that make it difficult to interpret what the programmer's intent is when you're on the far end of the 5250 data stream. Anyway, while a screen-scraper might be an answer, it's not the answer I want. I'll let other people do it (and they already have). Revitalization is cheap and easy and works extremely well. src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

          Comment


          • #20
            Determining IP Address

            If you are using DDS for your displays, it seems to me that it would be worth the time to parse the DDS and convert it to a common format that could be extended to take advantage of the "revitalized" interface. I know this would be a lot of work, but overall I bet you would come out ahead. Part of my work over the summer will be to create programs to do that stuff automatically, David. There's no theoretical reason that I couldn't design a program that could read a display file DDS and a corresponding RPG source, and automatically generate the application client, the green-screen UI server and the external data structures needed to communicate between the two. And it wouldn't be a far stretch from that point to generate the Java display file and client classes, either. And even in some cases a skeleton for the thick client or JSP interfaces. THAT'S where the real productivity will come in. We'll see what I have done by, say, Independence Day... hmmm, that's a fitting target date: user interface independence day >chuckle<. src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

            Comment


            • #21
              Determining IP Address

              Can't imagine trying to maintain a 'screen scraper' mess.

              Comment


              • #22
                Determining IP Address

                Well, never having worked with the 5250 data stream APIs, I'll have to take your word on this. Sounded like a great idea to me until you started throwing all those pesky "facts!" into the equation.

                Comment


                • #23
                  Determining IP Address

                  Joe, I kind of figured that you would be pursuing that approach. It seems that ideally you would store the DDS attributes in some sort of repository or common format. XML comes to mind as a potential candidate. The next logical step would be to support bi-directional changes between the DDS and repository. It seems like servlets would be a good architecture to support this type of conversion although I have only done type of thing with RPG. David Morris

                  Comment


                  • #24
                    Determining IP Address

                    I.3 TCP/IP Application Exit Points The following table lists the exit points provided for each TCP/IP application. TCP/IP Application Exit Points +------------------------------------------------------------------------+ TCP/IP Application Exit Point Exit Point Format +-----------------+---------------------------+-------------------------- FTP Client QIBM_QTMF_CLIENT_REQ VLRQ0100(1) (see page I.5.1) +-----------------+---------------------------+-------------------------- FTP Server QIBM_QTMF_SERVER_REQ VLRQ0100(1) (see page I.5.1) +-----------------+---------------------------+-------------------------- FTP Server QIBM_QTMF_SVR_LOGON TCPL0100 (see page I.5.2) +-----------------+---------------------------+-------------------------- REXEC Server QIBM_QTMX_SERVER_REQ VLRQ0100(1) (see page I.5.1) +-----------------+---------------------------+-------------------------- REXEC Server QIBM_QTMF_SVR_LOGON TCPL0100 (see page I.5.2) +-----------------+---------------------------+-------------------------- TFTP Server QIBM_QTOD_SERVER_REQ VLRQ0100(1) (see page I.5.1) +-----------------+---------------------------+-------------------------- Workstation QIBM_QTMT_WSG QAPP0100 (see page gateway (WSG) I.5.3) server +------------------------------------------------------------------------ Note: (1) The same interface format is used for request validation for the FTP client, FTP server, REXEC server, and TFTP server. This allows the use of one exit program for request validation of any combination of these applications. The same interface format is used for server log-on processing for the FTP server and REXEC server applications. This allows the use of one exit program to process log-on requests for both of these applications. +------------------------------------------------------------------------+ I.5.2 TCP/IP Application Server Logon Exit Point Interface Required Parameter Group: +------------------------------------------------------------------------+ 1 Application identifier Input Binary(4) +------+-----------------------------+-----------------+----------------- 2 User identifier Input Char(*) +------+-----------------------------+-----------------+----------------- 3 Length of user identifier Input Binary(4) +------+-----------------------------+-----------------+----------------- 4 Authentication string Input Char(*) +------+-----------------------------+-----------------+----------------- 5 Length of authentication Input Binary(4) string +------+-----------------------------+-----------------+----------------- 6 Client IP address Input Char(*) +------+-----------------------------+-----------------+----------------- 7 Length of client IP address Input Binary(4) +------+-----------------------------+-----------------+----------------- 8 Return code Output Binary(4) +------+-----------------------------+-----------------+----------------- 9 User profile Output Char(10) +------+-----------------------------+-----------------+----------------- 10 Password Output Char(10) +------+-----------------------------+-----------------+----------------- 11 Initial current library Output Char(10) +------------------------------------------------------------------------+ Exit Point Name: QIBM_QTMF_SVR_LOGON Exit Point Name: QIBM_QTMX_SVR_LOGON Exit Point Format Name: TCPL0100 The TCP/IP Application Server Logon Exit Point Interface enables additional control for authenticating users to a TCP/IP application server. This exit point allows access to the server to be based on the address of the originating session. It also enables the initial current library to be set by allowing the current library listed in the user profile to be overridden. When an exit program is added to the exit point, it is called each time a user attempts to log on to the server. The exit program sets the return code output parameter to indicate whether or not the server is to continue the logon operation. Different return code settings are available to enable alternative ways of processing the logon and initializing the current library.

                    Comment


                    • #25
                      Determining IP Address

                      Oooooo. I hadn't thought about XML. I'll start out with a DB2 database, but with an eye towards XML for sure. XML would be perfect for fields definitions, with their multiple keywords and multiple values for the keywords. {scratching head} Yes, indeed, you've hit upon something there, David... Okay, so who needs sleep? Sleep is for the weak... Joe

                      Comment


                      • #26
                        Determining IP Address

                        At $185. for the host, and $0.00 for the client BOS has a 5250 Java based screen scraper. I've not used it, but the price makes it hard to pass up, even for just a tryout. Dave

                        Comment


                        • #27
                          Determining IP Address

                          Some proper advice, get your self a 64k ISDN connection with permanent IP addresses and a Cisco router and configure NAT within the router with a static NAT (Network Address Translation) entry. Thats how weve got ours setup and its 100% efficient. and we are also running domino on our 400. Im assuming that if you can afford a 400, you could afford this solution. In Australia we pay $235 a month for ISDN connection, unlimited internet access.

                          Comment


                          • #28
                            Determining IP Address

                            The virtual terminal APIs allow a user-written server job to intercept the 5250 data stream from a seperate QPADEVnnnn job. Then the server can translate the stream on-the-fly into another form for another machine. Sending 5250 data response into a QPADEVnnnn job, by way of the virtual terminal APIs, typically involves translating input from the other machine into row/column screen positions in order to create an acceptable "Read MDT" input buffer. This is one basis for a server-side screen scraper.

                            Comment

                            Working...
                            X