Iseries Upgrading from 9.0.0.4 options

 9 Replies
 0 Subscribed to this topic
 10 Subscribed to this forum
Sort:
Author
Messages
Jeano
New Member Send Private Message
Posts: 0
New 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 Send Private Message
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 Send Private Message
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
New Member Send Private Message
Posts: 0
New 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
New Member Send Private Message
Posts: 0
New 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 Send Private Message
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
New Member Send Private Message
Posts: 0
New 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 Send Private Message
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 Send Private Message
Posts: 45
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 Send Private Message
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!