Free job scheduling support is built into V2R2MO of OS/400
Brief: Every data processing shop schedules jobs, either manually or via an automated system. The new job scheduling support built into OS/400 makes it easier to set up batch jobs that must run on a regular basis or jobs to run at a future date. The job scheduler also allows you to determine what recovery action is needed if the job cannot be submitted at the scheduled time. Two members of the job scheduler development team take you on a guided tour of this new facility.
Have you ever stayed late at work in order to submit jobs that needed to run after everyone else has left? Do you get tired of always submitting the same job on a particular day of the week or month? Have you ever forgotten to submit a job that was supposed to run at the end of every month or at the end of the year? If you answered yes to any of these questions, you could benefit from job scheduling.
Generally, job scheduling is the ability to control when jobs perform work on your system. Specifically, AS/400 job scheduling, new with V2R2M0 of OS/400, allows you to control when batch jobs are submitted to a job queue or when batch jobs become eligible to start from a job queue. The exact definition that applies to your work depends on the form of AS/400 job scheduling you choose to use.
The Mechanics of AS/400 Job Scheduling
The job scheduling support which our team developed for V2R2M0 of OS/400 involves a new system job, QJOBSCD, which acts as the controller for all jobs that use the job schedule support and a job schedule object (type = *JOBSCD), QDFTJOBSCD in QUSRSYS. Once job scheduling is initiated by one of the methods discussed later in this article, QJOBSCD remains in a wait state, waking up periodically to submit jobs at their scheduled time. Details concerning QJOBSCD are covered in the sidebar on page 29.
For the first method of job scheduling, OS/400 currently supports a single job schedule object with multiple job schedule entries. Each job you schedule becomes a job schedule entry in QDFTJOBSCD, much like a member in a source physical file. An entry defines when a job should be submitted by the new QJOBSCD system job and which parameters should be used.
The second method for scheduling a batch job makes use of two new parameters, Schedule Date (SCDDATE) and Schedule Time (SCDTIME), on the Submit Job (SBMJOB) command. SBMJOB places a job on the job queue just as it has done in previous releases. If a value other than *CURRENT is specified for either of the SCDDATE or SCDTIME parameters, the job is placed on the job queue in a "scheduled" status. When the defined time arrives, QJOBSCD makes the job ready to run.
The SBMJOB method is simple to use, and it enhances a command already familiar to customers. It's an easy way to schedule a job that you want to run only once, and it also allows you to use many of the job attributes defined for your current job. The drawback to this method is that there is no way to save the scheduled job queue job. If you experience a system crash and need to restore your system, these scheduled jobs are lost.
This situation does not present a problem if you use job schedule entries. You can easily save and restore your entries since they reside in a separate, permanent object. Another advantage: you can define jobs to be submitted once or repeatedly at specified times. In this manner, the first method gives you much more extensive support than the SBMJOB method. Because of these advantages, we'll concentrate on the job schedule entry method in the discussions that follow.
How to Use Job Scheduling Effectively
The new commands listed in 1 let you control and modify job schedule entries.
The new commands listed in Figure 1 let you control and modify job schedule entries.
When you want a job to be submitted at a later date and time, your first step is to set up a job schedule entry with the Add Job Schedule Entry (ADDJOBSCDE) command. With this command, you specify values that control when and how often the job should be submitted by the system. You also specify the parameters that should be used with SBMJOB (such as the command to run, the job description and user profile under which the submitted job will run, and the job queue where the job is placed). Refer to 2 for a complete list of ADDJOBSCDE parameters. The ADDJOBSCDE command adds an entry to the job schedule object which has a unique job name/entry number. You supply the job name; the system sets the entry number.
When you want a job to be submitted at a later date and time, your first step is to set up a job schedule entry with the Add Job Schedule Entry (ADDJOBSCDE) command. With this command, you specify values that control when and how often the job should be submitted by the system. You also specify the parameters that should be used with SBMJOB (such as the command to run, the job description and user profile under which the submitted job will run, and the job queue where the job is placed). Refer to Figure 2 for a complete list of ADDJOBSCDE parameters. The ADDJOBSCDE command adds an entry to the job schedule object which has a unique job name/entry number. You supply the job name; the system sets the entry number.
While the ADDJOBSCDE command uses many parameters from the SBMJOB command, job scheduling has introduced a few new ones. Perhaps a few examples of ADDJOBSCDE will help clarify how its parameters work.
Daily Submission
The first example will show how to schedule a job to be submitted daily. Since the FRQ parameter of an entry does not support a *DAILY special value, you must specify *ALL or *MON, *TUE, *WED, *THU, *FRI, *SAT, *SUN for the Schedule Day (SCDDAY) and *WEEKLY for the Frequency (FRQ). For example:
ADDJOBSCDE JOB(POSTINVTRN) + CMD(CALL PGM(INV837X)) + FRQ(*WEEKLY) + SCDDATE(*NONE) + SCDDAY(*ALL) + SCDTIME(224500) + TEXT('Post inventory transactions')
This command schedules the execution of program INV837X at 10:45 p.m. every day. The job name is POSTINVTRN. The reason it runs every day is because SCDDAY(*ALL) indicates that it is to run every day this week; FRQ(*WEEKLY) repeats the cycle every week-resulting in a job that runs seven days a week, week after week.
Relative Day of the Month
The next example illustrates how to use the Relative Day of the Month (RELDAYMON) parameter. This feature allows you to schedule entries for the same relative occurrence of a day of the week, such as the first Saturday of the month or the last Friday of the month. To use the relative day of the month feature, you must first specify one or more values for the schedule day and *MONTHLY for the frequency. Consider the following command:
ADDJOBSCDE JOB(CLRSYSOPR) + CMD(CLRMSGQ MSGQ(QSYSOPR) CLEAR(*KEEPUNANS)) + FRQ(*MONTHLY) + SCDDATE(*NONE) + SCDDAY(*FRI) + SCDTIME(210000) + RELDAYMON(2 *LAST) + OMITDATE(122592) + TEXT('Clear QSYSOPR message queue')
QSYSOPR is a very busy message queue, which usually gets a lot of clutter from many jobs. The command shown above submits a Clear Message Queue (CLRMSGQ) command that removes all messages from QSYSOPR except inquiry messages that haven't been answered yet. This job, named CLRSYSOPR, will run on Fridays at 9:00 at night. Not every Friday, however; only the second and last Fridays of the month (as indicated by the RELDAYMON parameter). Since FRQ(*MONTHLY) is specified, this cycle (second and last Friday) will be repeated every month. There is one exception to this schedule. The job will not be submitted on Christmas Day, 1992, because OMITDATE(122592) is specified.
Last Day of the Month
Now look at this command:
ADDJOBSCDE JOB(DLTPRBLOGS) + CMD(DLTPRB PRBID(*ALL) + STATUS(*ANSWERED *CLOSED *VERIFIED) DAYS(15)) + FRQ(*MONTHLY) + SCDDATE(*MONTHEND) + SCDTIME(010000) + JOBQ(QBATCH) + USER(QSECOFR) + MSGQ(QSYSOPR) + TEXT('Delete old problem logs')
This command schedules the Delete Problem (DLTPRB) command to run at 1:00 in the morning on the last day of every month. The job name is DLTPRBLOGS, and the job deletes all problem logs older than 15 days that have a status of answered, closed or verified. On the last day of each month, the job will be submitted to the job queue QBATCH as running under the user profile QSECOFR. Messages about the job's submission and completion will go to the message queue QSYSOPR. It is important to note that in order for you to add this job schedule entry, you must be authorized to the QSECOFR user profile, the QBATCH job queue and the QSYSOPR message queue.
Recovery Action
Finally, consider this command:
ADDJOBSCDE JOB(DLTSCRATCH) + CMD(DLTLIB LIB(SCRATCH)) + FRQ(*ONCE) + SCDDATE(010193) + SCDTIME(030000) + SAVE(*NO) + RCYACN(*NOSBM) + JOBQ(QPGMR) + TEXT('Delete SCRATCH library')
This command adds an entry that will submit to the job queue QPGMR a Delete Library (DLTLIB) command at 3:00 in the morning of New Year's Day, 1993. The command will delete the SCRATCH library, and be executed only once-as indicated by the FRQ parameter. Since SAVE(*NO) is specified for this entry, the entry is removed from the job schedule after it is processed. If SAVE(*YES) had been specified, the entry would have been kept in the job schedule object in a saved (SAV) status. And finally, the RCYACN(*NOSBM) parameter indicates that, if the job could not be submitted at the specified time, the job scheduler will not attempt to submit it at a later time.
The last example used a unique feature of the job schedule entry-the recovery action. The Recovery Action (RCYACN) parameter specifies the action to take if the job cannot be submitted at the scheduled time because the AS/400 is powered down or in the restricted state. This action is then applied to the entry at the next IPL or when the system comes out of the restricted state. You can specify one of three values for this parameter. *SBMRLS, the default, causes the job to be submitted to the job queue in a released (RLS) status. Use this option if you want the job submitted normally as soon as the system becomes available. The *SBMHLD value causes the job to be submitted to the job queue in a held (HLD) status. You can then release the job (RLSJOB command) or end the job (ENDJOB command). Use this option if you want to control whether or not the job runs based on the circumstances of the particular situation. The *NOSBM value does not submit the job to the job queue. Use this option if you do not want the job submitted if the scheduled time is missed. All three options cause the entry to be updated for its next scheduled submission.
Tracking Scheduled Jobs
After you've added your entry, the job scheduling function is designed to allow you to track what happens with it by leaving a trail of messages. The first message to be aware of is the completion message sent by the ADDJOBSCDE command. The message data associated with this message contains the entry number which the system defined for your entry. You may need this information later since the combination of the job name (supplied by the user) and the entry number uniquely defines each job schedule entry. QJOBSCD also sends a message to the appropriate message queue when a job is successfully submitted using the entry.
The job name of the submitted job, the current date/time and an indication of success are stored in the entry within QDFTJOBSCD, creating a historical record. Each time the job is submitted, the entry is updated with the new information. This historical record of a job schedule entry can be viewed using option 5 on the Work with Job Schedule Entries (WRKJOBSCDE) display.
If the submission is unsuccessful, QJOBSCD will send messages to the specified message queue or QSYSOPR, and the historical record will indicate what occurred when the submission was attempted. For example, a submission was not attempted because the job schedule entry was held, or the submission was attempted but failed, in which case you are instructed to look at the message queue to determine what error occurred.
A message is also sent to the designated message queue if the entry is removed from the job schedule object using the Remove Job Schedule Entry (RMVJOBSCDE) command.
If you want to keep track of what happens with your entries, it is important that you specify a message queue that you can properly monitor, either manually or through a program. The Job Scheduling chapter in the Work Management Guide provides more details on the messages issued by the job scheduling function.
Control Elements
Once a repetitive entry is added to the job schedule, the system will repeatedly submit jobs using the entry until the entry is removed, unless the entry is held. The job will run at the scheduled time as long as three conditions are met:
1. The job is on a job queue that is not held.
2. The job queue is attached to an active subsystem.
3. The maximum number of active jobs has not been reached for the job priority level, the job queue and the subsystem.
The Hold Job Schedule Entry (HLDJOBSCDE) and Release Job Schedule Entry (RLSJOBSCDE) commands can provide a pseudo on/off switch for job scheduling. Once an entry is held, the system will not submit a job using the entry, but instead will only send a message indicating that the entry was held at its scheduled time. The system will continue to update the next submit date for each held entry that it processes, so that once the entry is released, it will be ready to return to normal scheduling.
Both the HLDJOBSCDE and RLSJOBSCDE commands will operate on a range of entries, from a single entry to all the entries in the job schedule. With the generic support for job name, you can easily control large blocks of entries with a single command. That's why it is important to properly name your entries so that they can be easily grouped into logical collections. For example, if you had several entries that produced inventory reports at the end of each day and several more entries that worked with the inventory at the end of every Friday, you might start each entry's name with the letters INV. Then, if for some reason you needed to prevent all the jobs from being submitted on a particular Friday, you could simply specify JOB(INV*) on the HLDJOBSCDE command.
The interface provided by the Remove Job Schedule Entry (RMVJOBSCDE) command appears very similar to the HLDJOBSCDE and RLSJOBSCDE commands, with one small but important difference. The RMVJOBSCDE command does not support the *ALL special value for job name. This is not an oversight, but rather an intentional decision on the part of the designers.
The ability to remove all the entries from the job schedule with a single command was seen as a potentially dangerous function, especially in the hands of a novice user. Therefore, RMVJOBSCDE was restricted to single entries and groups of entries when using the generic support.
For the more experienced users who want the ability to remove all the entries with a single command, there are building blocks to create such a function. By using the List Job Schedule Entries API (QWCLSCDE) and the RMVJOBSCDE command, you could create a single program to remove all entries from the job schedule. Simply call QWCLSCDE, requesting all entries in the job schedule; then, for each entry listed in the user space, issue the RMVJOBSCDE command.
Getting All the Details
We haven't mentioned much about the Work with Job Schedule Entries (WRKJOBSCDE) command. Similar to the function provided by most "Work with" commands, the WRKJOBSCDE command allows you to order some or all of your job schedule entries and to easily apply the job scheduling commands to specific entries. You can subset the list of entries by specifying one or more of the following on the command invocation: a particular job name, a scheduled submission date, the user profile that added the entry, or the job queue to which the job will be submitted.
Once you are viewing the Work with Job Schedule Entries display, there are two other options that should be mentioned. The first is option 5 = Display details. The details of the entry that are shown include all the information for the entry, the command to run and the submission history for the entry. It is this submission history which can help you determine what has happened with a particular entry.
The history includes both the last attempted submission, which is the last time the system tried to submit a job using the information in the entry, and the last successful submission, which is the last job successfully submitted by the system using the information in the entry. If everything is working correctly with your job scheduling, these two histories will be for the same job submission. If there are problems, this information should help in determining what has occurred.
The other option we need to explore is option 10 = Submit immediately. When this option is used, a command prompt for the SBMJOB command is displayed with information from the job schedule entry filled in. This option allows you to submit a copy of an entry without affecting the entry itself. When this option is used, neither the scheduling information nor the submission history of the entry is changed in any way. An example of where this would be useful is when, on Thursday morning, your supervisor wants an updated copy of a report which is normally generated every Monday morning by a job schedule entry. Using option 10 will create a new report, but it will not affect the entry's normal Monday scheduling.
With the variety of functions available from job scheduling, you may want to closely control who can perform the scheduling functions. One way to do this is by granting and revoking authorities as necessary. 3 shows the authorities required to perform various job scheduling functions. (Keep in mind that, in addition to having authority to run the job scheduling functions itemized in the table, the person working with job scheduling also needs authority to any of the objects affected by his job.)
With the variety of functions available from job scheduling, you may want to closely control who can perform the scheduling functions. One way to do this is by granting and revoking authorities as necessary. Figure 3 shows the authorities required to perform various job scheduling functions. (Keep in mind that, in addition to having authority to run the job scheduling functions itemized in the table, the person working with job scheduling also needs authority to any of the objects affected by his job.)
A Word of Caution
If you use job scheduling, you must be careful when changing the date and time on your system (QDATE and QTIME system values). If you move the date or time backward, the scheduled dates and times for the job schedule entries are not calculated again. This means that no jobs will be submitted during the period spanned by the time change. If you want the submission dates and times recalculated after you move the date and time backward, you must save and restore the job schedule object. A few examples might make this easier to understand.
Suppose the current system time is 11:00 a.m. and the next job schedule entry to have a job submitted is scheduled for 2:00 p.m. You find that the current time is actually 10:00 a.m., so you set the QTIME system value one hour back. Before the time change, the next job would have been submitted in three hours. Now that job will not be submitted for four hours. Saving and restoring the job schedule object would have no effect on this job submission because no entries were scheduled during the interim of the time change.
Now, let's try something more complicated. Our system contains two job schedule entries: FIRSTDAY is scheduled to run on the first calendar day of each month-SCDDATE(*MONTHSTR); TUESDAY is scheduled to run on the first Tuesday of each month-SCDDAY(*TUE) FRQ(*MONTHLY) RELDAYMON(*FIRST).
Let's look at the system on Monday, January 4, 1993. FIRSTDAY was scheduled and ran on Friday, January 1, 1993, and the next scheduled submission of FIRSTDAY was set to Monday, February 1, 1993 (see the sidebar on page 29 for information on how the next submission is scheduled). TUESDAY is currently scheduled to run on Tuesday, January 5 which is the first Tuesday of the month.
If you change the QDATE system value to December 31, 1992 without saving and restoring the job schedule object, this schedule remains intact. FIRSTDAY will not be run again when the system date becomes January 1, 1993; TUESDAY is also unaffected, since the scheduled January 5 submission has not yet occurred. However, if the date is reset and the job schedule object is restored, all scheduled entries will be recalculated. As a result, the FIRSTDAY job will run again on January 1, 1993. Depending on your reasons for changing the system date, you must choose which of these two scenarios you want and handle the job schedule object accordingly.
Now for an explanation of a change in the opposite direction. If you move the date and time forward, be aware that the timer for job schedule entries may expire and jobs will be submitted for these entries. A new submission time will then be calculated for each of these entries based on the current time. If you do not want jobs submitted for job schedule entries when you move the date or time forward, you should hold all of the entries. This will cause only a message to be issued for each entry, and the new submission time will be properly calculated.
An example of a date or time change in this direction would be the following: you have job schedule entries scheduled for 9:00, 9:15 and 9:30 a.m. every Monday. At 8:00 Monday morning, you change your QTIME system value to be 9:20 a.m. The QJOBSCD system job would immediately submit a job for the first entry and then the second entry. A job would be submitted for the third entry 10 minutes later.
What Job Scheduling Cannot Do
The following items were not included in our original support but are recognized as useful additions. This in no way implies that this support will be added in the future. Whenever possible, we have attempted to describe alternative solutions.
o The most requested function during early customer testing was the ability to serialize jobs. Customers would like to make the submission of a job for a job schedule entry be dependent upon the successful completion of another job (either run by the user or submitted from another job schedule entry).
This function can be achieved to some extent if you funnel the jobs through a job queue or a specific job priority level of a job queue that has a maximum activity level of one. To determine if a previous job was successful, a value indicating success could be written to a data area by the first job, which would be checked by the next job.
Although the job scheduling function submits a job to a job queue at a specified time, the system cannot guarantee that the job will run at that time. You must ensure that the job queue is not held, the job queue is attached to an active subsystem, and the maximum number of active jobs has not been reached for the job priority level, the job queue and the subsystem.
Even though we were able to provide much flexibility in the way you can schedule a job (every Monday, on the last day of the month, the second and fourth Fridays of the month, and so forth), we were not able to incorporate every possible variety of scheduling method. For example, you cannot specify several fixed dates when the job should be submitted, an end date when jobs should no longer be submitted, or a frequency of *HOURLY, *SEMIMONTHLY, *QUARTERLY or *YEARLY.
Often, these variations can be achieved with a combination of currently supported scheduling parameters and the OMITDATE parameter to specify dates when the job should not be submitted.
The job scheduling function cannot be turned off and on in its entirety. You can hold all of the job schedule entries in one operation by specifying HLDJOBSCDE JOB(*ALL) ENTRYNBR(*ALL) and then use the RLSJOBSCDE command with the same parameters to release all of the entries. Keep in mind that a job will not be submitted for the entry if its scheduled time arrives and the entry is held.
If you want to cease job scheduling activity on your system, you could also bring the system down to the restricted state. No jobs are submitted for job schedule entries while the system is in this condition. Then when the system comes out of the restricted state, the value specified for the RCYACN parameter for each job schedule entry would determine whether or not a job is submitted for the entry.
There is no support in place for multiple job schedule objects on the system which could be useful for you to group and control your entries. If you would like to group related entries together, you should name your job schedule entries starting with the same unique characters and then take advantage of the generic name support in the job scheduling commands.
Work It into Your Schedule
AS/400 job scheduling gives you more power and flexibility in doing your work than you have ever had before. You can use the simple approach of submitting a job to a job queue and defining when that job should be released to run, or you can schedule a job to be submitted by defining an entry in the new job schedule object. The new system job, QJOBSCD, takes care of the rest.
No longer do you have to baby-sit routinely run jobs; you're free to focus your attention on other things. We made it easy to use but still put in enough function so that you can schedule your jobs when you want. We hope that you give it a try and find it useful in getting the job done.
QJOBSCD Takes Control
A new system job named QJOBSCD is central to the job scheduler function. It is started at IPL and remains active in the system at all times. Essentially, QJOBSCD consists of a timer which is set to the job event with the scheduled submission time that is closest to the current time. When the timer "wakes up," QJOBSCD retrieves information from the job schedule entry and uses the information to submit the job. At this point, the job looks like any other job on the job queue. The only indication that the job came from a job schedule entry is that the job name for "Submitted by" viewed with the Work with Job (WRKJOB) command will be the job name of the QJOBSCD system job.
In addition to monitoring the impending scheduled event time, QJOBSCD retains a queue of all scheduled jobs in chronological order. Each job appears only once in this queue based on its next scheduled run time. If a job entry is added or changed, the job schedule command (ADDJOBSCDE, CHGJOBSCDE) calculates the first date/time that the job should be submitted and signals to the QJOBSCD system job. The entry is placed in its correct chronological position within the QJOBSCD queue. A similar mechanism is used to handle scheduled jobs from the SBMJOB command.
Any change or addition to the scheduled jobs might potentially cause QJOBSCD to reset its event timer. Therefore, the QJOBSCD job keeps track of which entry in the job schedule will have the next job submitted and when it should occur. If the new entry is inserted before the existing jobs in the queue, then QJOBSCD needs to reset its timer (which indicates when the next submission is) so that it will process this new entry at the correct time.
Each time QJOBSCD wakes up and submits a job, two other tasks must be completed: QJOBSCD calculates the subsequent date/time that the entry should be submitted and places the entry in its internal queue. If this entry is to become the next job submitted in the system, QJOBSCD sets the timer for this entry. Otherwise, it sets the timer for the entry that will succeed the job just submitted. This restarts the cycle of waiting on the timer, submitting the job and updating the entry.
Job Scheduling: Compliments of IBM
Figure 1 Job Schedule Entry commands
Figure 1: Job Schedule Entry Commands Function Command Description Add Job Schedule Entry ADDJOBSCDE Add a job schedule entry to the job schedule. Change Job Schedule Entry CHGJOBSCDE Change a job schedule entry. This command changes the entry in the job schedule, but it does not affect any jobs already submitted using this entry. Hold Job Schedule Entry HLDJOBSCDE Hold a job schedule entry. If an entry is held, no job is submitted for the entry at the scheduled time. Release Job Schedule Entry RLSJOBSCDE Release a job schedule entry. If the scheduled time passed while the entry was held, no jobs are submitted when the entry is released. However, a warning message is issued to indicate that one or more jobs were missed. Remove Job Schedule Entry RMVJOBSCDE Remove a job schedule entry from the job schedule. Work with Job Schedule Entries WRKJOBSCDE Provide a list of job schedule entries to work with.
Job Scheduling: Compliments of IBM
Figure 2 Parameters for the ADDJOBSCDE command
Figure 2: Parameters for the ADDJOBSCDE Command Parameter Keyword Description Job name JOB The name of the job schedule entry. This name is also used as the simple name of the submitted job. Command to run CMD The command that runs in the submitted job. The maximum length of this command string is 512 characters. Frequency FRQ How often the job is submitted to run. Schedule date SCDDATE The date on which the job is submitted to run. If an actual date is specified, that date is used for the first submission and as the base date for subsequent submissions. Schedule day SCDDAY The day of the week on which the job is submitted. If a value is specified for SCDDAY, SCDDATE(*NONE) must be specified. Schedule time SCDTIME The time at which the job is submitted. Relative day of month RELDAYMON The relative day of the month on which the job is submitted. This parameter is valid only if one or more days are specified for SCDDAY and *MONTHLY is specified for FRQ. Omit date OMITDATE One to 20 dates on which the job is not submitted. Recovery action RCYACN The action to take if the job cannot be submitted at the scheduled time because the system is powered down or in the restricted state. This action occurs at the next IPL or when the system comes out of restricted state. Save SAVE Specifies whether or not the entry for a job that is submitted only onceis kept in the job schedule after the job is submitted. This parameter is valid only if *ONCE is specified for FRQ. Job description JOBD The qualified name of the job description used when submitting the job. Job queue JOBQ The qualified name of the job queue on which this job is placed. User USER The name of the user profile under which the job is submitted. Message queue MSGQ The qualified name of the message queue to which messages are sent. Text description TEXT The text that briefly describes the job schedule entry.
Job Scheduling: Compliments of IBM
Figure 3 Authority required by Job Scheduling functions
Figure 3: Authority Required by Job Scheduling Functions Function Authority Add Job Schedule Entry *READ authority to the library QUSRSYS *CHANGE authority to the job schedule QDFTJOBSCD Change Job Schedule Entry *READ authority to the library QUSRSYS *CHANGE authority to the job schedule QDFTJOBSCD *JOBCTL special authority or you must be running under the same user profile which added the entry to the job schedule Hold Job Schedule Entry *READ authority to the library QUSRSYS *CHANGE authority to the job schedule QDFTJOBSCD *JOBCTL special authority or you must be running under the same user profile which added the entry to the job schedule Release Job Schedule Entry *READ authority to the library QUSRSYS *CHANGE authority to the job schedule QDFTJOBSCD *JOBCTL special authority or you must be running under the same user profile which added the entry to the job schedule Remove Job Schedule Entry *READ authority to the library QUSRSYS *CHANGE authority to the job schedule QDFTJOBSCD *JOBCTL special authority or you must be running under the same user profile which added the entry to the job schedule Work with Job Schedule Entries *READ authority to the library QUSRSYS *USE authority to the job schedule QDFTJOBSCD Work with Job Schedule Entries *READ authority to the library QUSRSYS Options 5 and 10 *USE authority to the job schedule QDFTJOBSCD *JOBCTL special authority or you must be running under the same user profile which added the entry to the job schedule List Job Schedule Entries API, *READ authority to the library QUSRSYS SCDL0100 format *USE authority to the job schedule QDFTJOBSCD List Job Schedule Entries API, *READ authority to the library QUSRSYS SCDL0200 format *USE authority to the job schedule QDFTJOBSCD *JOBCTL special authority or you must be running under the same user profile which added the entry to the job schedule
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