The normal scenario for programmers is as follows: You submit a program for compilation, but receive a message stating that your program has terminal errors. You type WRKSPLF to get to the spool file. You then select the spool file that contains the compile listing of the failing program. You manually start jotting down the errors and statement numbers, if any. You then exit the spool file and return to your program to make the necessary corrections.
I believe if you try this new approach you'll never return to the old way. Once you've received the message that the program didn't compile, do the following:
Go back to edit the program with SEU.
Press F15 to go to the Browse/Copy selection panel.
Place a 2 in the selection field, and press Enter. This automatically brings in your last compile for the program you're editing. Use the on-line help for further information on the Browse/Copy spool file parameters if you need to.
You now have the compiled program with errors in the lower screen and the source to be edited in the top screen. This allows you to find the errors below and quickly make the corrections at the top without having to jot anything down or trying to remember what the jotted stuff means.
The really slick feature of SEU is the FIND *ERR command (that can be abbreviated F *ERR), which you type at the SEU===> command line in the lower screen. SEU will take you directly to the compile errors. The error message is presented at the bottom of the screen with your cursor at the error message number. You no longer have to go to the bottom of the compiled listing and start scanning for error line numbers.
Editor's Note: We have tested this technique and found that it works for member types CLP, RPG, PLI, PF, LF, DSPF, PRTF and CMD. We didn't test any others.
While SEU shows the compile listing in the bottom half of the screen and you execute the FIND *ERR command, the message is shown highlighted on line 24 with the cursor positioned at the spool file line that lists that error. Something Greg forgot to mention is that you can move the cursor to the message in line 24 and press the Help key--and get second-level help information about the error message! How's that for convenience?
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