Chapter 2 OS/390 and z/OS concepts and terms Murachs OS/390 and z/OS JCL 2002, Mike Murach & Associates, Inc. Chapter 2, Slide 1 Objectives Applied objective Murachs OS/390 and z/OS JCL Assign an appropriate name to a new data set. Chapter 2, Slide 2 Objectives (continued) Knowledge objectives Identify what an address space is. In general terms, explain how address spaces are used to implement virtual storage and multiprogramming. In general terms, explain how paging is used to transfer portions of an address space to and from real storage.
In general terms, explain how swapping is used to transfer entire address spaces in and out of virtual storage. Identify the information contained in a volume label. Describe the role of the VTOC in processing DASD data sets. Describe the three data set organizations that are most commonly used today: sequential, partitioned, and VSAM key-sequenced. Distinguish between master and user catalogs. Describe how the high-level qualifier in a data set name is commonly used. Murachs OS/390 and z/OS JCL Chapter 2, Slide 3 Objectives (continued) Distinguish between EBCDIC and ASCII notation. Describe unit allocation, volume allocation, and data set allocation.
List and describe the three types of open modes that can be used to open a file. Distinguish between a job and a job step. Identify the basic functions of the JOB, EXEC, and DD JCL statements. Describe the basic function of a Job Entry Subsystem. Name the five steps that are involved in processing a job. Describe how the job class and priority affect the scheduling of a job. Describe the four types of SYSOUT data that are produced by most jobs: the JES message log, the JCL listing, the system message log, and program output. Describe how the output class affects the handling of a SYSOUT data set. Distinguish between system generation and system initialization. Murachs OS/390 and z/OS JCL Chapter 2, Slide 4
Address spaces Address space Addressable storage locations Processor Mai n st orag e CP U Murachs OS/390 and z/OS JCL Figure 2-01a Chapter 2, Slide 5 Address space facts Each storage location in an address space can store one byte of information. You must use a binary numbering scheme to address each particular location in an address space. An address space is the complete range of addresses that can be accessed by the processor. System/370 processors use a 24-bit binary numbering scheme to represent addresses. This allows for 16MB of addressable storage. S/390 system architecture uses a 31-bit binary numbering scheme. Addressable storage can be up to 2GB. z/Series server architecture uses a 64-bit binary numbering scheme. Currently, the largest z900 server has an address space of 64GB. Murachs OS/390 and z/OS JCL Figure 2-01b Chapter 2, Slide 6 Multiple virtual storage
Page frames Address space 1 Real storage Address space 2 Address space 3 Address space 4 2GB 4K page Expanded storage (S/390 processors) Page data set (DASD) 8GB 2GB 2GB 2GB 2GB
Active pages Page slots Murachs OS/390 and z/OS JCL Figure 2-02a Chapter 2, Slide 7 Multiple virtual storage facts Virtual storage allows a processor to treat DASD as an extension of real storage. Multiple virtual storage (MVS) uses expanded storage and DASD to simulate several independent address spaces. Virtual storage is divided into 4K sections called pages. Pages in real storage are held in page frames. Pages in the DASD area of virtual storage are held in page slots. Transferring data from a page slot to a page frame is called a pagein. Data from a page frame to a page slot is called a page-out. Murachs OS/390 and z/OS JCL Figure 2-02b Chapter 2, Slide 8 Address space swapping under OS/390 Page data sets Address space 1 (swapped in) Swap data sets Real storage Address
space 2 (swapped in) Address space 3 (swapped in) Address space 4 (swapped in) Address space 5 (swapped out) Address space 6 (swapped out) Address space 7 (swapped out) Address space 8 (swapped out) CPU Murachs OS/390 and z/OS JCL Figure 2-03a Chapter 2, Slide 9 Address swapping facts OS/390 uses a process called swapping to transfer entire address spaces in and out of virtual storage as needed. When an address space is swapped out, its critical pages are written to a special data set called a swap data set.
When the processor can accommodate the job again, its address space is swapped in so it can continue to process. Some programs (like parts of the operating system itself) need to run in real mode rather than virtual mode. Programs running in real mode are not subject to paging or swapping processes. These type of programs are considered to be resident in real storage. Murachs OS/390 and z/OS JCL Figure 2-03b Chapter 2, Slide 10 A virtual storage address space Virtual storage Extended LSQA, SWA, and subpool 229/230 2GB Unallocated storage Extended private area Extended user region Extended common area Extended SQA, PLPA, and CSA Extended nucleus 16MB Nucleus Common area SQA, PLPA, and CSA LSQA, SWA, and subpool 229/230 Private
area Murachs OS/390 and z/OS JCL Unallocated storage User region System region 0MB Figure Chapter 2, Slide2-04a 11 Virtual address space facts Address spaces are divided into two basic areas: the private area and the common area. To provide compatibility for software written for 24-bit systems, 31-bit and 64-bit processors and their operating systems include special provisions for the first 16MB of address space memory. As a result, the private and common areas each have two sections. One above the 16MB line and one below it. The common area contains the OS/390 nucleus as well as other operating system data. The private area contains data thats unique to each users address space, including the program thats being executed. Murachs OS/390 and z/OS JCL Figure 2-04b Chapter 2, Slide 12 Dataspaces and hiperspaces on an S/390 system Address space Dataspace Real
storage Hiperspace Expanded storage Murachs OS/390 and z/OS JCL 4KB blocks Figure 2-05a Chapter 2, Slide 13 Description OS/390 lets a job or user create one or more additional address spaces that can be used to hold large amounts of data. These additional address spaces can be one of two types: dataspaces or hiperspaces. Dataspaces can only contain data, and their contents are managed directly by user-written programs. They reside in normal virtual storage and are subject to paging and swapping operations. Hiperspaces can contain both data and programs. Their contents are managed by the operating system and are made available to application programs in 4KB units. On S/390 systems, hiperspaces reside only in expanded memory and are never brought into real storage. On zSeries systems, hiperspaces reside only in real storage. Murachs OS/390 and z/OS JCL Figure 2-05b Chapter 2, Slide 14 How DASD labels identify files on a disk volume Disk volume
VOL1 label VTOC VTOC FILE-A FILE-B FILE-C FILE-B Free extents Free extent FILE-A FILE-B FILE-C Free extent FILE-B Free extent OS/390 identifies data sets stored on DASD with special records called labels. All DASD volumes contain a volume label, or VOL1 label, that identifies the volume serial number (vol-ser) as well as the disk address for the VTOC. The VTOC (Volume Table of Contents) contains labels called Data Set Control Blocks, or DSCBs, that provide information about all the data sets and available space on the volume. The DSCB for a data set includes the data sets name and location.
Murachs OS/390 and z/OS JCL Figure 2-06a Chapter 2, Slide 15 Rules for forming data set names Length Characters Qualifiers First character Last character 1 to 44 characters (standard) 1 to 35 characters (generation data group; see chapter 12) Only first 17 characters are used for tape data sets Alphanumeric (A-Z, 0-9) National (@,#, and $) Period (.) Data set names with more than 8 characters must be broken into qualifiers that each contain between 1 and 8 characters. Separate qualifiers from one another with periods. The periods are counted in the overall length of the data set name. The first character of each qualifier must be a letter or national character. The last character of a data set name should not be a period. A valid data set name AR.TRANS.Y2001 Murachs OS/390 and z/OS JCL Figure 2-06b Chapter 2, Slide 16 A file with sequential organization by employee number
Disk location 1 2 3 4 5 Social Security number First name 498-27-6117 213-64-9290 279-00-1210 499-35-5079 334-96-8721 Thomas William Constance Ronald Marie Employee Middle initial Last name number T J M L Bluestone Collins Harris Garcia Abbott 01003
01054 01702 02145 02181 A file with VSAM key-sequenced organization, indexed by employee number Index component Employee Disk number location 01003 01054 01702 02145 02181 1 2 3 4 5 Murachs OS/390 and z/OS JCL Data component Disk location 1 2 3 4 5 Social Security number 498-27-6117 213-64-9290 279-00-1210
499-35-5079 334-96-8721 First name Thomas William Constance Ronald Marie Figure 2-07a Middle initial Last name T J M L Bluestone Collins Harris Garcia Abbott Employee number 01003 01054 01702 02145 02181 Chapter 2, Slide 17 The four types of Non-VSAM data set organization Sequential Indexed-sequential Direct Partitioned (PDS)
The three types of VSAM data set organization Entry-sequenced data sets (ESDS) Key-sequenced data sets (KSDS) Relative-record data sets (RRDS) Murachs OS/390 and z/OS JCL Figure 2-07b Chapter 2, Slide 18 A partitioned data set with three members Data set name: MM01.TEST.COBOL Directory PAY1000 PAY2000 PAYTRAN ... Member PAY1000 IDENTIFICATION DIVISION. * PROGRAM-ID. PAY1000. * ENVIRONMENT DIVISION. * INPUT-OUTPUT SECTION. * FILE-CONTROL. * SELECT PAYMAST ASSIGN TO PAYMAST. . . . Member PAYTRAN 01
. Murachs OS/390 and z/OS JCL Figure 2-08a Chapter 2, Slide 19 Partitioned data set facts A partitioned data set, or library, consists of one or more members, each of which can be processed as if it were a separate sequential file. There are two types of partitioned data set organization: standard PDS and PDSE (partitioned data set extended). To keep track of members in a PDS, each members name is stored in a directory. Members of a PDS are usually processed individually, but the entire library can also be processed as a unit. Murachs OS/390 and z/OS JCL Figure 2-08b Chapter 2, Slide 20 The relationships among the master catalog, user catalogs, and data sets Master catalog VSAM data sets User catalogs Non-VSAM
data sets VSAM data sets Murachs OS/390 and z/OS JCL Figure 2-09a Non-VSAM data sets Chapter 2, Slide 21 Catalog facility facts The Integrated Catalog Facility (ICF) records the locations of files so that you dont have to know the volume serial number for the volume that contains the file you want. There are two types of catalogs: master catalogs and user catalogs. The master catalog contains entries that identify system data sets and user catalogs. User catalogs contain entries that identify user data sets. VSAM files must be cataloged.
Non-VSAM files are stored in data set labels in the VTOC, these files dont have to be cataloged. The high-level qualifier in a data set name often indicates the user catalog in which the data set is cataloged. User catalogs typically have several aliases. That way, files with different high-level qualifiers can be cataloged in the same user catalog. Murachs OS/390 and z/OS JCL Figure 2-09b Chapter 2, Slide 22 The eight bits in the binary code for the letter M 1101 0100 The hex code for the letter M D4 A binary-to-hexadecimal conversion chart Binary Hex Binary Hex Binary Hex Binary
Hex 0000 0001 0010 0011 0 1 2 3 0100 0101 0110 0111 4 5 6 7 1000 1001 1010 1011 8 9 A B 1100 1101 1110 1111 C D E F
Murachs OS/390 and z/OS JCL Figure 2-10a Chapter 2, Slide 23 The EBCDIC codes for alphanumeric characters Character Hex space . ( + & $ * ) ; - 40 4B 4D 4E 50 5B 5C 5D 5E 60 Character Hex A B C D E F
G H I C1 C2 C3 C4 C5 C6 C7 C8 C9 Character Hex J K L M N O P Q R D1 D2 D3 D4 D5 D6 D7 D8 D9 Character Hex Character Hex S T U
V W X Y Z E2 E3 E4 E5 E6 E7 E8 E9 0 1 2 3 4 5 6 7 8 9 F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 Note Although IBM mainframes use EBCDIC, most other computers use ASCII
(American Standard Code for Information Interchange). Data transferred to or from the mainframe has to be converted from ASCII to EBCDIC or vice versa. Murachs OS/390 and z/OS JCL Figure 2-10b Chapter 2, Slide 24 The three levels of data set allocation Level 1: Unit allocation You can allocate a unit by specifying a generic name or group name for a specific device. A generic name is an IBM-supplied name that indicates a device type, like 3380 for a 3380 disk drive. A group name, sometimes called an esoteric name, is the most flexible way to allocate units. Most installations define a group name of SYSDA to identify the DASD devices available for general use. Level 2: Volume allocation A specific volume request identifies a particular volume to be allocated for a new or existing file by specifying the volume serial number (vol-ser). In a non-specific volume request, you dont specify a vol-ser. Instead, you let OS/390 select the volume on which the new data set will be created. Non-specific volume requests arent valid for
existing data sets. Level 3: Data set allocation For new data sets, file labels are created, space for the data set is allocated, and the VTOC is updated to indicate the allocation. Murachs OS/390 and z/OS JCL Figure 2-11 Chapter 2, Slide 25 How data sets are processed OS/390 Program I/O requests Read Data set open modes Input Access methods QSAM Write Output Data VSAM Read/ Rewrite Murachs OS/390 and z/OS JCL
I/O Figure 2-12a Chapter 2, Slide 26 Data set processing facts An access method is an interface between an application program and the physical operations of I/O devices. Two of the most common access methods are QSAM and VSAM. For sequential files or members of a partitioned data set, QSAM (Queued Sequential Access Method) is used. VSAM provides support for its key-sequenced, entry-sequenced, and relative-record data sets. Before a program can issue any I/O requests to a file, it must issue an OPEN instruction. There are three open modes you can use: input mode, output mode, and I/O mode. Murachs OS/390 and z/OS JCL Figure 2-12b Chapter 2, Slide 27 Jobs, Job Control Language and JES Job The execution of one or more related programs in sequence. Job Control Language (JCL) A set of control statements that provide the specifications necessary to process a job. Job Entry Subsystem (JES) Keeps track of jobs that enter the system, presents them to OS/390 for processing, and sends their spooled output to the correct destination. There are two versions of JES: JES2 and JES3. Murachs OS/390 and z/OS JCL Figure 2-13a
Chapter 2, Slide 28 Three basic JCL statements JOB Provides information that identifies the job. EXEC Indicates the name of the program to be executed. DD Identifies a file to be processed by the program. JCL statements for a job that prints a report //MM01RN JOB (36512),'R MENENDEZ',NOTIFY=MM01 //RPTRUN EXEC PGM=RPT3000 //CUSTMAST DD DSNAME=MM01.CUSTOMER.MASTER,DISP=SHR //SALESRPT DD SYSOUT=A //ERRLIST SYSOUT=A DD
How JES2 and JES3 process jobs The job is submitted Murachs OS/390 and z/OS JCL The job is selected for execution The job is executed Figure 2-13b The jobs output is processed The job is purged Chapter 2, Slide 29 How a job is entered into the system Jobs are created by entering JCL commands into a display terminal. To enter, or submit, the job into the system, the terminal user issues a SUBMIT, or SUB, command. JES2 or JES3 then to reads the job stream copies it to the job queue on the JES spool. How a job is scheduled for execution JES examines the jobs in the job queue and prioritizes the work, selecting the most important jobs to be executed first. Job class and priority are two characteristics that JES uses to classify a jobs importance. An initiator is a program that runs in the system region of an address space thats eligible for batch job processing. Each initiator can handle one job at a time. Murachs OS/390 and z/OS
JCL Figure 2-14a Chapter 2, Slide 30 Typical job class assignments Job class Characteristics A The job will execute within 15 minutes of submission. B The job will execute within 30 minutes of submission. C The job will execute within 1 hour of submission. D The job will execute overnight. H The job is held until released by an operator. The job will execute within 15 minutes of submission but each step is limited to 1 minute of execution time. How job classes are assigned to initiators Initiator Eligible job classes 1
A 2 B,C,D,H,L 3 B,C 4 C Murachs OS/390 and z/OS JCL Figure 2-14b Chapter 2, Slide 31 How a job is executed once an initiator selects it Private area Local system areas Control blocks Private area Local system areas Control blocks Private area Local system areas Control blocks Private area Local system areas Control blocks User program System region
System region Interpreter System region System region Allocation Unallocation Initiator After the initiator selects a job for execution, it invokes the interpreter, which builds the required control blocks in the address spaces SWA. Murachs OS/390 and z/OS JCL Figure 2-15 Initiator For each job step, the initiator invokes allocation routines to allocate the units, volumes, and data sets required by the job step. Initiator After the job steps resources have been allocated, the initiator
creates a user region, loads the user program into it, and transfers control to the user program. Initiator When the user program completes, the initiator invokes unallocation routines to deallocate the resources used by the job step. Then, if the job has more steps, the initiator repeats the allocationexecution-unallocation process. Chapter 2, Slide 32 The SYSOUT data sets produced by most jobs SYSOUT data set Description JESMSGLG The JES message log is a listing of messages produced by JES2 or JES3 as the job was executed. JESJCL The JES JCL listing is a listing of the JCL processed by the job. JESYSMSG The system message log is a collection of messages produced by OS/390 as the job was executed. Program SYSOUT SYSOUT data produced by a program executed in the job.
Typical output class assignments Output class Type of output A Standard printer output, usually routed to one of the installations high-speed printers and printed on standard computer paper. B Special printer output. X Held output that stays on the SYSOUT queue until its released for printing or deleted. Murachs OS/390 and z/OS JCL Figure 2-16 Chapter 2, Slide 33 A partial list of products found in OS/390 (part 1) Product Description TSO/E TSO/E (Time Sharing Option/Extended) is a subsystem that lets terminal users invoke system facilities interactively. ISPF ISPF (Interactive System Productivity Facility) runs as part of TSO/E and takes advantage of the full-screen capabilities of display terminals.
VTAM VTAM (Virtual Telecommunications Access Method) provides centralized control over all of the terminal devices attached to the system. CICS CICS (Customer Information Control System) makes it possible for the system to run interactive application programs written in COBOL, PL/I, assembler language, C, C++, or Java. DB2 DB2 (Database 2) is a database management system. It manages relational databases that can be accessed using SQL (Structured Query Language). RACF RACF (Resource Access Control Facility) identifies both users and system resources such as data sets. It ensures that a user has the correct authority to access system resources and facilities. Murachs OS/390 and z/OS JCL Figure 2-17a Chapter 2, Slide 34 A partial list of products found in OS/390 (part 2) Product Description SMS SMS (Storage Management Subsystem) is an automated storage management system that removes many of the manual procedures associated with managing data sets.
UNIX UNIX System Services allow OS/390 to run UNIX applications and process files from UNIX systems. WLM WLM (Workload Manager) allows you to define performance goals and assign an importance to each goal. Websphere Websphere is a Java-based application server designed to enable e-business transactions. It supports servlets, JavaServer Pages (JSPs), and Enterprise JavaBeans (EJBs). Utility programs The operating system provides a set of general-purpose utility programs to perform such functions as copying files and sorting file records. Murachs OS/390 and z/OS JCL Figure 2-17b Chapter 2, Slide 35 System generation System generation (sysgen) is the process of creating the OS/390 system. IBM sends an installation the basic components that make up OS/390 on a series of tapes called distribution libraries. System generation selects and assembles the various components an installation needs to create a working operating system. To control system generation, a systems programmer codes special macro instructions that specify how the components from the distribution libraries should be put together. The output from sysgen is a series of system libraries that contain, among other things, the executable code that makes up the operating system.
Murachs OS/390 and z/OS JCL Figure 2-18a Chapter 2, Slide 36 System initialization System initialization is the process of starting a previously generated OS/390 system, either immediately after sysgen or when the system has to be reinitialized due to system maintenance or a system error. To begin a system initialization, the system operator uses the system console to start an Initial Program Load, or IPL. That causes the system to clear its real storage and begin the process of loading the operating system into storage from the system libraries. Murachs OS/390 and z/OS JCL Figure 2-18b Chapter 2, Slide 37 System libraries Data set Description SYS1.NUCLEUS Contains, among other things, the OS/390 nucleus program. The members of this library are created during sysgen. SYS1.PARMLIB Contains several options OS/390 is to use when the system is initialized. SYS1.LINKLIB
Contains executable programs that are either a part of the operating system or are written by users. SYS1.LPALIB Contains executable programs that are part of the link pack area (LPA). SYS1.MACLIB Contains the assembler macro instructions that are used for sysgen as well as other instructions that provide a standard interface for the operating systems facilities such as access methods. SYS1.PROCLIB Contains standardized JCL statements called procedures that can be used by the jobs that invoke them. SYS1.CMDLIB Contains the program modules that implement the various TSO/E commands you enter from a TSO terminal. SYS1.LOGREC Contains information about hardware problems. Murachs OS/390 and z/OS JCL Figure 2-18c Chapter 2, Slide 38
Theme Project - Day 2 . Meet with your group to complete the first task. Theme in Novel: Dot jot a list of places in the novel where the plot or something a character says or does clearly shows this...
…..if while writing the question you think this is a straightforward concept - how can I make it complicated, this is a reason to pause! Should be as short as possible. Include only relevant information. Be as realistic as possible....
Breeding expands on these topics and provides a basic explanation of cloud computing that focuses on real advantages and disadvantages for libraries. ... Microsoft Skydrive (7GB+) Mostly used as supplemental storage and for sharing. ... Access to API's.
A mark of good provenance is that a person not directly involved with the project is able to follow the data through its life cycle and understand any steps used to create outputs. Good provenance allows for the ability to...
Increase in SCr by ≥0.3 mg/dl (≥26.5 lmol/l) within 48 hours; or. Increase in SCr to ≥1.5 times baseline, which is known or presumed to have occurred within the prior 7 days; or . Urine volume of <0.5 ml/kg/hr for...
Venue: RMIT University Storey Hall, Building 16, Level 7, 336-348 Swanston Street Melbourne Victoria Australia. ... Up to 85% of jobs are NOT advertised. Up to 85% of business is done by referral. Best ways to get work - Networking,...