Potpourri
Recently, I have begun working on a new project with my associate. His experience has been almost entirely on the System/36, and judging by some of his questions and some of the problems he had, there are a few basic things that you will need to master to become a productive AS/400 programmer. Because these things don't fall into any one area of knowledge, I've included them in this month's column as a series of things to investigate.
Know where you are
One of the areas my friend found confusing was locating printouts. When I configured my AS/400, I allowed the system to create the device names, and with two printers, I ended up with devices PRT01 and PRT02. I also have output queues PRT01 and PRT02. Usually, we only have PRT01 (an HP Laser) turned on, and by default our printouts go into output queue PRT01. However, rather than print everything, I merely have device PRT01 print from output queue PRT02. We first look at the printouts with WRKOUTQ PRT01, and if we decide we need a copy, we use the "change spooled file" option on that display to move it to output queue PRT02.
Some difficulty often occurs when the device name is confused with the output queue name. It is unfortunate, in this case, that the device and the queue have the same name. The thing to remember here is that printouts go to an output queue, and you can then start a "print writer" (a printer) by telling it to print from that queue.
Another point of confusion is trying to locate the message queue where printer messages are sent, such as "verify alignment" and "end of forms." You can locate the message queue with the WRKWTR (Work with Writers) command, and then possibly display messages from the message queue used with the writer. If all else fails, wait until the printer finishes printing, then use the ENDWTR (End Writer) command with the *IMMED option. You can then issue a new STRPRTWTR, and tell it the device and output and message queues that you want to use.
If you feel uncertain about how this business works, you should put a few short printouts into some output queues (screen prints will be just fine). Then try starting and ending the writer, and working with different output and message queues. You really need to be clear on this, as there is almost nothing more frustrating than not being able to get something printed when you want it.
Get your messages
Another thing that you should do is change your message queue to *BREAK mode. If you don't know the name of your message queue, type in DSPMSG and note the name of the queue shown on that display. If you have more than one message queue for your session, change them all to *BREAK. Though it's sometimes annoying to have messages popping up in the middle of your work, I've found that preferable to waiting for something to happen, then finding out that the system is waiting for a message to be answered.
Working with the system
I have always felt strongly about this next point since the AS/400 introduction, and haven't seen anything yet to change my mind. If you will be doing a lot of programming work, I think you're far better off to use the Command Entry display (CALL QCMD), rather than PDM or the "programmer menu" or whatever else IBM has put together. Why? Because the Command Entry display maintains the running list of everything you've done in that session, with messages along the way. I know that you can use the Cmd9 technique from displays that supply a command line to "retrieve" a previous command, but that is almost unusable if the command you want is more than a few entries back.
With the Command Entry display, you can roll the whole display back and see the commands that you used, and rerun any of them. You can also see if you entered any commands that might still be affecting things, like OVRDBF and CHGLIBL.
Most people don't like to use the Command Entry display, because it involves more "typing" than selecting numbers off a PDM menu. I don't worry about typing long commands, since I usually prompt for anything if there is more than one parameter. Typing the commands, prompting and getting to see the command parameters has helped me learn about the commands far more quickly and comprehensively than having the system fill in defaults that I never get to see.
When you get into trouble
My friend had an awful time just getting some programs to compile. In fairness, it was a miserable job: to convert some S/36 code to use external files. Getting the program to compile, as we know, is usually just the beginning of the troubles. When he ran it, it promptly failed.
One of the first experiences you will have when programming the AS/400 is seeing the "horizontal line" message. That is, a cryptic message appears on your screen with a question mark followed by a screenwide underline, asking you to cancel, ignore or otherwise dispose of the message.
The first thing to be aware of is that if you cancel (reply "C"), you may get other similar messages following. Practically speaking, the subsidiary messages are of no value, since the first message caused the problem. The "cascade of problems" is generally not interesting or worthy of attention until you fix the first problem. If you keep getting messages, no matter how many "cancels" you enter, you should cancel the program with the System Request, Option 2 (cancel) procedure.
If you are using the Command Entry display, you can use Cmd10 once you are back on the display to see the messages from the most current program. The one that caused the problem will probably be up near the top, although there may have been a few messages before that. You can read the complete description of the message by moving the cursor up to the line with the message and pressing HELP (I sure wish AS/400 terminals had a mouse . . .). You are usually looking for "escape" messages, since unmonitored escape messages cause the "line drawing" message to appear. You may have some "diagnostic" messages before the escape message. You should review those also, and determine if you need to do anything. If you're just starting with the AS/400, the diagnostic messages will probably be inexplicable, such as "open of file changed to sequential only." Rather than paying too much attention to those, focus on the escape message, and try to understand what it is telling you.
When you're first starting, the messages seem to indicate certain predictable troubles: decimal data errors, problems opening files and assorted objects not found. Decimal data errors either have to be fixed in the file or in the program. Opening files, after you're sure that they can be found, either must be done with the name in your program or by using an OVRDBF command; You also have to ensure that the opened file agrees with what the compiler used when it created your program. It's useless to find a file with the correct name if the record format is different. As far as finding various objects, you have to be aware of your current library list, and what things you need when you run the program. For example, if your program calls other programs, make sure they are available. If you reference data areas, commands, files other than database files, make sure those can be found.
The Dump
At an early point in your AS/400 programming experience, you should request a dump when you get a hard-halt error. You'll be doing yourself a favor if you start with a small program, one that uses no more than three or four files, for reasons that will be obvious. The option that you want to take is the "D" option, not the "S" (system dump) option.
The "D" option is for a "formatted dump" of your deviating program. By formatted, we mean that you can see the name of every variable and indicator used, and the value of them at the moment that you request the dump. Since you are requesting it right at the point of the error, you are getting all the information you'll probably need to help locate, understand and correct the error.
The formatted dump starts with a quick summary of the problem, with some identification of the program, the run date and time, compile date and time, and so on. Don't skip past that first page; look at it and verify that the program is the one that you thought you were working with. I have often compiled a new version into one library, then promptly turned around and tested, only to have it crash immediately. This happened because I was testing a program of the same name, but in another library.
Next in the dump, you'll get a page for each file. This tells you the status of the file, the actual object and location of the file, and a summary of all activities against the file. This is important information, as you'll want to verify that the file is the one you want. It's also useful to check on I/O activity; for example, if the dump shows that 10 records have been read so far, that gives you a clue as to how many cycles the program completed.
The biggest section is usually the listing of the variables and their values. If you narrow down the problem to a section of the program calculations, then you can turn to that section of the program and work backward. Using the dump, you can pencil in on your source, listing the values. For RPG, you'll especially want to be aware of the indicators. However, if the problem isn't in the calculations, but is in the input of output sections, then you'll want to review the buffer for the file and see what came in or tried to go out. The RPG manual tells you how to associate the dump buffers with the files in your program.
Know your objects
It takes discipline to set up an AS/400 for programming and production so that you can easily and intuitively locate objects. If your shop has imposed standards, then you should work with those standards if they make sense. If you encounter a standard that really doesn't make sense and everyone agrees that it doesn't, then change the standard. It's not really much fun to backstep and relocate things, but I've done it more than a few times after becoming convinced that continuing with a faulty standard was going to become more troublesome as time went on.
Your primary tools for knowing where things are, are your library list, the library list of any "job descriptions" that you use, and the WRKOBJ (Work with Objects) command. Simply, you must always be aware of what your library list is. If you don't know, type in the DSPLIBL (Display Library List) command. Be careful about your current library since defaults may be taken when you create objects. Although I understand the purpose of the current library on the CRT (Create) commands, I still prefer to type in the actual destination library name. Just in case the current library is not what I thought it was.
If, despite your careful attentions, you create something and then can't locate it, use the WRKOBJ command to find it. You can specify objects to work with, the type of object, and a library or set of libraries to search. If you get desperate, you can have the command search all libraries on your system. This could take a while, but if you can't find an object any other way, this is the quickest way to locate it.
There are some other reference commands that you'll want to become familiar with, since these commands tell you how things actually are, which may be different from how you think they are. For example, there is DSPPGM (Display Program) and DSPCMD (Display Command), which tell you the creation dates and times, and the source files used to create those types of objects. The DSPCMD command is also useful for finding the command processing program (the program that executes when the command is used). For files, you can use DSPFD (Display File Description) and DSPFFD (Display File Field Description) to review what is in the file. DSPDBR (Display Data Base Relations) will tell you the names of all logical files built upon a physical file. You should use this after you create a logical file, just to verify that the "built on" files are the ones that you wanted. A nice feature of OS/400 is that it does keep track of its objects, and lets you see that information. When you're trying to track something down, start with "primary sources," which are the actual objects themselves. The source is only part of the story.
When we return
At this time, I will have to take a break from this column, since I have some pressing matters I must attend to. I've enjoyed writing the column over the past several months, and I hope you have enjoyed reading it. You'll be hearing from me again soon.
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