Professional Documents
Culture Documents
Batch jobs A batch job is a predefined group of processing actions that is submitted to the system. Batch jobs run in the system background, freeing the user who submitted the job to do other work. The job requires no interaction on the part of the user once it has been set up. Batch jobs are typically low priority jobs. Several batch jobs can be active at the same time. Following are different kinds of batch jobs: Simple batch job Most people are familiar with the simple batch job that is submitted to a job queue. For more information about a simple batch job's life, see A job's life. Batch immediate job A batch immediate job is a batch job that was started with many of the attributes of its parent job. The job runs in the same subsystem as the parent job. Because the job copies attributes from the parent job and does not go through a job queue, it can start faster than jobs submitted to a job queue. Batch MRT job A batch MRT job is a multiple requester terminal (MRT) job. MRT jobs are S/36 Environment jobs that act like servers, allowing other S/36 Environment jobs to attach to them in order to run an MRT procedure. Batch print job Batch print jobs track the printer output files (also called spooled files) that were created by a job whose current user profile is different from the user profile that it was started under.
1)
job's life
To understand the basics of iSeries work management, follow a simple batch job as it moves through the system. The life of a simple batch job begins when you submit it to the system. The job is then sent to a job queue where it waits to enter a subsystem where it can run. Once the job moves to the subsystem it is allocated memory in which to run. The printer output file (also called spooled files) is then sent to the output queue to await further instruction on what to do (for example, printing).
Page 1 of 35
a)
Submit a Job:-
A job's life: Submit a job When a job is submitted to the iSeries, it is created and enters the system. At this time, the properties are given to the job. Once the job receives its job description and defines its properties, it moves to the job queue where it waits to enter the subsystem.
Page 2 of 35
b)
Job queues are work entry points for batch jobs to enter the system. They can be thought of as "waiting rooms" for a subsystem. A number of factors affect when the job is pulled off the job queue into the subsystem, such as the job priority on the job queue, the sequence number of the job queue, and the maximum active jobs. When all of these factors work together, the job will be pulled off the job queue to start running in the subsystem.
Page 3 of 35
The job enters a job queue > Job queue c) The job enters the subsystem
When the job enters the subsystem it becomes active. Until a job gets its activity level and memory from a memory pool, it cannot run. The job uses several pieces of information before it can receive memory to run. The subsystem description, like the job description, carries information, such as the memory pool to use, the routing entry, the maximum active jobs, and the number of active jobs currently in the subsystem.
Page 4 of 35
The job enters the subsystem > Subsystem d) The subsystem uses memory from a memory pool to run the job
Page 5 of 35
The subsystem uses memory from a memory pool to run the job > Memory pool
A job's life: Memory pools Memory pools provide jobs with memory in which to run. Many factors affect how the job runs in the memory pool, such as the size and the activity level in the memory pool, as well as paging and faulting. The activity level in memory pools directly relates to the number of threads allowed to run in the memory pool at one time. Remember, every job has at least one active thread, but some can have multiple threads. Threads give a job the ability to do more than one thing at a time. For example, one thread can go out and do calculations while another thread waits for more data to process. Paging is the movement of data in and out of memory, both synchronously and asynchronously. Pages can be written out to storage or removed from memory without being written if they have not been changed. Faulting causes paging to occur on the iSeries server. Faulting occurs when a referenced page, or piece of data, is not in memory. This causes programs to stop because they must wait for the data to be paged in.
Page 6 of 35
The subsystem uses memory from the memory pool to run the job > Memory pools e) The job finishes and moves to the output queue
A job's printer output (also called spooled files) is sent to an output queue where it waits to be sent to a printer or file. The output queue is similar to the job queue in that it controls how the output is made available to the printer. The output queue allows the user to control what files are printed first.
Output queues Output queues are areas where printer output files (also called spooled files) wait to be processed and sent to the printer. Printer output is created either by the system or by the user using a print file. A print file is similar to a template or a guideline where the default values for the attributes of printer output are set. It is the beginning of the printer output life cycle. The print file contains the output queue (OUTQ) and print device (DEV)attributes, which dictate how the printer output is to be directed. The default settings are usually *JOB, meaning that the job attributes of the output queue and printer device determine how the printer output is directed. The job attributes of the output queue and printer device settings are based on information obtained when the job is created. This is based on information from the user profile the job is running under, the job description, the workstation device description, and the default printer system value(QPRTDEV).
Page 7 of 35
Page 8 of 35
Break the application into pieces and having multiple batch threads (jobs) operate concurrently. Reduce the number of open and close operations, input and output operations. If you have a considerable amount of main storage available, consider using the Set Object Access (SETOBJACC) command. This command preloads the complete database file, database index, or program into the assigned main storage pool if sufficient storage is available. The objective is to improve performance by eliminating diskread/write operations. Try to limit the number of communications input and output operations by doing fewer (and perhaps larger) application sends and receives when communications lines are used. Block the data in the application. Try to place the application on the same system as the frequently accessed data
Prestart jobs A prestart job starts before a work request is received, either when the subsystem starts or as a result of the Start Prestart Jobs (STRPJ) command. Prestart jobs start from a prestart job entry (PJE) in the subsystem description. The prestart job entry specifies properties such as what program to run in the prestart job, the user profile under which the prestart job starts running, the job description, the class used to specify the run-time properties of the job, and the memory pool in which the prestart job runs. Prestart jobs can start and initialize themselves before a work request is received. This reduces the amount of time required to handle the requests. A new job is not required for every work request. In addition, prestart jobs provide the ability to initialize once and handle many requests so that a new job is not needed for every request. Most client server applications use prestart jobs to handle the requests for the client user. Having a job ready to go makes the performance better in this situation because the prestart job can start processing the request for the user immediately. Note: The value specified for the maximum number of jobs in the subsystem can prevent prestart jobs from starting. If the maximum number of jobs in the subsystem is exceeded, no prestart jobs can be started. When enough jobs have completed so that the number of jobs running is below the maximum number of jobs in the subsystem, prestart jobs in the subsystem can start.
Two types of prestart jobs exist. Each type handles different types of requests. Before a job waits for its first request, it will be shown as Prestart only because the system does not know yet what type of requests the job will handle. Following are the two types of prestart jobs: Prestart communications job A prestart communications job is a communications batch job that starts running before a remote system sends a program start request.
Page 9 of 35
Prestart jobs can be reused, but there is no automatic cleanup for the prestart job once it has been used and subsequently returned to the pool. The number of times the prestart job is reused is determined by the value specified for the maximum number of uses (MAXUSE) value of the ADDPJE or CHGPJE CL commands. This means that resources that are used by one user of the prestart job must be cleaned up before ending use of the prestart job. Otherwise, these resources will maintain the same status for the next user that uses the prestart job. For example, a file that is opened but never closed by one user of a prestart job remains open and available to the following user of the same prestart job. By default, some of the server jobs run in QUSRWRK or QSERVER. Using iSeries(TM) Navigator, you can configure some or all of these servers to run in a subsystem of your choice. 1. Double-click iSeries Navigator --> Network --> Servers --> iSeries Access. 2. Right-click the server that you want to configure subsystems for and select Properties. 3. Configure the server using the Subsystems page. If you move jobs from the default subsystem, you must: 4. Create your own subsystem description. 5. Add your own pre-start job entries using the ADDPJE command. Set the STRJOBS parameter to *YES. If you do not do this, your jobs will run in the default subsystem
Page 10 of 35
When the file arrives at its destination, a notification message is sent to both the recipient and sender of the file. When a source physical file is sent, the source sequence number and change date in positions 1 through 12 of the record are sent with the file. These are kept if the file is received into a source physical file, and are truncated if the file is received into a nonsource physical file. When a file that was originally a nonsource physical file is received into a source physical file, the source sequence numbers are created and placed in front of the records. Note: Save files created on the AS/400 system cannot be distributed to System/38. However, save files created on System/38 can be distributed to the AS/400 system. Restrictions: 1. The user must be enrolled in the system distribution directory. 2. The maximum size of a file that can be sent using the SNDNETF command is approximately 2 billion bytes. Parameters Keyword Description FILE File Qualifier 1: File Qualifier 2: Library TOUSRID User ID Choices Qualified object name Name Name, *LIBL, *CURLIB Values (up to 50 repetitions): Element list Required, Notes Required, Positional 1
Page 11 of 35
Page 12 of 35
Receive Network File (RCVNETF) The Receive Network File (RCVNETF) command receives a network file and copies the records into a physical database file or a save file. Once the file has been received, it is removed from the queue of network files. If the original file is a save file, it must be received into a save file. Before a file can be received, the file specified by the TOFILE parameter must already exist. When a source physical file is sent, the source sequence number and change date in positions 1 through 12 of the record are sent with the file. These are kept if the file is received into a source physical file, and are truncated if the file is received into a nonsource physical file. When a file that was originally a nonsource physical file is received into a source physical file, the source sequence numbers are created and placed in front of the records.
Page 13 of 35
Integer, *LAST, *ONLY, *FIRST Optional Name, *CURRENT *NETFILE, *SRC Optional Optional Top
Examples Example 1: Receiving a Member RCVNETF FROMFILE (FILEA) TOFILE (FILEB/FILEA) FROMMBR (PAYROLL) This command receives member PAYROLL of file FILEA into member PAYROLL of file FILEA in library FILEB. If there is an existing member of that name, the records in the member are replaced. If multiple members of that name are available, the last one to arrive at the destination system is received. Example 2: Receiving a Network File
Page 14 of 35
Page 15 of 35
Restrictions: 1. A user with security officer authority can display the network files for any user. Users other than the security officer can show only those files that were sent to them or to their group profile. 2. To perform any of the options from this display, you must be authorized to the command corresponding to that option. For example, you must be authorized to the Display Physical File Member (DSPPFM) command for the browse function, and the Submit Database Jobs (SBMDBJOB) command for the submit job function. 3. To perform WRKNETF in debug mode, update of production files must be allowed by specifying UPDPROD(*YES) on the STRDBG command. Parameters Keyword Description Choices Notes
Page 16 of 35
Example 3: Working with Network Files for All Users WRKNETF USER (*ALL) OUTPUT (*OUTFILE) OUTFILE (NETFILES) This command allows you to work with the network files for all users and is written to the first member of a database named NETFILES. If the file exists in a library on the library list, the existing file is used; otherwise, the file is created in the QGPL library. If the file did not exist, or did not contain any members, a member with the same name as the file is added to the file; otherwise, the first member of the file is cleared and used. This command can be issued only by a user with security officer rights.
Page 17 of 35
Page 18 of 35
Parameters Keyword OBJ Description Objects Choices Single values: *ALL Other values (up to 300 repetitions): Generic name, name Values (up to 300 repetitions): Generic name, name Single values: *SAVF, *MEDDFN Other values (up to 4 repetitions): Name Single values: *ALL Other values (up to 300 repetitions): Character value Notes Required, Positional 1 Required, Positional 2 Required, Positional 3 Optional, Positional 4
LIB DEV
Library Device
OBJTYPE
Object types
VOL
Volume identifier
Single values: *MOUNTED Optional, Other values (up to 75 repetitions): Positional 5 Character value 1-16777215, *END Character value, *LIB Date, *PERM *REWIND, *LEAVE, *UNLOAD Qualified object name Name Name, *LIBL, *CURLIB Qualified object name Name Optional Optional Optional Optional Optional Optional
Sequence number Label File expiration date End of media option Save file Qualifier 1: Save file Qualifier 2: Library
MEDDFN
Page 19 of 35
SAVACTWAIT Save active wait time Element 1: Object locks Element 2: Pending record changes
Element 3: Other pending 0-99999, *LOCKWAIT, *NOMAX changes SAVACTMSGQ Save active message queue Qualifier 1: Save active message queue Qualifier 2: Library FILEMBR File member Element 1: File Element 2: Member Qualified object name Name, *NONE, *WRKSTN Name, *LIBL, *CURLIB Values (up to 50 repetitions): Element list Name, *ALL Single values: *ALL, *NONE Other values (up to 50 repetitions): Generic name, name *SYSVAL, *NO, *YES *YES, *NO *KEEP, *FREE *DEV, *NO, *YES, *LOW, *MEDIUM, *HIGH *DEV, *NO Single values: *NONE Other values (up to 300 repetitions): Generic name, name Optional Optional Optional Optional Optional Optional Optional Optional
Save access paths Save file data Storage Data compression Data compaction Libraries to omit
Page 20 of 35
Page 21 of 35
Page 22 of 35
Page 23 of 35
Page 24 of 35
Page 25 of 35
Parameters Keyword OBJ Description Objects Choices Single values: *ALL Other values (up to 300 repetitions): Generic name, name Single values: *ANY Other values (up to 300 repetitions): Generic name, name Single values: *SAVF, *MEDDFN Other values (up to 4 repetitions): Name Notes Required, Positional 1 Required, Positional 2 Required, Positional 3
SAVLIB
Saved library
DEV OBJTYPE
Single values: *ALL Optional, Other values (up to 73 repetitions): *ALRTBL, Positional 4 *BNDDIR, *CFGL, *CHTFMT, *CLD, *CLS, *CMD, *CRG, *CRQD, *CSI, *CSPMAP, *CSPTBL, *DTAARA, *DTAQ, *EDTD, *EXITRG, *FCT, *FILE, *FNTRSC, *FNTTBL, *FORMDF, *FTR, *GSS, *IGCDCT, *IGCSRT, *IGCTBL, *IMGCLG, *JOBD, *JOBQ, *JOBSCD, *JRN, *JRNRCV, *LOCALE, *MEDDFN, *MENU, *MGTCOL, *MODULE, *MSGF, *MSGQ, *NODGRP, *NODL, *OUTQ, *OVL, *PAGDFN, *PAGSEG, *PDFMAP, *PDG, *PGM, *PNLGRP, *PRDAVL, *PRDDFN, *PRDLOD, *PSFCFG, *QMFORM, *QMQRY, *QRYDFN, *RCT, *SBSD, *SCHIDX, *SPADCT, *SQLPKG, *SQLUDT, *SRVPGM, *SSND, *SVRSTG, *S36, *TBL, *TIMZON, *USRIDX, *USRQ, *USRSPC, *VLDL, *WSCST
Page 26 of 35
SAVDATE SAVTIME
Date Time Single values: *NONE, *ALL Other values (up to 4 repetitions): *AUTL, *FILELVL, *OWNER, *PGP Single values: *SYSVAL, *NO Other values: Element list
Optional
Element 1: *YES Convert during restore Element 2: Objects to convert RSTLIB Restore to library *RQD, *ALL
Name, *SAVLIB
Optional
Page 27 of 35
Restore to ASP Name, *SAVASPDEV device Restore to ASP 1-32, *SAVASP number File to receive Qualified object name output Qualifier 1: Name File to receive output Qualifier 2: Library Name, *LIBL, *CURLIB Element list
OUTMBR
Optional
Element 1: Name, *FIRST Member to receive output Element 2: *REPLACE, *ADD Replace or add records INFTYPE OMITLIB Type of output *OBJ, *MBR information Libraries to omit Objects to omit Element 1: Object Qualifier 1: Object Single values: *NONE Other values (up to 300 repetitions): Generic name, name Values (up to 300 repetitions): Element list Qualified object name Generic name, name, *NONE, *ALL Optional Optional
OMITOBJ
Optional
Page 28 of 35
Page 29 of 35
Page 30 of 35
Page 31 of 35
Page 32 of 35
Page 33 of 35
1) What happens if u do a RUNQRY on Source PF? 2) PF1 is having 2 LFs LF1 & LF2, LF2 is having unique keyword associated with it, and if u are trying to insert a duplicate record into a PF? What happens and what is the error which u get? 3) PF1 is having 3 LFs and LF1 is having 5 key fields and LF2 is having 4 key fields and LF3 is having 3 key fields, which will u compile first and why? 4) I should design a PF in which we should be able to insert records into a PF but we should not be able to modify any records? How can we achieve that? 5) If I change any field in a PF, then is it necessary to compile all the LFs that are built using this PF? 6) A PF is not containing any records in it, but when we do a runqry on that PF, it says member full, Then how will u handle this scenario? I mean what will u do so that u store data in that PF? 7) In CL, when I encounter any error I need to display the Message ID of that error case, like cpf9801 ? How to display that particular message ID and description through CL? 8) How will get the record count of any PF in CL? 9) How will get the record count of any PF in RPG with out using READ opcode? 10) In Arrays the no. of elements, entry length of array are given during declaration, If I need to get dynamically at run time how to achieve it? 11) How can u modify a particular field of a PF through RPG?
Page 34 of 35
RTVNETA - SYSNAME (8) STRTCPFTP - RMTSYS('intnetadr intnetadr(143.98.100.44)') RTVMBRD FILE(PF1) MBR(&JAN2005) NBRCURRCD(&RECCNT) If cond(&reccnt *eq 0) then(goto cmdlbl(endpgm)) if cond(&system *eq &testsys) then(FTP RMTSYS(dublin2)) else cmd(FTP RMTSYS(LASVEGAS)) RCVMSG MSGDTA(&MSGDTA) MSGID(&MSGID) MSGF(&MSGF) + MSGFLIB(&MSGFLIB) RTVSYSVAL CVTDAT SYSVAL(QDATE) RTNVAR(&DATE) DATE(&DATE) TOVAR(&YMD) FROMFMT(*SYSVAL) + TOFMT(*YMD) TOSEP(*NONE) RTVJOBA JOB(&WSID) USER(&USER) TYPE(&TYPE) bypass the prompt screen if batch FQSYSPRT F F O F 198 PRINTER PRTCTL(LINE:*compat) OFLIND(*INOF) USROPN
Page 35 of 35