Iseries Upgrading from 9.0.0.4 options

 9 Replies
 0 Subscribed to this topic
 10 Subscribed to this forum
Sort:
Author
Messages
Jeano
Basic Member
Posts: 17
Basic Member
    Hi;

    We are currently on 9.0.0.4 and would like to upgrade to 9.0.0.9 . Has anyone done this yet? If so, what should we be looking out for? We are on V5R4 on the Iseries. Also, has anyone gone from 9.0.0.x to 9.0.1 on the Iseries? Thanks in advance.
    Scott Krueger
    Basic Member
    Posts: 14
    Basic Member
      You should have no issues going from 9.0.0.4 to 9.0.0.9 or 9.0.1 especially on V5R4.
      Patrick
      Basic Member
      Posts: 6
      Basic Member
        Jeano,

        Have you modified any Lawson code?

        Lawson source is now stored within the IFS and not in source file members.

        Jeano
        Basic Member
        Posts: 17
        Basic Member
          Hello Patrick;

          I do have 2 screens that were changed. They are now sitting on a Lawmod library. There are no changes to RPG. How do I migrate the screen changes?
          Thanks! in advance.

          Jean
          Jeano
          Basic Member
          Posts: 17
          Basic Member
            Hello Patrick;

            I do have 2 screens that were changed. They are now sitting on a Lawmod library. There are no changes to RPG. How do I migrate the screen changes?
            Thanks! in advance.

            Jean
            Patrick
            Basic Member
            Posts: 6
            Basic Member
              Jean,

              Since all Lawson source is now on the IFS, you could retrofit the code, if there are not a lot of changes. Or you can perform the CPYTOSTMF command.

              Here is a program example - note the general directory structure for the Lawson source:

              CPYTOSTMF FROMMBR('/qsys.lib/law9.lib/ifpgsrc8.file/cu99.mbr') TOSTMF('/law9/law/lawapp9/rpg/ifrpg/IFRPGSRC/CU99.COPYPGM') DBFCCSID(37) STMFCODPAG(819)

              You would first want to make a backup copy of the entry you are replacing.

              Once the entry is changed in the IFS, call the SCRGEN and QCOMPILE commands in QSH to compile the screen and the program source.



              Jeano
              Basic Member
              Posts: 17
              Basic Member
                Patrick;

                Thanks for the information. Thus; I have a screen change for GL40 and PR35 sitting in a library call Lawmod9. Lawmod9 is in the Lawson Library List. Do I Copy just GL40D, PR35D from Lawmod9 to the IFS using the CPYTOSTMF command? In addition, Once the screens are successfully compiled, I wouldn't need to have Lawmod9 in the Libary List. Am I correct?

                Jean
                Patrick
                Basic Member
                Posts: 6
                Basic Member
                  Jean,

                  Yes, use the CPYTOSTMF command to place your modified source to the IFS.

                  The LAWMOD9 library would not be needed in the library list (unless it contains objects Lawson needs).



                  Mark F. Hardy
                  Veteran Member
                  Posts: 44
                  Veteran Member

                    Our shop just went to 901 as well. We had minor mods to both CB and GL, but due to significant mods to a couple AP programs, the new 901 IFS source code structure, and new compile methods we had to reevaluate our program development and deployment strategies.

                    We initially created a new native source file long enough (ie 228 chars) to offload the code from the IFS. It is used to modify and archive our version of the IFS code natively.

                    Each app also has three controlling CLs to: 1.)Copy from IFS code to work versions; 2.)Copy to IFS code; 3.) Compile IFS code components.

                    Program development is slightly modified with these three CL's. But our deployment strategy had to remain the same due to SOX constraints.

                    This was especially a concern as our AP150 had modified work files. The first file could only be modified with the workdef tool and the other controlled by sort code in the main program source component.

                    We knew we could not use the workdef tool on our production system. And the autogeneration of some portions of code with the new compile process was a challenge. We needed to fully understand the new compile process.

                    We circumvented the first issue by using workdef on our development system, then used the metadumpwrk to save our version of the file. This would be the only IFS source to be manually moved by Operations during deployment.

                    Both situations were eventually handled in the front end of our compile CL. The compile CL deletes both files, thus triggerring autocreation of both. It then uses metaloadwrk to reset the file definition of the first file with our modified version. Using metaloadwrk essentially bypasses the workdef tool, and simulates the manual effort. The compile CL then continues by using its companion CopyToIFS program to move the other AP150 source components, uses SCRGEN for the screen creation, and finally LAWCMP for the program creation. In this case, our compile program is designated as a self submitting batch program, so we were able to use LAWCMP as opposed to QCOMPILE.

                    The deployment effort was a coupling of the manual source migration (the single IFS component and remaining native modified source files) by Operations followed by the compile CLs. Finally, the compile CLs have an added benefit for ease of creation in the event of object corruption. The only other task necessary was an IOS Cache refresh to align our application mods with the Portal.
                    DanaB
                    Basic Member
                    Posts: 6
                    Basic Member
                      We are currently going from 9.0.0.4 to 9.0.1, so this information has been very helpful. Thanks all!