Beruflich Dokumente
Kultur Dokumente
Control Language
Rashmi Pratap
Agenda
What is Control Language Use of Control Language
Control Language
Control language (CL) is the primary interface to the operating system and can be used at the same time by users at different work stations. Single control language statement is called a command.
Control system power up and power down. Change the configuration of the system Manage work on the system by controlling subsystems, job queues, job priorities, memory pools, time slices and so on. Start other jobs by calling programs directly or by submitting jobs to batch processing.
Control system security by actually changing user and object authorities. Control all forms of communications between your AS/400 and other systems (peers, hosts, PCs, remote controllers). Manage objects in libraries.
Programming
Programming
Creating a CL program Interactive The iSeries server provides the Programmer Menu, the Command Entry display, command prompt displays, and the Programming Development Manager (PDM) Menu. The most frequently used source entry method is the source entry utility (SEU).
Programming(contd)
Batch To ensure best performance for interactive jobs, work that is batch in nature should be removed and executed separately as batch jobs. Use WRKSBMJOB command to monitor batch jobs. A batch job is submitted using the SBMJOB command.
Parts of a CL procedure
Start Declare Program-Level Monitor message IBM Commands PGM (Optional) (DCL, DCLF) MONMSG MONMSG IF ELSE COMMAND MONMSG MONMSG
ENDPGM (optional)
VALUE()
VALUE
*DEC
DEFAULT(15 5) MAX(15 9)
DEFAULT(32) MAX(9999) 1
DEFAULT(0)
*CHAR
DEFAULT(Blank)
*LGL
CHGVAR
Used to change the contents of a variable. Can also be used to perform arithmetic calculations.
Return variables are used to return a value in a CL program RTV group of commands are used to return external information into the program
CALL Command
When called program finishes running, control returns to the next command in the calling program. CL Program can call itself.
The sequence of CALL commands in a set of programs calling each other is the call stack.
RETURN Command
Removes the procedure or OPM program containing RETURN command, from the call stack. If the procedure containing the RETURN command was called by a CALLPRC command, control is returned to the next sequential statement after that CALLPRC command in the calling program.
If a MONMSG command specifies an action that ends with a RETURN command, control is returned to the next sequential statement after the statement that called the procedure or program containing the MONMSG command.
Has no parameters
TFRCTL COMMAND
The TFRCTL program, passes control to the program, then removes the calling program from the call stack. Control is returned to the next higher program in the call stack.
All subsequent statements in the calling program are ignored and the calling program itself ends.
Information to be passed specified on the PARM parameter on the CALL command. Example: Program A: CALL PROGB PARM(&AREA) then it calls PROGB and passes value &AREA to it. Program B: PGM PARM(&AREA)
Parameters are passed by position. Parameters listed in the receiving procedure or program must be declared as the same length and type as they are in the calling procedure or program. When calling an OPM CL program, the number of parameters that are passed to it must exactly match the number that is expected by the program.
Interprogram Communication
When you spread the work among several programs, however, you quickly realize that you need a method to pass information between them. One program must be able to communicate with others.
Information can be passed between programs using any of the following: Database files Parameters. Data areas, including the local data area (LDA) Switches. Messages Data queues
Data Area
Data areas are objects of type *DTAARA that you can create and delete at will.
A data area is an area of storage with a name, but without any structure. You cannot define fields within data areas. Used to store information. One program can write information to it and another can read that information at a later time Asynchronous Communication
Allow to establish communication between two or more programs that may be running in different jobs Possible because data areas are permanent objects (type *DTAARA) that are independent of any job.
1024 bytes Automatically created for each job. Type: *char Cannot be deleted Available till the job ends. CRTDTAARA and DLTDTAARA do not apply to it
512 byte group data area. Automatically created for each group job. Type: *char Cannot be deleted when job stops being a group job (or when it ends), the *GDA is deleted by system. CRTDTAARA and DLTDTAARA do not apply to it
2000 characters long. Automatically created. Type: *char CRTDTAARA and DLTDTAARA do not apply to it
Example:
CRTDTAARA DTAARA(AMERITOR/TEMPDTA) TYPE(*CHAR) LEN(100) VALUE('Sample Data Area) This creates a character type data area: TEMPDTA of length 100 in library AMERITOR. It has been assigned an initial value: Sample Data Area.
The output can be directed to the display or to a printer, depending on the value given to the OUTPUT parameter.
Example:
DSPDTAARA DTAARA(AMERITOR/TEMPDTA)
Contents of Data area can be changed using: Change Data Area (CHGDTAARA) command.
Requires:
Qualified name of data area Position within the data area to be changed length of the data to be changed New data to be placed.
The Retrieve Data Area (RTVDTAARA) command can be used in a CL program to place the contents of a data area (or a portion thereof) into a CL variable. To retrieve the second, third and fourth characters of data area TEMPDTA into variable &PART as follows: RTVDTAARA DTAARA(AMERITOR/TEMPDTA (2 3)) RTNVAR(&PART)
AMERITOR/TEMPDTA PGM DCL VAR(&PART) TYPE(*CHAR) LEN(10) RTVDTAARA DTAARA(AMERITOR/TEMPDTA(2 3)) + RTNVAR(&PART) ENDPGM
amp
The CHGDTAARA command uses a *SHRUPD (shared for update) lock on the data area during command processing.
The RTVDTAARA and DSPDTAARA commands use a *SHRRD (shared for read) lock on the data area during command processing. To perform more than one operation on a data area, use the Allocate Object (ALCOBJ) command to prevent other users from accessing the data area until your operations are completed.
Data Queues
Data queues have been improved to communicate between active procedures and programs. For storing large volumes of data or large numbers of entries use database files. When using data queues, you should include abnormal end routines in your programs to recover any entries not yet completely processed before the system is ended.
DTAQ similar to MSGQ in that procedures and programs can send data to the queue that is received later by another procedure or program.
More than one program can have a receive pending on a data queue at the same time, while only one program can have a receive pending on a message queue at the same time.
Referring to Files
Files are accessed during compiling of DCLF commands when CL modules and programs are created so that variables can be declared for each field in the file.
If library list used at compile time, the file must be in a library on the library list at run time.
Only 1 file can be referred The file referred to is implicitly opened when first send, receive, or send/receive operation performed. An opened display file remains open until the procedure or OPM program in which it was opened returns or transfers control. An opened database file is closed when end of file is reached, or when the procedure or OPM program in which it was opened returns or transfers control.
Once closed, a DB file cannot be opened again during the same call of the procedure or OPM program. By default first member of DB file opened unless OVRDBF used. If procedure or program ends in error, the files close. File remains open until the procedure or OPM program in which that file was opened ends=>an easy way to share ODPs between running procedures and programs.
Conditions for ODP sharing: The file was created with or has been changed to have the SHARE(*YES) attribute. An override for that file by specifying SHARE(*YES) is in effect.
Display file opened in a CL proc or OPM program always opens for both input and output. DB file opened in a CL proc or OPM program opens for input only.
Declaring a File
DCLF command - for both DSPF and DB files. Only 1 DCLF allowed in a CL proc/pgm. Parameters: DCLF FILE(library-name/file-name) RCDFMT(record-format-names) Only 1 DCLF allowed in a CL proc/pgm. File must exist before the module or program is compiled.
When processing a DCLF command, the CL compiler declares CL variables for each field and option indicator in each record format in the file. For a field, the CL variable name is the field name preceded by an ampersand (&). For an option indicator, the CL variable name is the indicator that is preceded by &IN. Up to 50 record format names can be specified on one command, but none can be variables. Only one record format may be specified for a database file.
When RCVF command is run, the next record on the files access path is read, and the values of the fields defined in the database record format are placed in the corresponding CL variables. When EOF reached, message: CPF0864 is sent to the procedure or OPM program CL vars. declared for record format. not changed by processing of RCVF command. Attempt to run additional RCVF commands after end of file has been reached=> message CPF0864 is sent again.
Agenda
Messages Creating a Message File Adding Messages Sending Messages From a CL Monitoring Messages in CL Message Logging
Messages
Communication between Procedures or programs Jobs Users Users and procedures or program occurs through messages.
Messages
Types of messages: Predefined Messages: Created before they are used. These messages are placed in a message file when they are created, and retrieved from that file when they are used.
Immediate Messages: Created by the program or system user when they are sent and are not permanently stored in the system.
Adding Messages
Add Message Description (ADDMSGD) Describes the pre-defined messages. Adds them to the message file created. Specifications for ADDMSGD command
Message identifier Message description Message file name
SNDMSG Used by a display station user to send an immediate message from his display station to one or more message queues.
SNDBRKMSG Used to send an immediate message to one or more work station message queues.
Message Queue
When a message is sent to a procedure, a program, or a system user, it is placed on a message queue associated with that procedure, program, or user.
OS/400 provides message queues for: Work station on the system User enrolled on the system System operator System history log
Messages Types
Inquiry and Informational Messages Inquiry message is sent and the message queue receiving the message must reply to it.
Messages Types
Completion and Diagnostic Messages Completion message indicates the status of the work that is successfully performed. Diagnostic messages provide information about errors detected by the program.
Messages Types
Status Messages The status message describes the status of work performed by the sending program.
Messages Types
Receiving Messages
Receive Message (RCVMSG) To receive messages from a message queue for your procedure or program. Messages can be received in the following ways: By message type By message reference key By its location on the message queue. By both message type and message reference key
Retrieving Messages
Retrieve Message (RTVMSG) To retrieve the text of a message from a message file into a variable.
Example:
DCL &FILE TYPE(*CHAR) LEN(10) VALUE(INVENT) DCL &LIB TYPE(*CHAR) LEN(10) VALUE(QGPL) DCL &A TYPE(*CHAR) LEN(20) DCL &MSG TYPE(*CHAR) LEN(50) CHGVAR VAR(&A) VALUE(&FILE||&LIB) RTVMSG MSGID(USR1001) MSGF(QGPL/USRMSG) + MSGDTA(&A) MSG(&MSG)
RMVMSG , CLRMSGQ,
You can remove: 1. A single message 2. All messages 3. All except unanswered messages 4. All old messages 5. All new messages 6. All messages from all inactive programs
Monitoring Messages in CL
You can monitor for messages using two levels of MONMSG commands: Procedure level Specific command level
Messages that are monitored are: Escape messages Notify messages Status messages
Message Logging
The two types of logs for messages are:
Job log History log Job log contains information related to requests entered for a job. QHST log contains system data, such as a history of job start and end activity on your system.
JOB Log
Each job has an associated job log that can contain the following for the job:
Commands in the job. Commands in a CL program if the CL program was created with the LOG(*YES) option or with the LOG(*JOB). All messages and message help sent to the requester.
JOB Log
Using LOG parameter on the CRTJOBD, user can control what information the system writes in the job log.
Values make up the LOG parameter are: Message level Message severity Message text level
Logging CL Command
LOGCLPGM controls weather CL commands are logged or not. LOGCLPGM is a parameter in the jobs job description.
User can change it using CHGJOBD or CHGJOB command.
History Log
History log (QHST) consists of Message queue Physical file known as log-version History log (QHST) contains System Information, Subsystem Information, Job start/completion Device status, QSYSOPR messages.
Retrieve Job Attributes (RTVJOBA) Used in a CL program to retrieve the values of one or more job attributes and place the values into the specified CL variable.
RTVJOBA JOB(&JOB) USER(&USER) NBR(&NBR)
RTVUSRPRF RTNUSRPRF(&USRPRF)
Open Query File (OPNQRYF) This command opens a file to a set of database records that satisfies a database query request.
QUESTION?