ckangas7
asked on
How to troubleshoot failing control language program
I am a newbie AS400 student and am learning from a course. I wrote and compiled a simple control language program. However, when I call the program I get the error "Processing command failure, refer to job log for details." I tried using wrkjoblog and wrkactjob but couldn't find the log I was looking for. Where can I find this log? Also, is the job log my primary tool for troubleshooting a failed program or are there other better options. Course doesn't really seem to cover that. Thanks in advance for your help.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks much!!!! Problem was I failed to set the LOG parameter to YES when I compiled the program. Lots of great info.
ASKER
Thanks much for a lot of great info. Problem was I failed to turn on the LOG option when I compiled the program. After that I was able to see my error in the joblog. The logging level was already set to 4. A related question would be how can you know the name of the job that is running your program? Is that something you can set during compile, or does the AS400 simply create and name a job automatically each time you do a call?
ckangas7:
There are two general kinds of jobs that your program will be running in -- interactive and batch. (There are many other kinds of jobs, but all jobs that will be running a CL program that you wrote will break down into those two categories.)
An interactive job is one that has a terminal session. If you use telnet and issue a CALL command on a command line or take a menu option that results in a call to your program, then your program will run in your "interactive" session (job). This is like a "foreground" process on some other systems.
A batch job is one that resulted from a SBMJOB command (mostly). If you use telnet and issue a SBMJOB command on a command line or take a menu option that results in a SBMJOB command, the submitted job is a batch job. This is like a "background" process on some other systems. A SBMJOB command will include a parameter that results in a program being called; if that program is your CL program or that program calls your CL program, then your program is running in batch.
It usually isn't necessary to determine the name of your interactive job. If you enter the DSPJOB command on a command line, for example, you don't need to specify the name of any job. The default job is the job that the command is running in. You only need to supply a job name if you want to display some other job.
When you use SBMJOB, one of the parameters is the name that you want to use for the batch job. There is a default name, but it's a good idea to supply the desired name. When SBMJOB runs, it shows a message that tells what name the submitted job was given.
In a lot of early testing, programs are simply called from a command line. Assume you named your program MYCLPGM. You could enter this at a command line:
==> call myclpgm
...and press [enter]. Your CL program would begin running interactively, in your interactive job. Any messages logged to the joblog would go into the interactive job's joblog. There wouldn't be another joblog for your program.
Once the program finished, you could access the joblog by running a DSPJOBLOG command. Another way to access the joblog would be by running a DSPJOB command; this would bring up a menu of options that can be taken, one of those options displays the joblog. Interactive jobs are just about that easy.
When you want to display the joblog of a batch job, you need to know what name was given to the job. Usually, since you supplied the name, you'll know what name to give to the command.
Also, the system keeps track of batch jobs that you started. The WRKSBMJOB command lets you bring up a list of them all and you can select the one you're interested in. There are three ways you can ask for the list -- *USER, *WRKSTN and *JOB.
The WRKSBMJOB *USER variation will bring up a list of all jobs that you have submitted (as long as they still exist in some form in the system). They might be jobs from yesterday or six months ago. As long as your UserID was the one that ran those jobs, they'll be on the list.
The WRKSBMJOB *WRKSTN variation will bring up a list of jobs that were submitted from the same interactive session name. If you start up a job under the session name DISPLAY01, then all jobs submitted through sessions named DISPLAY01 will be listed, regardless of who used that session device or when it happened.
The WRKSBMJOB *JOB variation limits the list to those that were submitted in the current session. If you log off and back on, then you're in a different session. If someone else logs on to the same terminal device, then that's a different session. This is the variation that I find myself using the most. Usually I'm interested in batch jobs that I'm creating through my current session.
Tom
There are two general kinds of jobs that your program will be running in -- interactive and batch. (There are many other kinds of jobs, but all jobs that will be running a CL program that you wrote will break down into those two categories.)
An interactive job is one that has a terminal session. If you use telnet and issue a CALL command on a command line or take a menu option that results in a call to your program, then your program will run in your "interactive" session (job). This is like a "foreground" process on some other systems.
A batch job is one that resulted from a SBMJOB command (mostly). If you use telnet and issue a SBMJOB command on a command line or take a menu option that results in a SBMJOB command, the submitted job is a batch job. This is like a "background" process on some other systems. A SBMJOB command will include a parameter that results in a program being called; if that program is your CL program or that program calls your CL program, then your program is running in batch.
It usually isn't necessary to determine the name of your interactive job. If you enter the DSPJOB command on a command line, for example, you don't need to specify the name of any job. The default job is the job that the command is running in. You only need to supply a job name if you want to display some other job.
When you use SBMJOB, one of the parameters is the name that you want to use for the batch job. There is a default name, but it's a good idea to supply the desired name. When SBMJOB runs, it shows a message that tells what name the submitted job was given.
In a lot of early testing, programs are simply called from a command line. Assume you named your program MYCLPGM. You could enter this at a command line:
==> call myclpgm
...and press [enter]. Your CL program would begin running interactively, in your interactive job. Any messages logged to the joblog would go into the interactive job's joblog. There wouldn't be another joblog for your program.
Once the program finished, you could access the joblog by running a DSPJOBLOG command. Another way to access the joblog would be by running a DSPJOB command; this would bring up a menu of options that can be taken, one of those options displays the joblog. Interactive jobs are just about that easy.
When you want to display the joblog of a batch job, you need to know what name was given to the job. Usually, since you supplied the name, you'll know what name to give to the command.
Also, the system keeps track of batch jobs that you started. The WRKSBMJOB command lets you bring up a list of them all and you can select the one you're interested in. There are three ways you can ask for the list -- *USER, *WRKSTN and *JOB.
The WRKSBMJOB *USER variation will bring up a list of all jobs that you have submitted (as long as they still exist in some form in the system). They might be jobs from yesterday or six months ago. As long as your UserID was the one that ran those jobs, they'll be on the list.
The WRKSBMJOB *WRKSTN variation will bring up a list of jobs that were submitted from the same interactive session name. If you start up a job under the session name DISPLAY01, then all jobs submitted through sessions named DISPLAY01 will be listed, regardless of who used that session device or when it happened.
The WRKSBMJOB *JOB variation limits the list to those that were submitted in the current session. If you log off and back on, then you're in a different session. If someone else logs on to the same terminal device, then that's a different session. This is the variation that I find myself using the most. Usually I'm interested in batch jobs that I'm creating through my current session.
Tom
In the character-based 'green' screen, you would put option 14 beside the source member name to compile.
To see your own joblog, use DSPJOBLOG command. Press F10 to get the lower level details, and roll-up to see the errors.
Hope this helps!
Barry