|
|
|
|
|
|
Greetings!
This issue of our newsletter has four articles. In the first article, we want to discuss how to more easily manage Journal Receivers by letting the system do some of the work for you. In the second, we'll tell you that support for i5/OS V5R3 is ending soon, and what your alternatives are. You can give us a call and we will do the upgrade to V5R4 or V6R1 for you. The third article discusses a new feature in V5R4 called Joblog Servers. The last article is for your reference with updated PTF information for your use. For a list of events that we will be attending over the next few months, please go to Events, as we will be in Winsor Locks, CT, Framingham, MA, Reno, NV, and Woodbury, NY.
iTech Solutions can help you improve performance, upgrade i5/OS, perform security audits, implement a High Availability solution, VoIP, Systems Management, PTF management, Blade installations, iSCSI Configurations, upgrade an existing machine, or upgrade to a new machine. If you are thinking of LPAR or HMC, then think iTech Solutions. We have the skills to help you get the most out of your System i.
Do you have advice for us about how we can improve your experience and help you get the information you need to succeed? How would you change this newsletter to make it more amazing? Are there other ways to receive information? We would love to hear from you -- you can give us your opinion . |
|
 |
System Managed Journals
|
|
There are many times that we are helping a customer clean up their system, and we come across large journal receivers that have been on the system for some time. This seems to be especially true when a customer is doing some testing, and then forgets about the journal and/or the journal receiver.
There is an answer for this: it's System Managed Journal Receivers. You can do this for existing journals, using the CHGJRN command, or you can set this up when you create the journal, using the CRTJRN command. In both cases, the parameters that we are concerned about will be the same. The first parameter we need to discuss is the THRESHOLD. This determines the maximum size of the journal receiver, and you specify this in KB. When the journal receiver becomes reaches this max and the journal is setup to be system managed, the system will automatically create a new journal receiver, detach the current journal receiver, and then attach the new journal receiver to the journal.
The second parameter is MNGRCV (Manage Journal Receivers). Set this to *SYSTEM so that the system "rolls" the journal receivers for us. The system will also generate a new journal receiver during an IPL and change the journal to use this new journal receiver, or if the journal receiver is in an Independent ASP, the system will generate a new journal receiver during the vary-on and change the journal to use this new journal receiver when that I-ASP is varied on.
Another function you can do is to allow the system to automatically delete these journal receivers after they have been detached. You do this by using the DLTRCV parameter and specify *YES. The DLTRCV parameter specifies whether the system deletes journal receivers when they are no longer needed, or leaves them on the
system for the user to delete after they have been detached by system change-journal management or by a user-issued CHGJRN command. You can also use this if you are using remote journaling, and the system will automatically delete the local journal receiver, when the remote journal receiver has been completely sent over to the remote machine.
We hope these tips and techniques make your life easier. If you require any help in implementing this or any other system administration, please contact us |
|
|
V5R3 Support is ending soon. |
|
IBM has made it known some time ago that April 30, 2009 is the end of support for V5R3. Yet, I think some people just ignore those warning statements. What does that mean for you if you are still on V5R3? You have 10 weeks before you will be running your business on an unsupported release of the operating system. The question becomes: why are you still on V5R3?
For most customers there is no reason to still be on such an old release of the operating system. In fact V5R4, which came out in April 2007, is probably one of the most stable releases of OS/400 or i5/OS in our opinion. In addition, we have had relatively few problems with customers upgrading to V6R1, once they pass ANZOBJCVN. See the article on getting ready for V6R1 with ANZOBJCVN.
Upgrading to V5R4 is fairly straighforward, but as with any upgrade there are a few gotchas to be aware of. In fact, we are presenting at the Hartford Midrange Users Group (HUMS) on Tuesday evening, March 25th, on how to upgrade to V5R4 and V6R1. It will be a Tips and Techniques on what you need to do from a planning perspective. Additionally, if you are too busy or just a little nervous about doing the upgrade yourself, we can handle the entire upgrade for you.
Recently, I was upgrading a V5R3 customer who hadn't put PTFs on since their old business partner had initially installed the machine. Their machine was so far back that we had to update the FSP in two steps, and also put a special PTF on so as not to overflow the Link Loader when loading PTFs. Basically there were too many PTFs to install, the PTF process would fall over, and you were left with a crashed system. This is another great reason to stay current with your PTFs and i5/OS upgrades. If your Firmware update policy is OS MANAGED, then you need to check the level of firmware on your FSP before applying additional PTFS when you haven't applied PTFs in a long time.
So what exactly does "unsupported" mean? Well if you run into a bug that isn't already fixed, IBM is not going to create a PTF to fix it. Also, if you get an audit of your computer systems, most audits will write you up for being on an unsupported operating system. If you just want to get off of V5R3, then my recommendation is to upgrade to i5/OS V5R4 with V5R4M5 for the License Internal Code. Be aware that you can only order V5R4 until January 2010. After that, you will have to upgrade to V6R1.
If you prefer to have iTech Solutions handle any of your systems management, which includes PTFs, i5/OS upgrades, or even technical iSeries question-and-answer sessions, then give us a call at 203-744-7854 or contact us via email, and we can work on this together. |
|
|
Joblogs & Joblog Server |
|
There is a new System Value that can help you reduce CPU when jobs end, and how and when joblogs are written to spool files. This System Value called QLOGOUTPUT will allow you to optimize how job logs are written. This new feature came out in V5R4, so if you are still on V5R3, see the article above on end of life.
First, let's discuss how and why information is written to a joblog, and what controls those events. Each job has an associated joblog that can contain the following information for the job:
- The commands in the job.
- The commands in a CL program (if the CL program was created with the LOG(*YES) option or with the LOG(*JOB) option and a Change Job (CHGJOB) command was run with the LOGCLPGM(*YES) option) .
- All messages (the message and help text for the message) sent to the requester and not removed from the program message queues.
At the end of the job, the joblog can be written to the spooled file QPJOBLOG so that it can be printed. However, producing a joblog doesn't necessarily mean printing it or creating a spooled file. Whether a joblog is created and what gets put into it is controlled by the LOG parameter of the Job Description (*JOBD) for each job. Most Job Descriptions will have the default of LOG(4 00 *NOLIST). Let's look at the three values of the LOG parameter of the Job Description. The first value of the LOG parameter is the LEVEL. This can be from 0 to 4. I won't go into each level, just tell you what the two extremes do. A zero means no messages are logged. A 4 means that all request messages, all messages with a severity greater than or equal to the message logging severity, and CL commands are logged. Since each message that is sent to a job has a severity, the SEVERITY of the LOG parameter specifies that only those messages which have a higher severity than the severity value will be included. The last value of the LOG parameter is the TEXT value, and the possible values are: *MSG - just the message text is written to the joblog; *SECLVL - both the message text and message help is written to the joblog; *NOLIST - if the job ends normally, no joblog is produced.
Now that you understand how to control what goes into a joblog, lets focus on the new system value, QLOGOUTPUT, which controls when the joblog is produced. The default for this is *JOBEND. This means that when a job ends, the job will write out its own joblog. This takes time and can also cause a CPU spike when multiple jobs end at once. The better value is to set QLOGOUTPUT to *JOBLOGSVR. Then the joblog for each job will be produced by a job in the subsystem QSYSWRK called QJOBLOGSVR. This is more efficient for your system and will spread out the CPU usage and not be so demanding at the end of a job. The third value is *PND, where the job log is not produced until required, and the joblog remains until removed.
You can easily change your System Value QLOGOUTPUT to *JOBLOGSVR, and as new jobs enter the system they will allow the joblog server to produce their joblogs for them. Don't worry, the QJOBLOGSVR is automatically started each time QSYSWRK starts, so you are ready to take advantage of this new feature.
If you prefer to have iTech Solutions handle any of your systems management, which includes PTFs, i5/OS upgrades, or even Technical iSeries question-and-answer sessions, then give us a call at 203-744-7854 or contact us via email and we can work on this together with you. |
|
Release levels and PTFs |
People are always asking me how often they should be performing PTF maintenance, and when is the right time to upgrade their operating system. I updated this article from last month with the current levels of PTFs. Let's look at PTFs. First, PTFs are Program Temporary Fixes that are created by IBM to fix a problem that has occurred or to possibly prevent a problem from occurring. In addition, some times PTFs add new functionality, security, or improve performance. Therefore, I am always dumbfounded as to why customers do not perform PTF maintenance on their machine at least quarterly. If IBM has come out with a fix for your disk drives, why do you want to wait for your disk drive to fail with that problem, only to be told that there is a fix for that problem, and if you had applied the PTF beforehand, you would have averted the problem. Therefore, I think a quarterly PTF maintenance strategy is a smart move. Many of our customers are on our quarterly PTF maintenance program, and that provides them with the peace of mind of knowing their system is up to date on PTFs. Below is a table of the major group PTFs for the last few releases. You might notice that this week, IBM just created a new Security PTF Group, so I have added this to our list, as we are installing this for our customers on iTech Solutions Quarterly Maintenance program.
Releases
6.1 V5R4 V5R3 V5R2
Cumul. Pack 8365 8305 8267 6080
Grp Hipers 29 93 164 189
DB Group 7 18 23 25
Java Group 6 18 22 27
Print Group 6 27 17 7
Backup/Recov. 5 23 32 31
Security Group 4 4 4 -
The easiest way to check your levels is to issue the command WRKPTFGRP. They should all have a status of installed, and you should be up to the latest for all the above, based upon your release. Now there are more groups than the ones listed above, but these are the general ones that most people require. We can help you know which group PTFs you should be installing on your machine based upon your licensed programs. Here is a nice tidbit. The Cumulative PTF package number is broken down as YDDD, where Y is the year and DDD is the day it was released. Therefore, if we look at the cumulative package for V5R4, the ID is 8183. We can determine that it was created on the 183rd day of 2008, which is July 1st, 2008. Look at your machine and this will give you a quick indication of just how far out of date in PTFs you may be. I left V5R1 off the list, because if you are on V5R1, you don't need to be worrying about PTFs, you really need to be upgrading your operating system. The same can be said for V5R2 and V5R3, but there are still customers who are on those releases.
If you have an HMC, you should be running V7R3.3.0 with Service Pack 3, or V7R3.4.0, with PTF MH01148 installed. This PTF is Required for V7.3.4.
For your Flexible Service Processor (FSP) that is inside your Power 5 or Power5+ (520, 515, 525, 550, 570), the code level of the FSP should be 01_SF240_358. Power 6 (940x M15, M25, & M50 machines, and 8203-E4A & 8204-E4a) customers should be running EL340_039. For Power6 (MMA, 560, and 570 machines) your FSP should be at EM340_039. If you have a Power6 595 (9119-FMA) then you should be on EH340_039.
If you need help with upgrading your HMC or FSP just give us a call. We will be happy to perform the function for you or assist you in doing it. | |
We have the skills to help you get the most out of your System i. For more information on any of the articles please contact us at info@itechsol.com . We would also like to know what you think of this newsletter and any items you would like us to discuss in future issues.
Our staff of Certified i5/OS professionals can help you get more out of your machines. Remember,
i want everything to work.
i want control.
i want an i
i need iTech Solutions.
Sincerely,
Pete Massiello
iTech Solutions | |
|
|
www.itechsol.com