What Happened to My Backup?
February 14, 2007 Hey, Joe
|
My automated tape backup job just stopped working. It was working fine last week, but when I try to run any of the i5/OS Save commands (SAVOBJ, SAVLIB, SAV, etc.), the command fails with a CPF4380 message (“Open attributes not valid in a multithreaded job”). I can manually back up my data, but I can’t use my usual backup routine. What’s going on here and do you have any idea why my automated backup suddenly started failing? –Jim In spite of a scary scenario when your backup stops running, this problem is actually very easy to solve. Here’s what I think is happening in your shop. In i5/OS V5R4 and OS/400 V5R3, as well as in earlier versions of OS/400, the QSYSTAP device is the name of the tape device file that the system uses for input/output operations during Save and Restore commands. Like many other i5/OS files, QSYSTAP is not eligible to be opened in multithread-capable jobs. According to IBM, the only files that can be opened in multithreaded jobs are Integrated File System stream files, printer-files, save files, IP-based distributed data management (DDM) files, and local database files. If you try to open any other types of file objects (*FILE) inside a multithread capable job, i5/OS will issue a CPF4380 message containing the following text:
Message . . . . : Open attributes not valid in a
multithreaded job.
Cause . . . . . : The open of file &2 in library &3
device &4 failed because this job is multithreaded and
one of the following attributes has been specified.
- The file being opened is a type of file which is not
supported in multithreaded jobs.
- SPOOL(*NO) was specified on an Override with Printer File
(OVRPRTF) command, in the program, or on the file.
- A save file was opened when more than one thread exists.
Recovery . . . : Correct the attributes which caused the
failure and try the request again.
Because QSYSTAP isn’t designed to run in multithread capable jobs, tape backup operations will automatically fail when the running job’s Allow multiple threads parameter is set to *YES. So my strong suspicion is that Allow multiple threads was recently reset to *YES for the job running the backup, and that is what’s causing your CPF4380 problem. This theory is easy verified by checking whether or not the job is multithread capable. The easiest way to do this on the green screen is by running the Display Job command for the running job and taking option 2, Display job definition attributes. You’ll find the job’s Allow multiple threads setting on the fourth screen that appears after selecting option 2. If this setting is set to *YES for the job running your backup, it’s almost a certainty that this is what’s causing your problem and changing Allow multiple threads to *NO for your job will take care of the issue. What’s happening is that all jobs retrieve their multiple threads setting from the job description used when the job starts running. The name of the job description being used for your backup job can also be found under option 2 of the DSPJOB command. Once you’ve found the job description that is making your backup job multithread capable, you have two options: you can either change that job description’s Allow multiple threads parameter (ALWMLTTHD) to *NO or you can change the job to run under another job description that already has an ALWMLTTHD setting of *NO. To change the ALWMLTTHD setting in a job description, use the Change Job Description command (CHGJOBD) to switch the ALWMLTTHD setting from *YES to *NO. Then end and restart the job performing the backup and the CPF4380 failure will disappear. If you opt to give your job a new job description rather than changing its existing one, there are two ways to change the job description that a job runs under. If your backup job is submitted to batch, you can designate a different job description to use under the Job Description parameter (JOBD) on the Submit Job command (SBMJOB) that submits the job. By default, SBMJOB uses the job description that is assigned to the user profile that the job is running under, but the job description name can be overridden by specifying a different job description name in the command’s JOBD parameter. For scheduled jobs that are entered through the Work with Job Scheduled Entries command (WRKJOBSCDE), you can change the job description name under the entry’s Job Description parameter (JOBD) and that job description will be used when the job is submitted for batch processing. If you are interactively running your backup (say from the GO SAVE menu), the job’s ALWMLTTHD setting is retrieved from the job description associated with the user profile running the job. For interactive backups, you can change the ALWMLTTHD setting by changing the job description already assigned to your backup user profile. You can also assign a different non-multiple threaded job description to your user profile’s Job Description parameter (JOBD). To change a user profile’s JOBD parameter, use the Change User Profile command (CHGUSRPRF). Once you have made this change, have your user sign off and sign back on the system, and he should be able to backup your i5/OS objects again. Anyhow, that’s my take. I’m almost 100 percent certain that the ALWLMTTHD setting is your issue because the CPF4380 issue often occurs in multithread capable jobs. –Joe RELATED RESOURCES Data management considerations for multithreaded programming IBM eServer iSeries Information Center, Version 5 Release3
|
