Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Writing data into Display File of OS/400 Cobol program

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

  • Writing data into Display File of OS/400 Cobol program

    No, you have to do this yourself. You have basically two ways of doing it: use a screen-scraper approach that populates the 5250 data stream, or modify your COBOL program to read a data queue and move the data into the fields itself. For simple programs, this isn't too difficult, but when you start talking about subfiles and popup windows, this can get very complex. Joe Pluta www.plutabrothers.com

  • #2
    Writing data into Display File of OS/400 Cobol program

    Thanks Joe, for your reply. These programs are are fairly complicated and apart from the effort in cloning them, our fear is that we'd have to maintain 2 sets of programs on an on-going basis. As I write this, we are looking into a product called Jacada Interface Server which claims to populate display files with data arriving from XML without making any change to the program. That's FYI. Unni

    Comment


    • #3
      Writing data into Display File of OS/400 Cobol program

      I have to be careful how I phrase things here, because Jacada is a competitor of mine. In the interest of full disclosure, let me say that my company markets a product, PSC400, that does exactly what you want to do, but it only does it for RPG and RPG ILE programs (a COBOL version is in design stages, but no delivery date is set yet). PSC400 modifies the source, but the modification is 100% automated and the modified programs run both interactively and via the web. The reason I bring this up is that even though PSC400 does not handle COBOL today, the architecture may still work for you. You could conceivably implement the architecture yourself. The way PSC400 works, a modified program will run either interactively or via the web. That means only one program, and hence only one source version. In interactive mode, it communicates with a display file and runs just like it did prior to the conversion. However, in "web mode" the program runs in batch and uses data queues to communicate to the web server, so it doesn't contribute to the interactive load on your machine. The screen scraper approach that Jacada uses means that the programs actually run in your interactive subsystem, so you not only have the interactive load, but also the load of the web application server (probably WebSphere). That combined with the overhead of large amounts of JavaScript can make your interface very slow and cumbersome. Before you make your decision, be sure that Jacada actually converts your application and you run in a real environment to see how well it performs, especially under heavy use. Joe Pluta Pluta Brothers Design www.plutabrothers.com

      Comment


      • #4
        Writing data into Display File of OS/400 Cobol program

        Unni, You may want to look at WEBFacing. I haven't used it myself but it is something we will be looking at here. My limited understanding is that it runs under WEBSPHERE. Basically the WEBFACING creates a web based interactive "screen" from your display file. Then when a user from a browser runs that web page "screen" the data is collected from the browser and is supplied to the COBOL app as if it was from the original display file. The COBOL program doesn't "know" (meaning you dont have to modify your COBOL program) whether the input came from the 5250 display file or from the web browser. The original display file screen works the same as before. Therefore you only have one COBOL app to maintain. I might not have all the facts exactly straight but that's the gist of it. Phil

        Comment


        • #5
          Writing data into Display File of OS/400 Cobol program

          Thanks Phil, for your input. Our problem is that we have already started entry on an existing web application. We are now trying to feed data that we have captured from this we based application into our Cobol program. If you recall WINS - we're feeding data into the Claims Entry module - and this means Claims and Claimant programs and screens - kinda tricky, dont you think? Webfacing will be used when we make WINS web-based. But for now, our problem is different. Thanks again Phil.

          Comment


          • #6
            Writing data into Display File of OS/400 Cobol program

            Thanks Joe - I browsed your website briefly. I dont take decisions on software purchase here but I've mentioned your product to my co-workers and will refer to it as alternatives.

            Comment


            • #7
              Writing data into Display File of OS/400 Cobol program

              Like I said, Unni, our PSC400 product probably isn't a fit for you since you're a COBOL shop. But the architecture isn't that difficult - if you can stand a quick plug, MC sells my book "eDeployment: The Fastest Path to the Web", and the entire architecture is outlined there, along with the software required to implement a proof of concept. The book is geared towards RPG, but can easily be adapted to COBOL, since the modifications to the program are very minor. Joe

              Comment


              • #8
                Writing data into Display File of OS/400 Cobol program

                We have an OS/400 Cobol online program that uses a display file to get data from users. The data entry will now be done in a web-based system. We are building adapters to bring the data to AS/400. Our intention is to feed the data to the Cobol program which originally used a display file to get data. We know that VAJ has java classes to make AS/400 program calls with parameters. Are there classes that will call the Cobol program AND populate the display file with data, and then, continue with its usual flow of logic as if a user had just completed entering data?

                Comment

                Working...
                X