Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Database Externalization

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

  • Database Externalization

    The good: Reference to a db file can be limited to a single service program. Could simplify maintenance if file changes. The bad and sometimes ugly: Additional logic is required to manage efficient opening and closing of files.

  • #2
    Database Externalization

    We wrote an entire shop floor application with this years ago, long before there were service programs. The customer wanted the application in COBOL, but, at the time, COBOL had no way to unlock a record without updating it. So we wrote external data handlers in RPG (which the customer grudgingly accepted). Anway, there may be ways around it now, but one of the big things we ran into was that all files become shared files, since you now have a single point of access. This requires some creative programming, like saving key values, or even entire records, before calling another progrram that uses the same file. In some cases, where the code got really ugly, we wound up creating logical files that were identical (to the physical or another logical), just so that we could break this sharing. One thing that we did do, was to create extensive copy members. We wrote a code generator that could create the I/O program source based on DSPFD and DSPFFD output. All I/O programs had the same parameters (I think it was an action code, keys to use, number of keys to use, record image out, and some sort of return code out). The keys to use parameter included all keys. The number of keys to use determined how much of the structure was actually in play. Major things that you lose are program references and level checks. The application programs don't declare the file, so there's no good way to find which programs use a file, except by searching source. Only the I/O program gets a level check, which means it's isolated, but you then have to scan all source to find the callers. We also soft coded the names of the data handling programs. Though we never used it for this purpose, this does allow for some extra flexibility. If you change an interface, or even one of the files, you don't need to change all of the programs that "use" the file; you only need to change the I/O handler. As long as the I/O program can reformat the data into the old record format, the programs that call the I/O program don't know or care that the file or interface has changed. In fact, the I/O program could be accessing multiple files to build the record image; it doesn't matter.

    Comment


    • #3
      Database Externalization

      Good afternoon, I was reading materials related to Application Modernization (IBM Roadmap, Redbooks, etc...) and I am trying to get some feedback (good or bad) on I/O externalization. The theory sounds great, but there seems to be mixed reports on the practicality of such an approach. I am interested in hearing the good the bad and the ugly of I/O externalization. Thaks

      Comment


      • #4
        Database Externalization

        Well, I've been involved in projects going both ways, to "externalize" the I/O and to kill externalization. IMO, externalizing AS400 I/O reduces the built-in DB2 database to being like other add-on databases on other platforms, where db access is via a call to some type of external program. The AS400 db access is so tightly ingrained into the OS that this is backing up and making the whole system slow down. One of the really nice things about our platform is it's tight integration. After all, which would you rather see: "CHAIN FILEA PARM KEY" or "10 lines to set up the variables, CALL READPGM PARM(fname accesstype key keylen dtabuf dtalen rtnval...whatever), 10 lines to check and move the data" and the I/O program is itself MANY lines of code. Which one do you think is faster? All this in a world where we try and optimize file opens by sharing access paths. This is what I call a chalk-board concept, like a fully normalized database is a chalk-board concept...looks really good on the chalkboard or in the classroom but just is not practical in real-world use. Not to even mention the added maintenance time to understand and follow the above. As I mentioned, I've been involved in projects going both ways, de-externalizing was the way that felt "right". JMO

        Comment

        Working...
        X