Fall is now upon us, as we say goodbye to a fantastic summer. We did an unbelievable number of upgrades this summer. Last weekend alone I performed 3 upgrades to IBM i 7.1. All of them went very smoothly, with very few problems the morning afterward. This is the way upgrades are supposed to be!
Many of you have been asking me, about the Technology Refresh they are hearing about with IBM i 7.1. It is really just a new way for IBM to more quickly and easily bring new technology to the machine. For example, with 6.1 we had a second release of the license internal code (LIC), called 6.1.1. This required customers to reload their LIC in order to upgrade from 6.1 to 6.1.1, even though the operating system on top of the LIC stayed at the same release. Now with these new Technology Refresh PTFs, IBM can deliver this same new functionality with PTFs instead of a new version of the LIC. For example, all the new 7xx machines we discussed in last month’s newsletter require the Technology Refresh one (TR-1) PTFs. Currently installing these PTF’s is a royal-pain-in-the-butt because they require a double IPL during normal PTF processing, and the PTF processing actually fails when you are loading the 7.1 PTFs. However if you know what to expect, this isn’t really a problem, just a nuisance. IBM has also come out with a re-release of the I_BASE_01 CD for the LIC, which already includes these TR-1 PTFs in the base. So, if you are upgrading to 7.1, you will want to use the RSB version.
Of course if you don’t want to deal with any of this, just call iTech Solutions, and let us take care of it all for you. We can help you with those annoying upgrades, handle your PTFs by getting you on our quarterly maintenance program, perform a health-check, remote administration, remote hosting, replication, or anything else in the Systems Management or Administration area. We have the experience, the expertise, and the knowledge to help you.
We have packed a lot of information into this newsletter, and I hope that you find this useful. This issue of our newsletter has five articles. In the first, I want to discuss a command to document your IBM i license keys. The second article is on automatically moving I/O Adapters from one partition to another partition with a simple CL program. The third article is using tools on your machine to trace TCP/IP routes and addresses to and from a machine. The fourth article is a list of upcoming events we will be participating in. The last article is for your reference with updated PTF information.
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.
|Two weeks ago we were working with a customer to build their Disaster Recovery book, and we were talking about where they keep their software keys. Hopefully everyone has a Disaster Recovery book, that includes information about key people for the recovery with their phone numbers, where the tapes are stored, how the restoration should be performed, how you currently are performing your backups, numbers for your remote site, and other information you will need should you restore your machine. The customer couldn’t find their software keys anywhere, so I showed them a command for listing their keys.CALL QSFWINV *PRINT
This command will give you a list of the IBM i licensed software that you have installed, the actual keys, and what the expiration of those keys are (if any). You can take this output and place it in your Disaster Recovery book. These keys would be for restoring on your existing machine if needed, but it can also tell you what software you currently have keys for so that if you were restoring on a different machine, you would know which keys you require.
These are just some of the items you need to be thinking about. If you don’t have a system to which you can restore (if you only have one machine), we can bring a machine to your office, or you can just send us the tapes and we can restore it in our office. One of the services that we offer is the ability to test your recovery on one of our machines. We can also host your environment on one of our machines if you are looking at doing off-site replication.
If you haven’t done a test this year, you really have no idea the issues that you might have, or the items that may have changed from year to year in how you perform your backup strategy. I urge you to review your backups, contact us if you need help, but most importantly, test out your restore.
Moving I/O Adapters programmatically.
Many new machines that we install are having new LTO-4 Tape Libraries also installed with them. These tape devices are fast, can hold multiple tapes, and each tape can store almost 1.6TB of information on them. So on a multiple partition machine, you would want to share this tape drive amongst all your partitions. The problem comes when you have automated backups on each partition, you are expecting the tape drive to be on that partition to perform the backup, but there is no one in the computer room in the middle of the night to move the I/O adapter from one partition to the other. There goes your automated unattended backup. Well fear not.
John has developed a suite of CL commands, programs, and QShell execs that interface from your CL program directly to the HMC to tell the HMC to move a particular adapter from partition to partition. In all honesty the setup of this is a real bear, but once it is set up, it works like a charm. The best scenario is you can call these routines from your CL to actually move the adapters from one partition to another without any intervention.
What we are doing is talking directly from a CL program using SSH to the HMC, and directing the HMC with the CHHWRES command to move adapters from one partition to another.
This has reduced the need for a few of our customers to purchase multiple tape drives, and multiple adapters. Send John an email at firstname.lastname@example.org and let him schedule some time to implement this on your machine.
|Tracing TCP/IP Communication issues with NSLOOKUP & TRACEROUTE|
Have you ever been working on a communication problem between two machines, and you can’t understand why they won’t communicate? Most of us already use the PING command to see if there is another machine responding to a TCP/IP address. What happens if you want to know what is the address that my DNS server is providing? Most people familiar with communications will use NSLOOKUP, but the same functionality and a lot more can be obtained from the DIG command. Don’t get me wrong: NSLOOKUP is great for a basic query of the DNS Server, but DIG will provide some additional information and has a lot more options. DIG is a powerful query tool that allows you to retrieve information from or test the response of a Domain Name System (DNS) server. You can verify that a DNS server is responding correctly before you configure your system to use it. You can also retrieve DNS information about hosts, domains, and other DNS servers. Unless it is told to query a specific name server, DIG will try each of the servers listed in CHGTCPDMN.
The other command is TRACEROUTE. You can use either TRACEROUTE or TRCTCPRTE. The Trace TCP/IP Route command (TRCTCPRTE) traces the route of IP packets to a user-specified destination system. The route can involve many different systems along the way. Each system along the route is referred to as a hop. You can trace all hops along the route or specify the starting and ending hops to be traced. The route is traced by sending packets (called probes) to the destination system. Each probe contains an upper limit (called Time To Live or TTL) on the number of hop systems the probe can pass through.
This is a great command when trying to figure out why you can’t get from one machine to another, or if you are curious to the route a packet would take leaving one machine on its way to the target machine. Use this command to see how your machines in your environment are connected. We used this last month when we were trying to figure out why two machines in the computer room would take such a long time for a file transfer. It seems the network guys had the machines on two different subnets, and the traffic was routing from one building to another, and then coming back before getting to the computer in the same rack!
Here is a list of upcoming events that iTech Solutions will be participating in or that Pete Massiello will be speaking at:
October 3 to 6 COMMON Fall Conference www.common.org San Antonio, TX Topics:
1) Upgrading to IBM i 6.1 & 7.1
2) HMC, FSP, IBM i: You need to know what these do.
3) Performance tuning tricks
4) Creating Virtual IBM i LPARs on hosted IBM i.
October 19 – Fairfield CT AS/400 Users Group (FASUG), www.fasug.org Norwalk, CT. Topic: Upgrading to IBM i 6.1 & 7.1
October 20 – Long Island Systems User Group (LISUG), www.lisug.org Woodbury NY. Topic: HMC, FSP, IBM: You need to know what these do.
October 21 – North Eastern System Technology Users Group (NESTU), www.nestu.com Fairfield NJ. Topic: Upgrading to IBM i 6.1 & 7.1
October 26 – IBM Power7 for IBM i customers.1:00pm Warwick New York Hotel, 65 West 54th St., New York, NY
November 15 to 17 iSeries Dev Conn www.iseriesdevcon2010.com Las Vegas, NV Topics:
1) Everything you need to know to upgrade IBM i (i5/OS) to IBM i 6.1 or 7.1
2) Building virtual i partitions hosted by IBM i – no additional hardware required!
3) Putting the pieces together: Understanding your options with HMC, FSP, and firmware on the IBM i
4) Tips and tricks to improve system performance and save disk space
5) Everything you need to know to get started with the new Systems Director Navigator Console
April 11 to 13 Northeast User Groups www.neugc.org Framingham, MA
|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 10229 10215 10117 8267
Grp Hipers 12 71 136 169
DB Group 3 15 27 24
Java Group 3 13 24 23
Print Group 1 18 41 20
Backup/Recov. 3 16 34 33
Security Group 3 18 15 7
Blade/IXA/IXS 2 17 14 –
Http 2 14 24 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 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 V7R7.1 SP2. If your HMC is a C03, then it should stay at V7R3.2 SP1.
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_071. For Power6 (MMA, 560, and 570 machines) your FSP should be at EM350_071. If you have a Power6 595 (9119-FMA) then you should be on EH350_071. POWER7 the firmware level is AL710_086 or AM710_086 depending on your model.
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.