i can do anything with iTech Solutions
Everyone at iTech Solutions wishes you a fantastic Thanksgiving holiday with family and friends. The time between Thanksgiving and New years is by far my most favorite time of the year. We hope you enjoy all the upcoming holidays. Each Thanksgiving I just count my blessings as I have so much in my life to be thanksful for, I hope that you are as fortunate as well. I am also grateful for the opportunity to write to you each month, grateful when I think that someone will read these words, and grateful that perhaps something I write will help make some System Administrator’s life a little easier, work more efficiently, or help them solve a problem that they have been facing for a while. I would like to thank you for the opportunity you have given me by subscribing to this newsletter, no matter if you have been here since the start 6 years ago or this is your first issue. Some business partners provide a lot of stuffing, but with iTech Solutions it’s like Thanksgiving all year round. Why not “Fill your plate” with IBM i (AS/400, iSeries) expertise to get the job done right the first time. You will be surprised at the number of ways we can help you. Each month our newsletter brings to light tips and techniques that help many System Administrators in their job, as well as help managers know what is happening in the IBM i world. We are happy to be able to help so many people in the IBM i community. The number of iTech Solutions customers is growing each and every month, and I believe that is due to our commitment to our customers, our services that we offer, and the support that we provide. Find out for yourself what it is like to work with a business partner who cares about you and your success.
If you are a regular reader of this newsletter, you know that standard IBM support for V5R4 expired at the end of September. If you are still on V5R4, you know what I have been telling you. Stop praying for a miracle upgrade. Take action, iTech Solutions can make it happen as it has for hundreds of others. Give us a call, don’t go at it alone. Check our references, because they will tell you just how smooth their upgrade was. This is our last technical newsletter for the year; stay tuned for the December special newsletter on how iTech Solutions helped Santa save Christmas.
This issue of our newsletter has 6 articles. In the first article, we will discuss the new problems with changing Cache Batteries in your disk controllers. The second article is about Journaling enhancements in 7.1 TR7. The third article is on Naming your images with the SNDPTFORD command. The fourth article is on you don’t have to sign-on to DST everytime you take over the console. The fifth article lists some of the upcoming events in which iTech Solutions will be participating. The last article is for your reference with updated PTF information. Please note that for all 7.1 customers that are on the Quarterly iTech Solutions PTF maintenance plan, we will be installing Technology Refresh 7 for you on your next application of PTFs.
Having a business partner isn’t the same as having iTech Solutions, if you aren’t getting the support, the help, the guidance, and the advice you need to succeed then you need to contact iTech Solutions for your IBM Power Systems running IBM I needs. We can help you upgrade your AS/400 or iSeries to a Power Systems running IBM i.
iTech Solutions vast experience can help you improve performance, perform security audits; implement a High Availability solution; perform health checks, systems management, remote administration, PTF management, blade installations, Cloud based systems, Hosting, iSCSI configurations, and backup/recovery; 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 IBM i.
For more information on any of the articles below please visit us on the web at iTech Solutions or email iTech Solutions. We would love for you to let us know any articles that you wish for the future, or if you enjoy any of the articles in the current newsletters.
It used to be a routine operation, the CE comes in changes your batteries on your disk controller for the cache and you didn’t even notice. Not any longer! First, let’s make sure everyone knows why this is so important and can affect your production machine negatively.
There are batteries on your disk controller that keep the data protected while in the cache. Think of the cache as very fast memory to speed up the performance of the disks and therefore the entire system. When a write is written to disk by an application program for instance, the data is sent to the disk controller where it is first written out to cache. Once the data is written to the cache on the disk controller, the I/O is deemed complete and control is returned back to the application to continue its processing. Then the controller moves the data from cache to the actual disk drive. If the power to the system was to be lost between the time the data is written to cache and before it was written to disk, that data would be lost without the batteries powering the cache. Now, you understand the importance of the cache to performance, and the batteries to keeping the integrity of the data. Normally the batteries last on average just under a 1000 days. You start to get warning messages at about 90 days before the battery goes. Once the battery is dead (has no ability to charge or power the cache memory on the disk controller), the system will no longer use the cache for a buffer, but instead write the I/O directly to disk. If you were to do a WRKDSKSTS and hit Function key 11, it would display Degraded in the status. You will know when this happens as your system will grind to a halt and your response time will become terrible.
Up until recently, IBM used to ship the cache batteries fully charged. So, when the CE replaced your cache batteries, he would take your current battery out and replace it with a fully working battery. The disk controller would determine that it had a good battery and continue to use the cache. Everything was great. Now, due to safety regulations, IBM can no longer store and ship these batteries charged. Therefore, when the CE replaces your battery with a new battery the new battery must be charged by the disk controller before the disk controller uses the battery to power the cache. This results in a disk performance nightmare. Let me explain that again for some of you, the performance of your disks will be as slow as molasses. We have seen this a few times over the past few months, so I thought it was good to make sure everyone is aware of the problem.
By the way, it takes about 4 or 5 hours to charge the new batteries. During this time you feel like you are riding a turtle compared to what used to be a thoroughbred horse.
I guess you could charge the batteries in another machine, or a development partition, but the first time you get caught with this I just hope you have a planned downtime of 4 to 5 hours to charge the batteries. The newer disk controllers, like the 5913 disk controllers don’t require replacing the batteries as they have rechargeable cells.
In February 2011, we wrote a article on how to determine when your batteries will need replacing. You should check the article out and make sure you plan accordingly for your next outage. To determine if your controllers can be replaced by newer models, please contact Pete.
Journaling enhancements with 7.1 and TR7.
One of the biggest problems with doing a restore used to be with logical files being restored before the physical files. IBM fixed that in 6.1 of the OS. The next biggest issues with restores was that if a file (or data area, or data queue) was journaled when it was saved, and then that object was restored before the journal was restored, that object would no longer be journaled. This caused problems with many restores. IBM i 7.1 with Technology Refresh 7 now fixes that problem using the same Deferred ID on the restore commands for journaling as it does for logical files. Whoooo Hooo!!!!! If you do system migrations and restores as much as I do, then you will also be just as excited. Yes, another reason to get up to the latest releases of the operating system as well as stay current on your PTFs.
Some restore commands as well as the GO RESTORE option 21 are already configured to use the Defer ID. As such, these commands and operations can be called directly using the same Defer ID (DFRID) value that was used on RSTOBJ, RSTLIB, or GO RESTORE 21.
Journaling for an object will resume when the missing journal is restored or explicitly recreated followed by a call to RSTDFROBJ using the appropriate DFRID.
A new system file, QADBRSDFRJ, will be used to track objects that defer start journaling. The file will be created into the QRECOVERY library for SYSBAS and the QRCYnnnnn library for independent ASPs (IASP). One record will be inserted into the file for each object that defers starting journaling.
The objects which defer start journaling will be created. Since the objects are restored prior to resumption of journaling for the object, the restore and create journal entries for these objects will not be generated.
If a Defer ID is specified when restoring an object into a journaled library that has a *RESTORE inherit rule defined and the object was journaled at save time and that journal does not exist on the system, the start of journaling will be deferred for the object to the journal the object was journaled to when it was saved.
If a Defer ID is specified when restoring an object into a library that contains a data area named QDFTJRN that has a *RSTOVRJRN rule defined, the object will attempt to automatically start journaling to the journal specified in the QDFTJRN data area, regardless of whether or not the object was journaled when it was saved or the journal target at save time. If the journal specified in the QDFTJRN data area does not exist, the start of journaling will be deferred.
If a Defer ID is specified when restoring an object into a journaled library that has a *RSTOVRJRN inherit rule defined, the object will attempt to automatically start journaling to the journal being used by the library, regardless of whether or not the object was journaled when it was saved or the object’s journal target at save time. For this scenario, the journal for the library exists and therefore deferred journaling does not apply.
This should make your migrations so much more easier and give you less headaches. Make sure you get up to OS 7.1 with Technology Refresh 7 before undertaking your next restore or migration. If you need help with an upgrade or to get your PTFs to the latest technology refresh, contact Glenn, Paul, or Rick for an estimate.
This one comes from my friend Jim Kelly who uses this when naming the images when using the SNDPTFORD command. This is a great way to keep track of the images. As many of you know, if you use the SNDPTFORD command to get PTFs, you can have IBM deliver those as images using the parameter DLVRYFMT(*IMAGE) or as save files using the parameter DLVRYFMT(*SAVF). You can read more on using the SNDPTFORD command in a previous iTech Solutions newsletter. By the way, these images are stored in the IFS in this directory: /QIBM/UserData/OS/Service/ECS/PTF
Image catalogs are a useful tool for ptf application. The SNDPTFORD command includes the IMGPFX (image prefix) parameter. The default is *SRVPVD which generates a unique, but not informative name for the image file. Optionally, you may specify a name (up to 10 characters) that will be used in generating the file name. For group ptf’s we use the group ptf id and level. Some may prefer a pneumonic name. A typical system generated name would be S9707V01.BIN01 while putting SF9936228 for the IMGPFX parameter would generate a image catalogue with the name SF9936228S5879V01.BIN01. That includes a prefix that more readily identifies the BRMS level 28 group ptf. The SF99362 is the BRMS Group PTF number, and the 28 in this case is the current level of the PTF group that you are downloading.
This will certainly make keeping track of your images easier. Don’t forget, if you want to take the total hassel out of PTF management, get on the iTech Solutions Quarterly or Semi Annual PTF maintenance program, and let iTech Solutions mange and apply your PTFs for you. Contact Paul or Rick for more information.
Do you use Operations LAN Console for your IBM i (AS/400 or iSeries) console? If you don’t have an HMC, this is the console that we recommend. If you currently have a twinax console, contact John at iTech Solutions and have him convert you to Operations LAN Console. The best reason is remote connectivity, like being able to do a full system back (Go SAVE 21) from home. Perform any restricted system command on the console remotely. Operations LAN Console is just a blessing when it comes to more easily managing and administrating your machine.
One of the annoyances that happens when you are using Operations Console, is that when you try to reconnect to Operations Console it asks you to enter your DST/SST userid and password. Then the Console Information Status screen is displayed, where you hit F10 to take over the console. Well, with 6.1.1 & 7.1 this sign-on can be skipped. In fact, if you put PTFs MF50441 on V5R4M0, MF50443 & MF56965 on V5R4M5, or MF44644, MF44859, & MF50444 on 6.1.0, and MF50445 on 6.1.1 you can also have this new functionality.
With the new functionality, when you are presented with the DST Signon screen, you will notice an F18 function key at the bottom of the screen. Pressing F18 will skip the DST sign-on screen, and bring you right to the IBM i sign-on screen for the console device in the controlling subsystem. This makes your life so much easier.
We have pointed this out to a few customers during some recent health checks. The iTech Solutions Health Check is to identify problems you might have, best practices you might not be following, identify performance issues, security issues, etc. Yet, sometimes it just takes someone to see the very simple things that you are doing wrong. For help or to have an iTech Solutions Health Check contact Paul or Rick.
Some of the events that we will be speaking at, or exhibiting at are listed below. Don’t forget the iTech Solutions web site at http://www.itechsol.com.
April 7 – 9, 2014 Northeast User Groups Conference – Framingham, MA http://www.neugc.org
May 5 – 8, 2014 COMMON Annual Conference – Orlando, FL http://www.common.org
June 3, 2014 Michigan IBM i Technical Conference – Livonia, MI http://gomitec.com
June 18, 2014 New England Midrange Users Group – Managing IBM i with Navigator for i www.nemug.com
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. This is what we are installing for our customers on iTech Solutions Quarterly Maintenance program.
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 9104. We can determine that it was created on the 104th day of 2009, which is April 14, 2009. 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 & V5R2 off the list, because if you are on V5R1 or V5R2, you don’t need to be worrying about PTFs, you really need to be upgrading your operating system. The same can be said for V5R3, but there are still customers who are on those releases.
If you have a Hardware Management Console (HMC,) you should be running:
If you have an Flexible Service Processor (FSP) your firmware should be:
|Power5 or 5+||520, 515, 525, 550, 570||SF240_418|
|Power6||940x, M15, M25, M50||EL350_149|
|8203-E4A, 8204-E8A, 8204-E4A||EL350_149|
|MMA, 560, 570||EM350_149|
|Power7||8231-E1B, 8202-E4B, 8231-E2B, 8205-E6B, 8233-E8B, 8236-E8C||AL730_122|
|8231-E1C, 8202-E4C, 8205-E6C||AL740_100|
|Power7+||8231-E1D, 8202-E4D, 8231-E2D, 8205-E6D||AL770_032|
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. Contact Pete Massiello.