July 2011 Newsletter
i can do anything with iTech Solutions
Well I hope that you are having a fantastic summer, it seems to just be flying by. Everyone here at iTech Solutions is enjoying our summer, although we probably could do without the extreme heat. We have also been extremely busy with new system installations, upgrades, recoveries, and i5/OS upgrades.
As I talk with customers and prospects each day, I always ask them what their pain points are, what are the problems they are trying to solve, and what keeps them up at night? While each customer is entirely different, I can tell you that there are a lot of similarities amongst the people that I talk with. Some things that they have in common is discovering new technology, finding ways to embrace new technology, and teaching their staff about how to take advantage of the new technology. This is where education like COMMON, and other user groups can really help you. In addition, depending on the technology, iTech Solutions can help you learn the new technology, implement the technology, or even provide skills transfer. No matter what the problem, we are always available to help our customers find the right solution to their needs. Some times, that is us, sometimes that is bringing in IBM, and other times it is bringing in partners with skill sets which we don’t have. In any case, we are a company that will help you find the right solution to your needs/problems.
Each month our newsletter brings to light tips and techniques that help many System Administrators in their job, as well as 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 month, and that is due to our commitment to our customers, our services, 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.
This issue of our newsletter has four articles. In the first, we look at a new parameter on the restore commands with 7.1. The second article is on your system’s name. The third 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.
If you are still on V5R4, send Pete an email and he can help you upgrade to V6R1 or V7R1, with over 300 V6R1 upgrades done to date you know iTech Solutions has the expertise and know how.
iTech Solutions can help you improve performance, upgrade i5/OS, perform security audits, implement a High Availability solution, Health Checks, Systems Management, Remote Administration, PTF management, Blade installations, iSCSI Configurations, 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 System i.
New ALWOBJDIF parameter option on restore with 7.1
A new value *COMPATIBLE has been added to the ALWOBJDIF (Allow Object Differences) parameter to make restores work better.
We have always used the ALWOBJDIF(*ALL) for database files, but it can cause us problems when there is a file level difference between the file on the system and the file being restored. When this occurs, the original file is renamed with a numeric suffix and the new file is restored with the original name. Unfortunately, the logical files are still based over the original file, which was renamed. This is a pure disaster in the making. You can get different results then reading the physical file vs. reading the logical files (because the logical files are based upon a different physical file). The same issue happens if the member has a different level upon the restore.
When using ALWOBJDIF(*COMPATIBLE) on the restore command for database objects this is equivalent to using ALWOBJDIF(*AUTL, *OWNER, *PGP, and *FILELVL) all together. Then the following would be allowed:
This is a big difference. For all other types of objects, *COMPATIBLE performs just like *ALL.
One important item to note, is that with 7.1, *COMPATIBLE is now the default for using the RESTORE menu options 21, 22, and 23 when restoring to a different system option is taken. This means you need to be extra careful and recognize the differences between releases when you restore.
Of course, we strongly recommend that everyone should be testing out their restore process at least yearly. If you need help with testing your restore, or a machine to test your restoration on, please contact Pete to setup an appointment.
| System Name.
Most parent’s spend quite a lot of time determining what their babies new name will be. What people will call their child, any abbreviations for the proposed name, will the baby have more than one name (Grandparents call the child one name, and friends another). Will they name it after someone in the family, etc. A lot of thought goes into what a child’s name should be. How is it then, that some system administrators don’t give more than 1 second in determining a partition or system’s name?
Last month I was at an account and the system had four different names. Four different names. This just creates confusion. Let’s look at places where the system name is defined: System Name, Host Table, Host Name, Partition Name, Remote Database Directory name, and the NetServer name .
First of all we have the system name that is displayed on the signon screen in the upper right-hand corner, on the WRKACTJOB screen, on the DSPNETA, and other commands. This is the real system name and should be the same as the other places you name your system. You change this with the Change Network Attributes (CHGNETA) command, and will usually require an IPL to complete the change. There is also a local control point name on the CHGNETA which should also be the same as the system name. I won’t get into the details of the differences here, but almost every time they are the same.
Next you have the Host name. You define this from CFGTCP command, and take option 12. This is the machine name according to TCP/IP, and should be the same as the machine name. This name can get resolved to a TCP/IP address either via DNS or via the host table. The host table is option 10 on the CFGTCP command. Most places will have an entry in here which connects the Host name to a TCP/IP address via an Interface (The interface is defined on CFGTCP option 1).
The next item to examine is the name of the partition. While this doesn’t necessarily need to be the same, it just makes good sense to call the partition the same name as the system name when you have an HMC or SDMC.
The next place is optional. I have seen some people who had NetServer defined from the early Windows 95/98 days and have a Q in front of their system name in NetServer, but if you aren’t using those older clients to connect to your IBM i, then I recommend using the system name.
Now, there is also the Remote Database Directory Entry name that needs to be looked at. You need to also be careful with this, because remote journals, ODBC, Remote SQL Connect statements all use this name. This is yet another name that you need to be aware of.
If your system name starts with an A, B, C, etc and then followed by your machine serial number, you took the default name when the system was created (most likely restored from another system). I think these are the worst names ever.
So, do the names have to be the same. No. But just think about the confusion that is created when everyone has a different name for the same thing. Confusion. Now, should you just drop this article and change everything to be the same. Absolutely not, because this takes some planning and time to figure out and understand the repercussions of a name change. This is where iTech Solutions can help, as we have the insight to know and understand what the issues are when you change each item.
Tuesday Sept 13 Omni User Group in Chicago:
Tuesday Sept 27 – Vermont User group:
October 3 to 5th, in St.Petersburg, FL at the COMMON Fall Event, Pete Massiello will present:
IBM i DevCon 2011 in Las Vegas at Planet Hollywood Hotel – Nov 2 to 4th.
|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. This is what we are installing for our customers on iTech Solutions Quarterly Maintenance program.
7.1 6.1 V5R4 V5R3
Cumul. Pack 11116 11102 11137 8267
Tech. Refresh 2
Grp Hipers 36 96 159 169
DB Group 10 20 31 24
Java Group 6 16 27 23
Print Group 3 21 44 20
Backup/Recov. 10 23 41 33
Blade/IXA/IXS 7 21 15 –
HTTP 9 21 28 17
TCP/IP 3 11 18 16
Security 6 22 17
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 an HMC, you should be running V7R7.3M0. If your HMC is a C03, then it should stay at V7R3.5 SP3.
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_403. Power 6 (940x M15, M25, & M50 machines, and 8203-E4A & 8204-E4A) customers should be running EL350_108. For Power6 (MMA, 560, and 570 machines) your FSP should be at EM350_108. If you have a Power6 595 (9119) then you should be on EH350_108. POWER7 the firmware level is AL730_035 for 8202-E4B (710, 720, 730, 740), AL730_035 for 750 (8233-E8B) & 755 (8236-E8C). Use AM730_035 for 770 (9117-MMB) & 780 (9179-MHB).
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.