Sometimes, the reason is improved capabilities; other times, it is a new feature that can enhance productivity. Most of the time, the support on your old release is about to expire, and you have to upgrade if you want to maintain software support.
So, after all that trouble and all the extra hours, you will have some explaining to do if response time is worse than it was before the upgrade. Here are some reasons why this might happen and some steps you can take to alleviate the situation.
IBM may have changed the methodology by which data is accessed in your new release. IBM has done this several times over the years, and each time it has been for the better. The problem is that your files haven't been reorganized to take advantage of the new algorithms. After a period of file activity, the files will automatically become adjusted, but this takes time, and the first few days seem like an eternity.
As long as the system is restricted, use this opportunity to reorganize every database you can. Use the RGZPFM command with the KEYFILE(*FILE) parameter specified. You've probably been meaning to do this for a while anyway, and now's your opportunity.
When a new release is delivered, many of the new objects are in compressed format. After a few uses, these objects will become permanently decompressed, but those first few uses can consternate users who are used to better response times. There is not much that can be done short of going into QSYS and manually decompressing everything. I recommend leaving everything alone. If you have reorganized your data, that should be enough. I also recommend warning your users of this temporary inconvenience in advance so that they are neither surprised nor panicked when the system performance is suddenly not what they're accustomed to.
David Abramowitz may be reached at
LATEST COMMENTS
MC Press Online