ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Moving from S/36 to modern RPG/ILE environment

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

  • Moving from S/36 to modern RPG/ILE environment

    Looking for information, tips, experience that users here have in migrating a production environment from a S/36 environment to modern ILE environment. What tools are out there that may be useful converting code. What approaches people use to get from A to B.

    I am leaning toward getting the new libraries in place and building new software enhancements there and slow migrating the existing code as we touch it to make enhancements.

    Anyone that has practical exposure to this that has any input on lessons learned or practices that will help smooth the transition would be greatly appreciated.

    Jeff

  • #2
    Re: Moving from S/36 to modern RPG/ILE environment

    I looked at Linoma's website, because I've heard good things in years past about their migration tool. It doesn't look like they advertise it anymore, but it's probably still available.
    Good luck!
    Last edited by Keith Hodges; September 12, 2015, 11:03 AM. Reason: pronoun

    Comment


    • #3
      Re: Moving from S/36 to modern RPG/ILE environment

      Jeff,
      I have done this before for some clients when I was in the consulting world. The first question that you have to ask yourself is "What benefit can I receive by making it "modern"?" Identify some key benefits and then review the programs that would be best served to make this migration and realize those benefits. Create a library and place it a step higher in the library list and then put the migrated programs into that library. Certainly the opportunity to migrate when you add enhancements to a program is a good time, but remember if you are adding an enhancement that minor (ie. a couple of hours max) but it takes 3 weeks to migrate, is that a good use of time?

      I would, prior to any program migration, make sure that your data files have all been "DDS'd" so that you have external file descriptions. There is no point in in using the newer language constructs with internally defined data files.

      Also understand that you are in a position to use the best of both worlds. For example, you can call CL and use other CL commands inside your old OCL.

      Just my $0.02 Canadian ( or about $0.015 US).

      Comment


      • #4
        Re: Moving from S/36 to modern RPG/ILE environment

        Keith -

        Thanks, I have good relationship with the Linoma folks. I do have them on my list to call. Waiting to get a programmer on staff here and up to speed first. Unfortunately, I think that product was let go long ago. I think it might have piggy-backed on an old IBM tool that is no longer supported. But I definitely have that on the list as well as

        RBO -

        I've been in IT a long time, so I am pretty well versed in weighing the risk vs. reward of updating the code. The primary benefit to updating the code is having an environment that isn't predicated on a skill set that virtually doesn't exist in the market place. Try hiring RPG programmers, even those that are stuck in OPM era coding practices, and try to bring them on board to a full fledged S/36 environment.

        Definitely plan on modernizing the tables, but will probably go the DDL route.

        Comment


        • #5
          Re: Moving from S/36 to modern RPG/ILE environment

          You can, sort of, convert things from S/36 to modern times by doing:

          a) Change the source type from RPG36 to RPG.
          b) Try compiling... some S/36 features might not work.
          c) Fix up the things that didn't work, repeat b & c until working. Now you have an RPG III program.
          d) Run CVTRPGSRC to make it an RPG IV program.

          The result, though, will still be using program-described files, six-character field names, and fixed-format code. It will be monolithic, not modular, not using ILE techniques, etc. To truly update the code isn't just a "conversion", it requires human intelligence to really do a good job of refactoring (and in many cases rewriting) the code into something modern. Tools from folks like Linoma and Arcad may help, but ultimately, it's not going to just be "convert and everything is modern". There's no way a computer can know, for example, the 10 (or more) character variable names to use when the old files had 6 character names that differed between each program...

          Comment

          Working...
          X