D.B.S. job scheduler is an instrument designed to resolve all the problems linked to the scheduling and coordinated execution of local and remote processes on i5 / iseries / AS400 systems. The product includes control and alarm sending functions. Installation of D.B.S. module (Data base Supervisor) is advisable but does not represent a prerequisite. We recommend installation of JBQTRC software (job queue activities check) for a complete check of all system batch activities. Page 1 of 66
1. GENERAL INFORMATION...3 2. PROGRAM INSTALLATION...5 3. METHODS OF USE...6 4. DEFINITION ACTIVITIES...8 5. PLANNING METHODS...10 5.1 Daily scheduling...11 5.2 Weekly scheduling...13 5.3 Monthly scheduling...14 5.4 Fixed date scheduling (calendar)...15 5.5 Scheduling based on a scheduling group...18 5.6 Conditioned scheduling...23 6. PARAMETERS OF EXECUTION...31 6.1 Program call...32 6.2 Command execution...34 6.3 Execution of a DBS function...36 6.4 Execution of a GAA action...37 6.5 Execution of remote commands (RUNRMTCMD)...38 6.6 Execution of remote commands (SBMRMTCMD)...40 6.7 Execution of FTP commands...42 7. JOB CONTROL...44 8. ALARMS MANAGEMENT...47 9. JOB EXECUTION...49 10. THE STATE OF SCHEDULED JOBS...51 11. INQUIRY OF LOG DATA...55 12. CALENDAR MAINTENANCE...57 13. DEFINITION OF E-MAIL ADDRESSES...61 14. SCHEDULER START...63 15. RESET OPERATIONS...64 Page 2 of 66
1. GENERAL INFORMATION The structure of D.B.S. Job scheduler is summed up in the following diagram: RESET Module (IPL) Undertakes the reorganization of information relating to unfinished jobs, if envisaged in the definition of the individual job. Scheduler Undertakes the submission of jobs at the date/time envisaged in the planning and/or the verification of the conditions of execution. Alarm manager Checks the completion of jobs within the scheduled time, sending alarm messages to a distribution list. JOBS TERMINATED WITH ERRORS JOBS NOT COMPLETED WITHIN THE EXPECTED TIME JOBS NOT SUBMITTED AS SYSTEM NOT AVAILABLE JOBS CANCELLED Planning module Allows definition of timetables and conditions of execution and the visualisation of the execution calendar Check module Allows analysis of jobs in progress and scheduling, as well as the reset of functions with alarm. Analysis module Allows consultation of the executions LOG Page 3 of 66
The base definition, very simple and intuitive, envisages the following possibilities: 1) Scheduling of repetitive processes in the course of the day, within the range of a preestablished time interval 2) Scheduling of processes at daily fixed times 3) Weekly scheduling 4) Monthly scheduling 5) Scheduling for fixed dates (calendar) 6) Scheduling based on a scheduling group 7) Scheduling coordinated by several processes All the possibilities can be combined together, as illustrated in the following examples. Page 4 of 66
2. PROGRAM INSTALLATION 1) Request user password for the RR0016, communicating serial number (QSRLNBR), system model (QMODEL) and processor (QPRCFEAT). 2) The product is distributed in the file DBSSCD_EXE.SAVF, which can be unloaded from the site www.rrrightware.com 3) Open a session as with QSECOFR profile 4) Create the RR_SAVF library on AS/400 5) Create the salvage file RR_SAVF/DBSSCD_EXE 6) Transfer the contents of the DBSSCD_EXE onto the save file via FTP according to the download instructions www.rrrightware.com 7) Type the command RSTLIB SAVLIB(DBSSCD) DEV(*SAVF) SAVF(RR_SAVF/DBSSCD_EXE). 8) Verify that the base library RIGHTWARE is installed (objects in RIGHT_OBJ) or install it; the library can be obtained from the download page of the www.rrrightware site. 9) Modify the system value QUSRLIBL by entering RIGHT_OBJ in a position following QTEMP. 10) Close and reopen the session. 11) Type the command : SETUP DSTLIB(DBSSCD) TGTLIB(RIGHT_SYS) 12) Enter the RIGHT_SYS library in the system library list through the command WRKSYSVAL QSYSLIBL 13) Close and reopen the session 14) Execute the DBSSCDINI command Note: The DBSSCD library can be cancelled from the system. Create the user profile DBSADM. If the D.B.S: product is already installed, the profile already exists. CRTUSRPRF USRPRF(DBSADM) USRCLS(*SECOFR) In order to use DBSSCD it is necessary to start the monitor at every IPL It is advisable to modify the start program (QSTRUP) by entering the command: STRDBSSCD RESET(*YES) Install the distributed PTF using the SETUP command (see download general instructions). Page 5 of 66
3. METHODS OF USE Access to the functions is given from the relative DBS menu (if installed) or through commands. The definition methods are usually intuitive. Where there are not specific command keys present, access to the options is given by positioning the cursor on the highlighted buttons (double click). The picture below highlights the buttons which are active on the maintenance video. Page 6 of 66
Page 7 of 66
4. DEFINITION ACTIVITIES The job definition function is activated by the DBSSCD command, with the possibility of selection by: job name or partial name xxx* Job group Alarm group Scheduling group The visualization sequence can be by group or by name. Page 8 of 66
The list of defined jobs is shown: The copy option and visualisation of links with correlated jobs are available. Job scheduling under a different user name requires authorization from the user profile: as a rule, the definition should be reserved to users of *SECOFR class. Page 9 of 66
5. PLANNING METHODS A process is identified by: A univocal code of 10 characters. A group code of 3 characters and a group progressive; belonging to a group makes it possible to aggregate and deal with several processes together, as explained more fully below. A description of 50 characters. An alarm group of 10 characters, which corresponds to a distribution list; this makes it possible to sort out the the notifications relative to problems with scheduled jobs. The examples below explain the various methods of use of the scheduler. The definition of control and alarm functions is dealt with in a separate section. Page 10 of 66
5.1 Daily scheduling 1) Scheduling of repetitive processes in the course of the day, within the range of a preestablished time interval. This method is particularly adapted to checking functions. The job is submitted from the time indicated; after termination, it will be resubmitted once the given interval has passed until the specified end time. Page 11 of 66
2) SCHEDULING OF PROCESSES AT FIXED DAILY TIMES This method is particularly suitable for data exchange functions or for any process that requests time synchrony. Page 12 of 66
5.2 Weekly scheduling The definition can be combined with other typologies; it makes it possible to limit processes to workdays, the weekend, etc. Page 13 of 66
5.3 Monthly scheduling Makes it possible to confine execution to specific days or to the end of the month of every or certain months. If combined with weekly planning, it takes priority. Page 14 of 66
5.4 Fixed date scheduling (calendar) Makes it possible to indicate specific dates for job execution, in addition to or by exclusion as regards daily, weekly or monthly planning. It is useful for single scheduling or for holiday planning. Fixed date definition always takes priority over other definitions, either by inclusion or by exclusion. It is possible to select a reference calendar to identify holidays. Workdays are distinguished from Saturdays and Sundays through use of colour. The state of scheduling can be modified by positioning the cursor on a box (double click or send). Likewise the calendar can be modified or you can run through the years by using the cursor. Page 15 of 66
It is also possible to operate on an individual month, by selecting it (double click) Page 16 of 66
In each individual month the scheduling days are highlighted (underlined), as are holidays and part holidays (red/pink). Page 17 of 66
5.5 Scheduling based on a scheduling group The concept of a scheduling group is fundamental in order to define execution planning shared by several processes; programming maintenance is greatly simplified and easily takes into account the holidays noted on the reference calendar. In the example below a scheduling group is defined for jobs to be executed on the first working day of every month. The definition of a scheduling group is accessible from the research/assignation format or through the DBSSCDSCH command. Position the cursor on the code to make a choice, on the description to carry out maintenance. Page 18 of 66
By positioning the cursor (double click) on the heading (weekly/monthly), the defining options are opened (days/months). By positioning the cursor on the calendar, access is given to the specific definition. Page 19 of 66
It is possible to select a reference calendar with holidays highlighted. Workdays are distinguished from Saturdays and Sundays by colour. By positioning the cursor on a box (double click or send) it is possible to modify the state of scheduling. Also through the position of the cursor, it is possible to modify the reference calendar or run through the years. By selecting a month (double click) the management format by individual month can be opened. Page 20 of 66
In each individual month the scheduling days are highlighted (underlined) as are holidays and part holidays (red/pink) Page 21 of 66
By positioning the cursor on the day, it is possible to modify the stste of scheduling (in the example, the executions have been moved for days at the beginning of the month which fell on Saturdays/Sundays or holidays) Page 22 of 66
5.6 Conditioned scheduling D.B.S., in addition to the definitions given, also allows definition of the conditions of feasibility of a process. This method allows independent processes to be synchronised, without the need for application modifications, since the management module takes care of checking feasibility conditions as well as fixing conditions for correlated processes; it is obvious that processes which carry out job submissions themselves cannot be checked. A module for the external definition of the conditions is supplied. There are up to fifty execution conditions. For every job the feasibility conditions are defined (condition flags received from other jobs) and the conditions to define for dependent jobs (jobs which are waiting for a condition). Page 23 of 66
The example which follows shows the coding for a job which is waiting for confirmation of reception of data from a branch, carries out local elaboration of data and sets up execution of a summary; the summary waits for the completion of the elaboration of data from the main office. In order to obtain correlations 3 types of condition flags have been used; condition flags can be descriptive, for easier definition of correlations. Page 24 of 66
The images below show the situation of conditions that have been envisaged or set up among the four jobs. Page 25 of 66
The work of data reception from the branch has no conditions of execution, but it must inform the data processing job when it is over. Page 26 of 66
The data processing job waits for the communication from the reception job. Page 27 of 66
When it ends, it must inform the final processing job, this job is highlighted to show that it is waiting for another condition. Page 28 of 66
The main office data processing job has no conditions, but informs the final job when it ends. Page 29 of 66
The final processing job waits for the completion of the two jobs (independent of each other) of data processing. There are no obligations to belong to a group for co-ordinated jobs and the feasibility conditions can be much more complex. The definition of conditions can be made in addition to the normal time scheduling or can be absolute (the job is executed whenever the conditions are verified). It is also possible to fix conditions at the start of a process, as well as at the end, for example to start simultaneous executions. Page 30 of 66
6. PARAMETERS OF EXECUTION Three kinds of typology are envisaged: 1) Program recall 2) Command execution 3) Execution of a D.B.S. function (if installed) Whatever the typology, the job is submitted on behalf of the user named, in the job queue or with the attributes of job description and output queue specified. Page 31 of 66
6.1 Program call A parameter type is associated to the program; this definition allows the recall of application methods which envisage fixed INPUT parameters. The parameter types are predefined: * = no parameter P = Parameter string of 256 characters L = D.B.S. parameter string in Local Data Area K = D.B.S. parameter string for written applications in G.A.A. environment A source is supplied as an example for the definition of other typologies for user use. It is possible to insert a parameter string of 256 characters, which will be interpreted by the parameter construction module and passed on to the application program. Page 32 of 66
Page 33 of 66
6.2 Command execution The command string is confined to 256 characters; for the execution of longer strings it is necessary to create an interface CL PROGRAM. The standard PROMPT is available for the insertion of the command string. Page 34 of 66
Page 35 of 66
6.3 Execution of a DBS function The function is specified in the ENVIRONMENT/FUNCTION format; the scheduler will take care of defining the environment library list before the job submission. The parameters can be likewise defined at the submission of a program. Page 36 of 66
6.4 Execution of a GAA action The action is specified in the ENVIRONMENT/ACTION format; the scheduler will take care of defining the environment library list and setting parameters in KPJBA format before the job submission. The parameters can be likewise defined at the submission of a program. Page 37 of 66
6.5 Execution of remote commands (RUNRMTCMD) It applies at any system, even if not AS/400, which supports the remote command. Page 38 of 66
The informations to establish the link and to check the result are required: The command syntax is cheched only for AS/400 systems. The password is encrypted and it is not possibile to use it on another system. The check of the result is made through the analisys of the stream returned by the remote system. Page 39 of 66
6.6 Execution of remote commands (SBMRMTCMD) This mode is note recommended, because remote errors normally doesn t have a default reply, but cause a message sent to the operator s message queue. The definition of the maximum run time is recommended, to obtain a local monitoring. Page 40 of 66
The informations to establish the link are required: Page 41 of 66
6.7 Execution of FTP commands Allow the definition of FTP commands to transfer data from/to any type of system. The informations to establish the link and to check the result are required: Page 42 of 66
The password is encrypted and it is not possibile to use it on another system. Respect if necessary the uppercase/lowercase distinction. The check of the result is made through the analisys of the FTP log file. If errors are issued or if the request to keep the output is specified, a spool file containing the FTP log is created. Page 43 of 66
7. JOB CONTROL D.B.S. is able, apart from submitting jobs according to the many methods illustrated, to check them. Checking and alarm activity depends on the given definitions, which are detailed below, distinguished by: IPL definitions or restart Job duration definitions Definitions for non-available system Definitions for execution errors F7=Job control action command is available on the definition panel The table describe actions of each possible definition: Page 44 of 66
Definition Value Action Actions at IPL Reset at IPL Y When STRDBSSCD RESET(*YES) is executed, all jobs which appear irregularly closed are reset, that is, they can be executed at the next planned time. N Jobs which appear irregularly closed remain in PENDING state, awaiting manual reset. Reset Conditions to IPL N Any feasibility conditions defined will not be reset. Y E Conditions are defined at null value. The conditions are defined at the value requested for execution. Note that this definition allows resetting of correlated jobs in rotation, for which at least one job must the initial conditions verified initially. Actions for duration limit exceeded Maximum job length nnn Expresses in minutes the maximum duration of a job, at the end of which an alarm message will be sent. Alarm gravity 0-9 Expresses the level of gravity of the delay for this job; the value determines the sending of an alarm and the receivers concerned.a 0 value prevents the sending of alarms. Automatic reset N Delay condition will produce a PENDING situation Y After alarms are sent, the job is reset for execution and condition flags are defined at nil value Action on job I In case of automatic reset, the job, if active is ignored C The job, if active, is cancelled (ENDJOB *IMMED) Condition set N In case of automatic reset for delay, the conditions for correlated jobs are not set Y Conditions for correlated jobs are defined, as if the job had ended regularly. Actions for non-available system Action for non-available system C When STRDBSSCD RESET(*YES) is executed, if the scheduled time has passed, the job is no longer executed. R The job is executed, but only within the given limit. Maximum delay nnnn Indicates, in minutes the maximum delay before the execution is cancellled in case of non-available system Page 45 of 66
Severity 0:9 Expresses the gravity of the cancellation of a job for system non-available, determining conditions of alarm sending: a 0 value prevents alarm sending Actions for execution error Automatic reset N Following execution errors, the process is not automatically reset. Y After sending alarms, the job is reset for execution and condition flags set at nil value Defining conditions N In case of automatic reset for an execution error, conditions for correlated jobs are not set. Conditions for correlated jobs are set, as if the job had ended regularly Manage message waiting Y If the job go in the message waiting status, this is like an execution error. N The message waiting condition is shown, but no actions are issued. Wait for operator action nnn If Y in message waiting management, the monitor waits for an operator action for the time specified in minutes; then the condition error is started. Action on job I In case of automatic reset, the job, if active is ignored C The job, if active, is cancelled (ENDJOB *IMMED) Execution severity 0:9 Expresses the gravity for an execution error, determining conditions of alarm sending: a 0 value prevents alarm sending Page 46 of 66
8. ALARMS MANAGEMENT The product includes an alarm manager, which is responsible for advising the operator, or sending email/messages to s distribution list. For each process is defined: b) an alarm group (distribution list) which defines to whom, at which times and for what degree of gravity alarms must be sent. c) the gravity of situations which can verified: Execution not completed within the planned times Execution completed over the planned time Execution errors Process not executed for non-available system Job cancelled from the system Page 47 of 66
It is therefore possible to distribute process checking to different people, defining the actions to undertake on the basis of the predefined gravity of the problem. The definition provides for the sending of internal emails (postal address from SMTP parameters of the user) or external (MNGEXTMAIL command) to the operator queue or to receivers, according to the levels of gravity defined for the job, with indication of sending times. Page 48 of 66
9. JOB EXECUTION Once defined, the job will be automatically submitted on every planned occasion. The next occasion for elaboration can be requested using the Next button. A compulsory execution of the job can be requested at a certain date/time. If entered, it represents the date/time of the next execution, any preceding scheduling is ignored. Immediate execution of the job can be requested using the Esec. Imm. button; compulsory scheduling is automatically inserted within the following minute. Page 49 of 66
At the close of the definition, the next planned execution is indicated anyway, with obligatory confirmation. Page 50 of 66
10. THE STATE OF SCHEDULED JOBS D.B.S. Job scheduler carries out both scheduling and checking functions. The state of scheduled jobs is obtained by the DBSSCDSTS command. Data relating to the last execution and the scheduling which follows are highlighted. Page 51 of 66
Instead of the scheduling data a status may appear: * RUNNING Execution is in course *SUBMITTED The job has been submitted and is in the job queue *PENDING The job did not finish regularly and intervention is necessary *SCHEDULING Programming of the next Execution is underway *WAITING Execution is conditioned and the conditions are not fulfilled Apart from maintenance options these options are available: interrogation of execution/programming calendar visualisation of links Page 52 of 66
The execution/programming calendar highlights the days in which the function has been executed and those for which it is programmed. Page 53 of 66
By selecting an execution box the LOG of the day is highlighted, any problems which came up are shown. In the example the job was cancelled during execution. Analysis by data relating to several jobs is supplied by the DBSSCDLOG command. Page 54 of 66
11. INQUIRY OF LOG DATA The DBSSCDLOG command allows interrogation between date/time limits of the jobs executed, also in partial form. Page 55 of 66
Page 56 of 66
12. CALENDAR MAINTENANCE Calendar maintenance is obtained through the DBSSCDCAL command. The product contains a perpetual calendar; the definition of calendars has the sole aim of indicating state and company holidays. The *DFT calendar is automatically created, without holidays. Since the *DFT calendar is automatically associated toe every new scheduled job, it is appropriate to define within this the holidays on the national calendar. From the selection format it is possible to modify a calendar (double click on description) or insert a new one. Page 57 of 66
The colour highlights the kind of day (white workdays, pale blue Saturday, blue Sunday, pink part holiday (/), red holiday(*). By positioning the cursor (double click) on a day, the definition window for the kind of day is opened. Page 58 of 66
It is also possible to work on an individual month, by positioning the cursor (double click) on the month description. Page 59 of 66
Definition methods are analogous (double click on day to be modified). Page 60 of 66
13. DEFINITION OF E-MAIL ADDRESSES Alarm management is based on precoding of receiver; these may be internal or external. The user profile is valid for internal ones; the email address must be specified in the postal address of the associated system directory entry. Example: For external ones, use the MNGEXTMAIL command. Page 61 of 66
Page 62 of 66
14. SCHEDULER START The scheduler must always be active. The activation command is STRDBSSCD Activation command is around 30 seconds; if already active it is disactivated and reactivated. Activation at IPL (insert command in the START UP module) has to have RESET (*YES) parameter, Reset *YES executes automatic resets and resets the conditions of all jobs which are not in execution. The scheduler can be stopped with ENDDBSSCD command. It can be used for maintenance, salvage and program updating operations. Page 63 of 66
15. RESET OPERATIONS If scheduled jobs do not finish within the fixed times, a PENDING condition is highlighted. This condition is automatically reset if it is envisaged in the job definition. The reset option allows resetting of jobs for which automatism is not specified. Page 64 of 66
The RESET video is shown, with job data and indication of the cause of the error. Page 65 of 66
The appropriate RESET parameters must be defined for job rescheduling or definition of dependent conditions. Page 66 of 66