A road trip checklist. Don't leave home without it!
Scenario one: You are a project manager at an AS/400 software company. The president of the company asks you for a tape of presentation programs he will use in making a sales pitch to a large customer. You provide the tape but he is unable to load it on the client's machine because you gave him a tape reel and the client only has a tape cartridge drive. The presentation fizzles along with your credibility.
Scenario two: You have a weekend to bring up a system conversion at a remote site. You fly out on Friday afternoon and begin work that night. Everything goes well until Sunday morning when you have to write a quick RPG conversion program. You sit down at the AS/400 only to discover that neither the RPG compiler nor the Program Development Manager is available on the machine. If you cannot write this translation program, there will be no way to bring up the conversion Monday morning as expected.
The Twilight Zone? Hardly. These are actual incidents that occur in AS/400 remote site sales, service and maintenance calls. These twin nightmares share a common theme: both situations could have been avoided with some pre-trip planning and common sense. If you install or upgrade software across multiple AS/400 sites, what can you do to avoid the problems listed above? How can you know you have your bases covered when you go out on a remote install?
This article addresses those concerns and gives you a checklist to follow when you go out of town in a remote support situation. Most of the ideas stated here are from my own experience in supporting computer installations across the United States. I have wasted time, money and credibility making mistakes on the road that could easily have been avoided. I hope my road trip checklist will save you some embarrassment and stress when you go on the road.
What Shall I Pack?
You have received your assignment and you are ready to gather your materials. What should you do next? The first thing is to know what AS/400 objects you need to install on the remote machine. This sounds obvious, but forgetting one necessary file or program can make all the difference when you get out there. Make a list of your objects and review it often. Remember, it is easier to add an object to a tape now than it is to transmit it across a telecommunications line or send it overnight by UPS later.
Who Will I See?
Next, you need to determine which people are going to help you make your trip successful. You must find the following people who will help you when things go wrong (and they will).
The first person you need to know is your main on-site contact. This person will help you get in the door, obtain any security clearances you may need and probably supervise you informally while you do your work. Ask if your contact will be available that week. Once I arrived at a remote site only to find my contact was home on comp time because he had been in the center all weekend recovering from a system crash. It took me a considerable amount of time to find his backup. If you are counting on key personnel, make sure they are available and get the names and phone numbers of some backup personnel.
The second person to find is the local IBM representative who services the account you are visiting. Again, ask whether or not the rep will be available that week. In a pinch, you may have to get this person to install IBM software, make compatible installation tapes, or just smooth out some system problem you are encountering.
Another good phone number to have is the number of your own local IBM representative. This may sound strange but, as you will see later, it can help in ways you had not considered.
What Kind of Hardware Do They Have?
An important question to ask if you are bringing tapes to a remote site is: What kind of tape drive do they have? You do not want to be in the position of the company president at the beginning of this article who brought a reel tape when all the installation had was a cartridge tape drive. Check to see what kind of tape drives they have and save accordingly. If you do not have the matching tape drive on your system, contact your local IBM rep to see if he can help you create the tape you need.
Also find out what density your tapes should be formatted at. We have a cartridge tape drive at our company. One of our customers has a high-density cartridge tape drive. We cannot just initialize a tape on their AS/400 and expect to run it on our machine. First, we have to specify a density in the Initialize Tape (INZTAP) command that is compatible with our drive. Failure to pay attention to tape drive details such as densities may render any tape you are trying to install unreadable.
The final tape question involves situations where you will be restoring tapes to multiple AS/400s. Another one of our customer locations has four AS/400s. Three of the four machines have cartridge tape drives; the fourth machine has a reel tape drive. When our sales representative first went out to install software on these machines, he had the proper tapes to install three out of four machines but he had to scramble to get a new installation tape for the fourth.
Hardware is not restricted to tape drives. If the install/demo requires a special printer, or PC Support, or graphics, make sure these are available. It pays to check the hardware on all machines you've targeted for software installation.
Tape, Savefile and Program Woes
When you are installing software, you need to do a little research before making tapes or savefiles to bring with you. A number of things can happen if you take this step for granted, including:
Source and object code that cannot be restored to the target system
Programs that will not run on the target machine
Loss of valuable travel time in getting replacement tapes or savefiles to the remote sites
The worst of these situations is something I call SAVOBJ Syndrome. It involves problems with object restoration from a savefile or tape. SAVOBJ Syndrome happens this way.
You need to restore something to a remote system that is running a prior version of OS/400. You save the objects from your system by using the Save Object (SAVOBJ) or Save Library (SAVLIB) command.
When you get to the site, OS/400 will not let you restore the objects because they were saved on an OS/400 operating system that is more recent than the remote site's operating system and the objects were saved without using the *PRV option on the Target Release (TGTRLS) parameter of the SAVOBJ or SAVLIB command.
Essentially, this means the tape or savefile you brought along is worthless and cannot be used on the system. Because of this, you must recreate the tape or save-file on your original system with the right parameters on the SAVOBJ or SAVLIB command. Then you must have the tape overnighted to the remote location or have the savefile transferred by modem. In either case, you have lost valuable time in completing your assignment. This is the SAVOBJ Syndrome at its finest.
This will happen if you are restoring something from V2R2M0 to V2R1M1, or from V2R1M1 to V2R1M0 or from V2R1M0 to V1R3M0. Because of differences in save and tape file formats between operating system versions, OS/400 must format the tape or save- file in the format used by the earlier version. It does this by specifying, through the TGTRLS parameter of the SAVOBJ or SAVLIB commands, that the objects are going to be restored to an earlier version of OS/400. This is a necessary but annoying trap to protect the integrity of objects going to earlier versions of OS/400.
Another piece to saving objects for use on a previous release of OS/400 is making sure the objects are created for the correct release. Before you save your programs, recompile them with *PRV in the TGTRLS parameter of the CRTxxxPGM command if you are going to restore them to the prior OS/400 release. Beginning with V2R1M1, target release support has been refined to allow you to be modification level specific. Not only can you specify a TGTRLS of *CURRENT or *PRV but you can explicitly describe the version, release and modification level of the target machine. For example, the TGTRLS parameter can be V2R1M0 or V1R3M0. When V2R2M0 is available, the target release could be V2R1M1 or V2R1M0. You can retrieve this information from your main contact at the remote system or from the remote site IBM rep.
If you will be creating your tapes or savefiles on an AS/400 that is pre- V2R1M1, specify *PRV on the TGTRLS parameter of the SAVOBJ or SAVLIB command. This will enable you to restore the objects to a machine that is running the OS/400 release that immediately preceded the release you are running.
If you are using V2R1M1 or higher of OS/400, you can be more specific and indicate the version, release and modification level (V2R1M0 or V1R3M0) just like you can for the CRTxxxPGM commands.
There is one important point
to note with previous release support. You cannot go back more than one release. If you need to go back more than one release, contact your own IBM representatives to see if they can help you convert your tapes to the proper release and version number.
There is a catch to using TGTRLS. IBM will not guarantee downward compatibility if your restored object is using features that are available only in the more recent operating system. It's worth mentioning that the target system may be at a higher release level. Theoretically, this shouldn't cause you any problems but occasionally the QUSRTOOL library changes from release to release.
Roadside Repairs
Our second example in the introduction talked about the AS/400 professional who needed development tools in a crunch and did not have them. Check to see whether the development tools that you need will be available. There is nothing worse than needing an RPG editor and compiler to correct a bug and finding out that you do not have it.
Again, this is where the remote site's IBM representative comes in. If you need development tools and they are not present, contact the rep and make sure they are installed before you arrive. If the rep cannot install them, delay the trip until they can be installed. Sometimes the IBM rep may send you a tape with the licensed programs and ask you to install them yourself when you arrive. Be careful in this situation. An IBM rep once sent me an installation tape for RPG and it turned out that the RPG library on the tape was saved on V2R1M1 without the *PRV command. I could not load it on the V2R1M0 machine. It is best to make sure IBM does the installation before you get there.
Development is more than just having the right software tools. You may need manuals to look up information, verify or fix code and use for reference. If an installation does not have RPG installed, it will not have RPG manuals. Ask your local contact if the AS/400 manuals you need are available on-site. If you need additional manuals, take them with you, express mail them to the location, photocopy the pages you need or ask the IBM rep to have them available for you on-site when you arrive. This includes CLP, COBOL, Communications or any other manuals you may need. I have worked with government organizations that save money by not purchasing AS/400 manuals. When I went for the information I needed, it was not there. I later found out they did not even have CL manuals for their operators to perform system maintenance.
When Can I Work?
Additional questions that need to be asked involve the best times to work and what factors might affect your ability to work.
I once worked with a nonprofit organization that asked all systems personnel and consultants to work from one in the afternoon to eight at night. This was because the AS/400 we were working on was so maxed out that having consultants, who were usually heavier users, on the machine at peak hours slowed things down too much. This type of arrangement may affect your travel plans. If you work with an organization like this, you may want to catch a morning flight and save yourself one night of staying in a hotel. Similarly, you may need to work late on the final day of your stay and catch a morning flight out the next day. If you know what your working schedule will be, then you can plan your travel around it.
Another time I worked with a defense contractor in Texas whose tight security precautions meant that I needed an escort to go to the restroom. In this situation, my movements were limited and I was dependent on someone always being present to do anything. If key personnel could not stay late, I was unable to work at night. In a case like this, it may be wise to either plan extra days on the road or arrange ahead of time for someone to work late with you in the evening.
Is Going on the Road Worth It?
In spite of the potential frustrations listed above, going on the road can be a very rewarding experience. You get a chance to break out of your enclosed development environment and see things from the perspective of the people who use your software. It is also rewarding to see your well-written software run on another machine. However, be sure to ask some of the questions brought up in this article or you may wind up taking a road trip detour through The Twilight Zone.
The Road Trip Checklist
1. What objects and programs do I need to install on the remote machine?
2. Name and phone number of the on-site contact I will be working with.
3. Name and phone number of the IBM representative that handles the on-site account.
4. Name and phone number of my local IBM representative.
5. Release of each machine I will be installing software to.
6. If using a tape drive to restore objects to the remote machine(s), what type of drive is it (reel, cartridge, 8mm, etc.)?
7. At what density should the tapes be formatted?
8. Will the printers and displays provide the support needed?
9. Is PC Support required and will I be enrolled to run it?
10. If installing tapes to multiple locations, do all locations have the same tape drive hardware? If no, answer questions 6 and 7 for each machine that has different hardware.
11. Were all programs created with the proper Target Release parameter to run on the remote machines?
12. Were all tapes and savefiles created with the proper Target Release parameters so they can be restored to the remote machines?
13. Are all the required development tools currently loaded onto the remote machine(s)? If not, will the IBM representative load them before arrival?
14. Are AS/400 manuals available at the remote site? If not, have arrangements been made to get the needed documentation on-site?
15. What are the working hours I will be expected to keep? Will I have open access to the site or will someone always have to accompany me?
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online