Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Convert S/36 on AS/400 to straight AS/40

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

  • Convert S/36 on AS/400 to straight AS/40

    Can anyone tell me what is involved in converting an application that runs in the System/36 on AS/400 application to a regular AS/400 application? Not to make it take advantage of the extra advantages of AS/400 but just to run. Is this dead simple, or extremely complicated or something in between? What would some of the issues be? TIA, Debbie Gallagher

  • #2
    Convert S/36 on AS/400 to straight AS/40

    On Tuesday, June 29, 1999, 04:53 PM, Debbie Gallagher wrote: Can anyone tell me what is involved in converting an application that runs in the System/36 on AS/400 application to a regular AS/400 application? Not to make it take advantage of the extra advantages of AS/400 but just to run. Is this dead simple, or extremely complicated or something in between? What would some of the issues be?
    There is a lot more to going native than meets the eye. Furthermore, you may opt to do this all the way, or just partially.
      [*]Database - Converting flat file to DB2/UDB/400, or whatever it's being called today, may be more complicated than it looks. Typically S/36 files may be in multiple formats, or rely on overlapping fields, or subfields. Defining the PFs may require a good deal of analysis. Determining which sorts will become permanent LFs, and which will become FMTDTAs or OPNQRYFs is also a matter of analysis.[*]COBOL - These programs if originally run on mainframes, may fill numeric values with spaces. If you do a straight conversion to COBOL/400, you may end up with decimal data errors when running. Include a PROCESS statement at the top of each program with the APOST keyword. This will eliminate the need to change all apostrophes to quotes.[*]RPG II - This will easily convert to RPG/400, but notice no mention was made about externalizing files (COBOL too).[*]ILE - Do this afterwards.[*]OCL to CL - There are third party packages that will do this for you in one swell foop![/list]Getting all of the niceties of the native environment won't come until a lot of tweaking is done. In any event, expect to allocate a good deal of time and a portion of your budget to this effort. IMO such an effort may be done piecemeal during "slow" times without affecting any other projects currently taking place. David Abramowitz

    Comment


    • #3
      Convert S/36 on AS/400 to straight AS/40

      The syntax changes (OCL to CL, RPG II input chained file processed by limits to input full-procedural, etc.) are one issue. Another is redesign of the application. For example, it's common for an OCL procedure to delete a work file, if it exists, before running #GSORT to build the work file. I know you said you're not asking about AS/400 enhancements, you just want to know how much trouble it is to get the stuff to run, but IMHO, if you're not going to take advantage of enhancements, it's probably not worth the trouble to get the stuff running as native objects. I have one client who has a lot of S/36 stuff. I leave some of it in S/36 mode, especially interactive programs, since it's so much trouble to convert them to native. However, if I have to make a change to a report program that has very little of an OCL procedure to run it, I go ahead & change it to native if it's not a lot of trouble.
      color=blue>On Tuesday, June 29, 1999, 04:53 PM, Debbie Gallagher wrote: Can anyone tell me what is involved in converting an application that runs in the System/36 on AS/400 application to a regular AS/400 application? Not to make it take advantage of the extra advantages of AS/400 but just to run. Is this dead simple, or extremely complicated or something in between? What would some of the issues be?

      Comment


      • #4
        Convert S/36 on AS/400 to straight AS/40

        Ted, you're right. If you could provide some examples, it probably would be helpful. Here's the situation. I am assisting a client with a software selection to replace their entire system. Sent out the RFI to the short-listed vendors, and one of them sent back a reply that several modules were currently written for System/36 but they would be pleased to "retrofit" them to AS/400 for the client, if they were chosen as the vendor. I have sent a follow up request to the vendor, asking for the details of how and when they would accomplish the conversion of the S/36 modules. I'd like to be able to evaluate the incoming details to determine if the plan makes any sense or whether it appears the vendor is out to lunch. I need to be able to advise the client one of two things, really: 1. Looks like the vendor has a good workable plan to achieve the conversion; or 2. The vendor's plan is nonsense and here are some good reasons why I think so. If you have suggestions, feel free to make them. Regards, Debbie Gallagher On Friday, July 02, 1999, 12:43 PM, Ted Holt wrote: The syntax changes (OCL to CL, RPG II input chained file processed by limits to input full-procedural, etc.) are one issue. Another is redesign of the application. For example, it's common for an OCL procedure to delete a work file, if it exists, before running #GSORT to build the work file. I know you said you're not asking about AS/400 enhancements, you just want to know how much trouble it is to get the stuff to run, but IMHO, if you're not going to take advantage of enhancements, it's probably not worth the trouble to get the stuff running as native objects. I have one client who has a lot of S/36 stuff. I leave some of it in S/36 mode, especially interactive programs, since it's so much trouble to convert them to native. However, if I have to make a change to a report program that has very little of an OCL procedure to run it, I go ahead & change it to native if it's not a lot of trouble.
        color=blue> On Tuesday, June 29, 1999, 04:53 PM, Debbie Gallagher wrote: Can anyone tell me what is involved in converting an application that runs in the System/36 on AS/400 application to a regular AS/400 application? Not to make it take advantage of the extra advantages of AS/400 but just to run. Is this dead simple, or extremely complicated or something in between? What would some of the issues be?

        Comment


        • #5
          Convert S/36 on AS/400 to straight AS/40

          Ted, you're right. If you could provide some examples, it probably would be helpful. Here's the situation. snip
          1. Most RPG II code will compile as is. The F spec probably needs the most revision, believe it or not. Block length entries and L's for limit files must be removed. File format can't be blank, so you have to stick an F in there for program-described files. Combined demand files become combined full-procedural. I think most of the conversion tools can handle this stuff easily. E, I, and O specs should be OK. Most C specs work OK, but certain opcodes, like KEY and SET, won't. So, first, I'd like to know what they're going to do to all that RPG.
          2. OCL to CL is a bigger conversion. Most packages convert // FILE to OVRDBF, // LOCAL to CHGDTAARA, etc., but what do these people plan to do about #GSORT? Convert it to FMTDTA? Convert it to OPNQRYF?
          3. Screen formats. This has got to be one of the worst parts of conversion. I'd rather take a beating than convert an interactive S/36 program to native. $SFGR can't define data types or number of decimal positions. When you compile a screen format member, you have the option of saving the generated DDS in a source member. You should see that stuff! Horrors!!!
          4. David mentioned the problem of multiple record formats in a disk file. What are they going to do about them? More than likely, they'll create separate physical files, then put them together with multiple-format logical files. This works, but requires a format selector program for output to the logical file.
          So I'd start by asking how they're going to handle these things. Anybody else want to add to the list, disagree, or make other comments to help Debbie?

          Comment

          Working...
          X