ZOS System Operations Students Handbook ES271

Instructor Guide
Publishing Information This publication has been produced using BookMaster (Program Number 5668-015), the Document Composition Facility (Program Number 5748-XX9), and Freelance 2.1 for Windows. It was printed on the IBM 3820 Page Printer.
August, 1998 The information contained in this document has not been submitted to any formal IBM test and is distributed on an as is basis without any warranty either express or implied. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customers ability to evaluate and integrate them into the customers operational environment. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will result elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk.
Copyright International Business Machines Corporation 1997, 1998. All rights reserved.
This document may not be reproduced in whole or in part without the prior written permission of IBM. Note to U.S. Government Users Documentation related to restricted rights Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Instructor Guide
Trademarks IBM is a registered trademark of International Business Machines Corporation. The following are trademarks International Business Machines Corporation in the United States, or other countries, or both: ACF/VTAM AD/Cycle ADSTAR Advanced Peer-to-Peer Networking AIX AIX/ESA AIX/6000 AnyNet Application System/400 APPN AT BookMaster C/370 CICS CT CUA DB2 DFSMS 3090 400 DFSMS/MVS DFSORT Enterprise Systems Connection Architecture ES/9000 ESA/390 ESCON GDDM IBM IMS Multiprise MVS/DFP MVS/ESA MVS/SP MVS/XA NetView OfficeVision Open Blueprint OpenEdition OS/390 OS/2 OS/390 OS/400 Parallel Sysplex PR/SM RACF RETAIN RS/6000 S/390 San Francisco SP Sysplex Timer System/360 System/370 System/390 VM/ESA VTAM
1-2-3/G and Notes Mail are trademarks of Lotus Development Corporation in the United States, or other countries, or both. TME and Tivoli are trademarks of Tivoli Systems Inc. in the United States, or other countries, or both. MCS is a registered trademark of Intel in the United States, or other countries, or both. Microsoft, Windows, Windows NT and the Windows 95 logo are trademarks or registered trademarks of Microsoft Corporation. ActionMedia, LANDesk, MMX, Pentium, and ProShare are trademarks or registered trademarks of Intel Corporation in the U.S. and other countries. UNIX is a registered trademark in the United States and other countries licensed exclusively through X/Open Company Limited. Other company, product, and service names may be trademarks or service marks of others.
Copyright IBM Corp. 1997, 1998

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
iii
Instructor Guide
iv
OS/390 System Operations
Instructor Guide
Contents
Instructor Course Overview Course Description Agenda
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii ix xi
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Units
Unit 1. Review of S/390 and OS/390 Objectives . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1-1 1-2 1-5 1-6 1-8 1-10 1-12 1-16 1-18 1-22 1-24 1-26 1-30 1-33 1-34 1-38 1-42 1-44 1-46 1-50 1-54 1-58 1-61 1-64 2-1 2-2 2-4 2-7 2-8 2-12 2-16 2-18 2-20 2-22 2-24 2-26
v
1.1 System/390 Overview . . . . . . . . . . . . . . . . . System/390 Overview . . . . . . . . . . . . . . . Processor Types . . . . . . . . . . . . . . . . . . . Modes of Operation . . . . . . . . . . . . . . . . . Logical Partitioning / Partitioning with VM . . . . . . . . . . . . . Overview of Partitioning Coupling Systems . . . . . . . . . . . . . . . . . . Enterprise Systems Architecture: Hardware System/390 Overview . . . . . . . . . . . . . . . What Is OS/390 . . . . . . . . . . . . . . . . . . . . IS Installation Requirements . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 OS/390 Overview . . . . . . . . . . . . . . . . . . . . . OS/390 Overview . . . . . . . . . . . . . . . . . . . . OS/390 Elements and Features . . . . . . . . . . OS/390 Delivery . . . . . . . . . . . . . . . . . . . . Large Systems Storage Hierarchy . . . . . . . The Concept of Virtual Storage . . . . . . . . . . Address Space, Data Space and Hyperspace Paging and Swapping . . . . . . . . . . . . . . . . MVS Data Set Types . . . . . . . . . . . . . . . . . Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unit Summary . . . . . . . . . . . . . . . . . . . . . . Unit 2. Overview JES, TSO Objectives . . . . . . . OS/390 Overview . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 Overview of JES2, JES3, and TSO Job Entry Subsystem . . . . . . . JES3 - Job Processing Phases JES2 Requirements . . . . . . . . Types of JES2 Starts . . . . . . . JES2 Commands . . . . . . . . . . TSO Introduction . . . . . . . . . . TSO Logon Panel . . . . . . . . . ISPF/PDF Introduction . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
Instructor Guide
Establishing a TSO Session . . . . . ISPF Main Menu . . . . . . . . . . . . . PDF Main Menu . . . . . . . . . . . . . MVS Data Sets . . . . . . . . . . . . . . Data Set Naming Conventions . . . Sequential Data Sets . . . . . . . . . . Partitioned Data Sets . . . . . . . . . . VSAM Data Sets . . . . . . . . . . . . . ISPF Utility Data Set View Panel . . ISPF Utility Data Set Allocate Panel JCL Sample . . . . . . . . . . . . . . . . Procedures . . . . . . . . . . . . . . . . . Checkpoint . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . Unit 3. MVS/ESA or OS/390 IPL Flow Objectives . . . . . . . . . . . . . . . OS/390 Overview . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2-28 2-30 2-32 2-34 2-36 2-38 2-40 2-42 2-44 2-46 2-48 2-50 2-53 2-54 3-1 3-2 3-4 3-7 3-8 3-10 3-12 3-14 3-16 3-18 3-24 3-26 3-32 3-34 3-36 3-39 3-42 4-1 4-2 4-4 4-7 4-8 4-10 4-12 4-16 4-18 4-20 4-22 4-24 4-28 4-30 4-32 4-34 4-36
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 MVS/ESA or OS/390 IPL . . . . . . . . . UCW and UCB Generation . . . . . . Activate Task . . . . . . . . . . . . . . . Load Profile . . . . . . . . . . . . . . . . ES/9000 IPL Using OPRCTL . . . . . ES/9000 IPL Using SYSCTL . . . . . Load Parameters . . . . . . . . . . . . . OS/390 MVS Data Set Connections IPL Flow (1 of 2) . . . . . . . . . . . . . Operating System Messages . . . . Sysplex Initialization . . . . . . . . . . IPL Flow (2 of 2) . . . . . . . . . . . . . Checkpoint . . . . . . . . . . . . . . . . . . . . . . Unit Summary . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unit 4. MVS/ESA or OS/390 Consoles Operation Objectives . . . . . . . . . . . . . . . . . . . . . . . OS/390 Overview . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1 MVS/ESA or OS/390 Console Operation and Recovery Console Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Console Display Commands D C,*Command . . . . . . . . . . . . . . . . . . . . . . . . . . D C,A or D C . . . . . . . . . . . . . . . . . . . . . . . . . . . . D C,M Command . . . . . . . . . . . . . . . . . . . . . . . . . D C,A,CA and D C,N,CA Command . . . . . . . . . . . CONSOLxx Member of SYS1.PARMLIB . . . . . . . . . Console Groups (CNGRP) . . . . . . . . . . . . . . . . . . Console Switching . . . . . . . . . . . . . . . . . . . . . . . . Console Failure Example . . . . . . . . . . . . . . . . . . . Console Switching Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Console Named SYSAMSTR Fails IEE141A Condition . . . . . . . . . . . . . . . . . . . . . . . .
vi OS/390 System Operations
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Instructor Guide
No Active MCS Consoles Exist Checkpoint . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . Unit 5. OS/390 MVS Commands Objectives . . . . . . . . . . . OS/390 Overview . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-38 4-41 4-42 5-1 5-2 5-4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1 OS/390 MVS Commands Syntax, Messages, and Meanings . . . . . . . . . . . . . 5-7 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8 Optional Code Meanings (general usage) . . . . . . . . . . . . . . . . . . . . . . . 5-10 Messages Requiring a Response (WTOR) . . . . . . . . . . . . . . . . . . . . . . . 5-14 Determining Outstanding WTORs (D R,R) . . . . . . . . . . . . . . . . . . . . . . . 5-16 System Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18 MVS/ESA Operator Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20 D A,L Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22 MVSESA and OS/390 Address Spaces . . . . . . . . . . . . . . . . . . . . . . . . . 5-26 D A,A Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-28 Display Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-34 D U Command D U Command Continued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-36 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-38 D M=DEV Command D M = D E V ( d d d d ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-40 Paths Not Validated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-42 D M=CHP(cc) Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-44 D M=CHP Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-46 D M=CPU Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-48 CONFIGxx Member of SYS1.PARMLIB . . . . . . . . . . . . . . . . . . . . . . . . . 5-50 D M=CONFIG Command Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-52 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-56 DS Paths Command DevServ Paths to DASD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-58 Vary Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-64 Vary Offline Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-68 Vary Online Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-70 Configure Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-72 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-74 Configure Command Examples Taking a Device Offline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-76 Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-79 Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-82 Unit 6. OS/390 Communication Server Objectives . . . . . . . . . . . . . . . . OS/390 Overview . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-1 6-4 6-6 6-9 6-10 6-12 6-14 6-18 6-22 6-26 6-28
vii
6.1 OS/390 Communication Server . . . . . . . . . OS/390 Communication Server . . . . . . . . VTAM and TIOC . . . . . . . . . . . . . . . . . . . . . . . . . Networking Architectures: SNA VTAM and SNA . . . . . . . . . . . . . . . . . . . Why a Communication Controller? . . . . . SNA: APPC . . . . . . . . . . . . . . . . . . . . . . SNA - Advanced Peer-to-Peer Networking
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
Instructor Guide
SNA : APPN/HPR . . . . . . . . . . . . . . Networking Architectures: TCP/IP . . . TCP/IP: Architectural Layers . . . . . . TCP/IP: Internet Address . . . . . . . . . TCP/IP: Ports and Sockets . . . . . . . . TCP/IP: Internet Protocol . . . . . . . . . TCP/IP: Transmission Control Protocol . . . . . TCP/IP: Application Protocols Networking Architectures: MPTN . . . Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . Unit Summary . . . . . . . . . . . . . . . . . Unit 7. Netview . . . . . Objectives . . . . . OS/390 Overview
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-32 6-36 6-40 6-44 6-48 6-52 6-54 6-56 6-58 6-61 6-64 7-1 7-2 7-4 7-7 7-8 7-10 7-12 7-16 7-16 7-16 7-16 7-18 7-22 7-22 7-22 7-23 7-26 7-26 7-26 7-27 7-30 7-30 7-30 7-31 7-34 7-34 7-34 7-35 7-38 7-38 7-38 7-39 7-42 7-42 7-42 7-43 7-46 7-46 7-46
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1 Netview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bringing the Pieces of NetView Together . . . . . NetView and the Tivoli Management Environment Three Packaging Options . . . . . . . . . . . . . . . . . More on NetView . . . . . . . . . . . . . . . . . . . . . . . NetView Components . . . . . . . . . . . . . . . . . . . . . . . . Operating System Interfaces . . . . . . . . . . . . . . . . . . . VTAM Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command Facility . . . . . . . . . . . . . . . . . . . . . . (Command Facility) . . . . . . . . . . . . . . . . . . . . . Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Status Monitor Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (Hardware Monitor) . . . . . . . . . . . . . . . . . . . . . Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (Session Monitor) . . . . . . . . . . . . . . . . . . . . . . Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NetView Logging Capabilities . . . . . . . . . . . . . . Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NetView Automation Facilities . . . . . . . . . . . . . Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NetView Automation Table . . . . . . . . . . . . . . . . Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
viii OS/390 System Operations
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Instructor Guide
Value
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NetView Customization Facilities Requirement . . . . . . . . . . . . . . . . . . . Functions . . . . . . . . . . . . . . . . . . . . . Value . . . . . . . . . . . . . . . . . . . . . . . . Centralized Operations . . . . . . Requirements . . . . . . . . . . . . . . . . . . Function . . . . . . . . . . . . . . . . . . . . . . Value . . . . . . . . . . . . . . . . . . . . . . . . Checkpoint . . . . . . . . . . . . . . . . . . . . Unit Summary . . . . . . . . . . . . . Unit 8. Introduction to UNIX Objectives . . . . . . . . OS/390 Overview . . .
7-47 7-50 7-50 7-50 7-51 7-54 7-54 7-54 7-54 7-57 7-58 8-1 8-2 8-4 8-7 8-8 8-10 8-12 8-14 8-16 8-18 8-20 8-22 8-24 8-26 8-29 8-30 8-32 8-34 8-36 8-38 8-40 8-44 8-46 8-50 8-52 8-54 8-56 8-58 8-60 8-62 8-64 8-66 8-70 8-72 8-74 8-76 8-78 8-80
ix
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1 UNIX Introduction . . . . . . . . . . . . UNIX Introduction . . . . . . . . . . UNIX History/Background . . . . Evolution of UNIX . . . . . . . . . . UNIX Today . . . . . . . . . . . . . . . UNIX and the C Language . . . . UNIX Philosophy . . . . . . . . . . . UNIX System Components . . . . Unix Operating System (kernel) UNIX Command Interface (Shell) Commands and Utilities . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . 8.2 OpenEdition Overview Course Contents . . . . . . . . . . . . . . . . Open Systems . . . . . . . . . . . . . . . . . . OpenEdition . . . . . . . . . . . . . . . . . . . Open Infrastructure Requirements . . . Open Systems Concept . . . . . . . . . . . Standards Organizations . . . . . . . . . . Posix Standards . . . . . . . . . . . . . . . . X/Open Portability Guide (XPG) . . . . . UNIX Application Interfaces in OS/390 DCE Architecture . . . . . . . . . . . . . . . . Port Applications to MVS/ESA . . . . . . Access to Applications and Data . . . . High-Speed Storage Device Access . . Data Administration . . . . . . . . . . . . . . . . . . . . Server for Batch Applications OS/390 Internet Gateway . . . . . . . . . . Distributed Computing Environment . . . . . . . . . . . OpenEdition Components XPG4/XPG4.2 Functions in OpenEdition Hierarchical File System . . . . . . . . . . Shell and Utilities . . . . . . . . . . . . . . . Application Services . . . . . . . . . . . . . Unit Summary . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Contents
Instructor Guide
Appendix A. Enterprise Systems Connection (ESCON) Overview (Optional topic) ESCON, Directors and EMIF Overview Appendix B. Checkpoint Solutions Bibliography
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A-1 A-3 B-1 X-1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Instructor Guide
Instructor Course Overview

The intention of this class is to teach students all the essential skills necessary to work in an OS/390 environment. The main focus of the course is OS/390 commands and to be familiar with which hardware and software make up an OS/390 system. Students will be able to do actual OS/390 commands in lab exercises.
Instructor Course Overview
xi
Instructor Guide
xii
Instructor Guide
Course Description
OS/390 System Operations Duration : 2.5 days Purpose

This course is designed to teach students system operations in OS/390. This includes use of MVS JES2, PR/SM, Unix, APPC, VTAM and NetView. This also includes the use of commands from MVS, TSO and NetView consoles.
Audience
The intended audience for this class is IT personnel with little or no theoretical background of OS/390 and little or no general practical IS experience.
Prerequisites
ES05 - An Introduction to OS/390 or equivalent on-the-job training.
Objectives

To be familiar with basic facts and concepts of OS/390. To be familiar with what JES is and use basic commands. To be familiar with what TSO is and use basic commands. To be familiar with OS/390 IPL process. To be familiar with OS/390 Consoles. To be familiar with and use Basic OS/390 commands. To be familiar with what VTAM/SNA is and how it relates to OS/390. To be familiar with what TCP/IP is and how it relates to OS/390. To be familiar with what NETVIEW is and use basic commands. To be familiar with what UNIX is and how it relates to OS/390.

Course Description
xiii
Instructor Guide
Contents
This class consists of a mixture of theoretical and practical sections. The major objective of the course is to familiarize the students with the everyday-activities involved in working in an OS/390 environment. The main focus is therefore on the classes lab exercises.
Curriculum Relationship
ES05
xiv
Instructor Guide
Agenda
Day 1
(00:15) Welcome (03:30) Overview OS/390 (03:15) Overview JES, TSO, (00:00) Consoles (00:00) LAB
Day 2
(01:15) IPL (01:00) MVS Commands (04:00) LAB
Day 3
(00:30) OS/390 Communication Server Overview (01:30) VTAM and SNA (01:30) TCP/IP (00:30) UNIX (00:00) NetView

Agenda
xv
Instructor Guide
xvi
Instructor Guide
Unit 1. Review of S/390 and OS/390
What This Unit Is About

The following unit reviews the basic facts and concepts of the System/390 architecture and the OS/390 operating system.
What You Should Be Able to Do

After completing this unit, you should be able to:

Describe the System/390 architecture Name the characteristics of the System/390 processors Give an overview of OS/390, its components and delivery process Explain the concept of virtual storage and its exploitation in OS/390
How You Will Check Your Progress

Accountability:
Checkpoint questions
References
GC26-4900 GC28-1725 GC28-1727 GC28-1860 GC35-0033 SA22-7201 SC26-4914 SC26-4916
DFSMS/MVS Version 1 Release 3: General Information An Introduction to OS/390 Information Roadmap Parallel Sysplex Overview: Introducing Data Sharing and Parallelism in a Sysplex Device Support Facilities: User s Guide and Reference ESA/390: Principles of Operation DFSMS/MVS V1R3 Managing Catalogs DFSMS/MVS V1R3 Program Management
1-1
Instructor Guide
Figure
1-1. Objectives (ES271100)
Notes:
1-2
Instructor Guide
Instructor Notes:
Purpose To list the objectives of unit 1. Transition Statement Unit 1 - topic 1 System/390 Overview.
1-3
Instructor Guide
1-4
Instructor Guide
1.1 System/390 Overview

Instructor Topic Introduction
What students will learn This topic gives students a very brief overview of the System/390 architecture, the processor types, their modes of operation, as well as their connectivity with other systems. How this will help students on their job This overview will help students to understand the overall picture behind the System/390 architecture.
1-5
Instructor Guide
Figure
1-2. System/390 Overview (ES271101)
Notes:
The System/390 architecture is the follow-up to the System/360 and System/370 architectures. The System/390 architecture was announced in 1990. The System/390 architecture is a blueprint that provides a set of definitions and rules required for the interaction of System/390 hardware and System/390 software. The System/390 architecture determines processor instruction sets, addressing range and modes, communication mechanisms such as interrupts, and so on. It lays the groundwork for every System/390 processor and every operating system running on it. The System/390 architectures onsets originate in a demand for a system architecture that supports large numbers of users along with large amounts of data while still providing a reasonable performance. Over the years, the System/390 platform has met these objectives without sacrificing reliability, availability, or serviceability. The design of the System/390 architecture incorporates an evolutionary approach, meaning, even though it grows in functionality it still provides a high degree of compatibility with its ancestors, System/370 and System/360.
1-6
Instructor Guide
Instructor Notes:
Purpose To explain briefly explain the System/390 architecture and its components. Transition Statement A short introduction to the System/390 processor types.
1-7
Instructor Guide
Figure
1-3. Processor Types (ES271103)
Notes:
An IBM System/390 consists of hardware and software products. The hardware consists of the central processor, the storage, channels, etc. Together they make up a central processor complex (CPC). The software running on the S/390 comprises system application programs, end-user applications, tools, utilities and so on. The primary program executing on the system is an operating system such as MVS. The System/390 architecture defines that a single central processor processes one and only one program instruction at a time. The operating system manages the instructions to be processed and the resources required to process them. A single processor system is also called a uniprocessor. By adding more processors to a CPC (referred to as an n-way processor), you provide a processor backup and enable a system to process multiple program instructions simultaneously. Some of these n-way processors provide the physical capability to be divided into two separate systems. An n-way processor system that possesses this feature is a multiprocessor.
1-8
Instructor Guide
Instructor Notes:
Purpose To introduce the terms uniprocessor, n-way processor, and multiprocessor. Details Please be aware that there are multiple definitions of the term multiprocessor. The definition used in this class is based on the definition used by the ITSO (International Technical Support Organization). Only an n-way processor that supports physical partitioning is a multiprocessor. Transition Statement An IBM System/390 multiprocessor can be run in two modes Single-Image Mode and Physically-Partitioned Mode.
1-9
Instructor Guide
Figure
1-4. Modes of Operation (ES271105)
Notes:
Single-Image Mode Single-Image mode is the default operation mode of an IBM System/390 n-way processor system. All resources such as processors, processor storage, channel subsystem, as well as all peripherals, are controlled by a single operating system image. Single-image mode uses only one side of the processor controller. The inactive side of the processor controller acts as a backup for the active side. Physically Partitioned Mode In physically-partitioned mode, a System/390 is literally split into two subsystems, which act independently. Those two systems can also run different operating systems. In physically-partitioned mode, each side of the processor controller is assigned to one of the systems.
1-10
Instructor Guide
Instructor Notes:
Purpose To outline the modes of operation of a System/390. Transition Statement Apart from physical partitioning, a System/390 can be logically partitioned using PR/SM or VM.
1-11
Instructor Guide
Figure
1-5. Logical Partitioning / Partitioning with VM (ES271107)
Notes:
Two other ways of partitioning a single S/390 system, apart from physical partitioning, are logical partitioning and partitioning through the use of VM. Logical Partitioning Logical partitioning describes the logical subdivision of a System/390s resources into two or more parts, called logical partitions. These logical partitions run different operating system images. To logically partition a System/390 it has to be equipped with the (PR/SM) Processor Resources/Systems Management feature. PR/SM allows multiple logical partitions (LPARs) of:

processors storage (central/expanded) channel paths
Processors can be shared among logical partitions or dedicated to a specific LPAR.
1-12
Instructor Guide
Partitioning with VM Using (VM) Virtual Machine to partition a system, is the most flexible way of running multiple images on the same physical machine. VM acts as a resource manager to build multiple virtual machines which each run their own operating system image. Note: All three forms of partitioning, physical partitioning, logical partitioning, and partitioning through VM can be combined, therefore achieving great flexibility.
1-13
Instructor Guide
Instructor Notes:
Purpose To describe ways to logically partition a System/390. Transition Statement An overview of all three ways of partitioning.
1-14
Instructor Guide
1-15
Instructor Guide
Figure
1-6. Overview of Partitioning (ES271109)
Notes:
Let us now summarize the different forms of partitioning:
Physical partitioning enables you to split an n-way processor into two physically separate sides, which act completely independently of each other. Logical partitioning uses PR/SM to split up a System/390s resources into two or more logical partitions. PR/SM allows for 10 logical partitions (10 per side for physically-partitioned models). Some CMOS processors can have 15. When partitioning with VM the number of partitions is indefinite, only restricted by the storage available. With the exception of physical partitioning, where a processor is physically assigned to a partition, processors can be dedicated or shared. The same applies for processor storage which only in the case of physical partitioning has to be dedicated to a single partition. Processor storage cannot be shared among LPARs, but can be assigned dynamically. Channels in physical partitioning are dedicated to a single partition. When using logical partitioning, channels may be shared. When using VM to partition a System/390, ESCON channels can be configured dynamically or can be shared, while parallel channels can not be shared.
1-16
Instructor Guide
Instructor Notes:
Purpose To summarize and compare all forms of partitioning. Transition Statement The following page reviews the various ways to achieve workload distribution among multiple System/390s.
1-17
Instructor Guide
Figure
1-7. Coupling Systems (ES271111)
Notes:
We already discussed the backup capabilities of systems with multiple processors in case of CP failure. But what about backup capabilities across systems? Loosely Coupled Systems Systems can coordinate more than one MVS image with the MVS job entry subsystem (JES2/JES3) and global resource serialization (GRS). The job entry subsystem allows work to be distributed among different systems. Global resource serialization enables multiple systems to share resources. Systems that establish a way of sharing work and resources are called loosely-coupled systems. A loosely coupled configuration has more than one CPC sharing DASD, but not storage. The systems can be connected via channel-to-channel communications. They run multiple MVS images. A loosely-coupled configuration increases system capacity and availability but requires extensive management, as each system has to be managed by itself. Sysplex A sysplex ( sys -tems com -plex) consists of two or more MVS systems residing on one or more processors. It is the basis for a simplified multisystem management. Management across systems
1-18
Instructor Guide
is achieved through the cross-system coupling facility (XCF) of MVS. XCF services allow authorized applications on one system to communicate with applications on the same or another system. In a base sysplex, CPCs connect by channel-to-channel communications and a shared dataset to support the communication. When more than one CPC is involved in a sysplex, a Sysplex Timer synchronizes the time on all systems. In a sysplex, an installation can view multiple MVS systems as a single entity. For example, console services allow the IS installation to operate all MVS systems within a sysplex from one console. A sysplex is different from a loosely-coupled configuration in that a standard communication mechanism for MVS systems exists - XCF. In a loosely-coupled configuration products and applications have to provide their own communication mechanism. Parallel Sysplex The enhanced or parallel sysplex provides support for a greater number of systems than a sysplex and improves communication and data sharing among those systems. A parallel sysplex provides the means for high-speed data sharing through a device called the coupling facility, and allows multiple systems to provide a single system image to the end user. Workload in a sysplex or parallel sysplex can be dynamically balanced across systems, thus allowing work to be equally distributed across all systems. In comparison with the base sysplex systems, management has been improved considerably.
1-19
Instructor Guide
Instructor Notes:
Purpose To give an overview of possible workload distribution among S/390s using loosely-coupled systems, sysplex, or parallel sysplex. Transition Statement An overview of some of the currently available System/390 processors.
1-20
Instructor Guide
1-21
Instructor Guide
Figure
1-8. Enterprise Systems Architecture: Hardware (ES271113)
Notes:
1-22
Instructor Guide
Instructor Notes:
1-23
Instructor Guide
Figure
1-9. System/390 Overview (ES271115)
Notes:
The chart above gives you an overview of the currently available System/390 hardware. Note: This foil is not comprehensive and shows only selected models.
Listed along with each S/390 model group is the indication whether it is a uniprocessor, a non-partitionable n-way processor or a multiprocessor. Here are some examples of how to read the table:
A Multiprise 2000 model 105 is a uniprocessor model as indicated by a 1 in the n-way column. A 9672 Parallel Enterprise Server model R42 is a 4-way processor model that does not support physical partitioning. An ES/9000 9121-742 is also a 4-way processor model, but can be physically partitioned into two systems with two central processors each.
All ES/9000 9021 and 9121 models as well as all the 9672 models listed here, support the implementation of a parallel sysplex.
1-24 OS/390 System Operations Copyright IBM Corp. 1997, 1998
Instructor Guide
Instructor Notes:
Purpose To provide an overview of currently available System/390 processors.
1-25
Instructor Guide
Figure
1-10. What Is OS/390 (ES271117)
Notes:
Prior to OS/390, the System/390 world consisted of tens of different products that had to be ordered, installed and maintained separately. The products were updated in different release cycles. Many products were often available in different releases and different package sizes (base functions, full-function package, etc). For the average IS installation this meant, before a product could be ordered or installed, its prerequisites had to be checked, and if necessary, other products to be installed or updated first. Whenever a product was installed, extensive testing had to take place to ensure it worked properly and did not interfere, in any other than the intended way, with other products. All this made keeping an MVS system up to date and running a difficult, if not challenging task. With OS/390 a lot of things changed. IBM now gives customers the opportunity to order products en bloc, that is, there is no more need for separate orders. Customers order OS/390 and receive a tailored package of all the base and optional products they need for their IS installation. IBM makes sure that all products shipped with the order are at the proper release level and that all prerequisites are met.
1-26
Instructor Guide
The OS/390 package comes in a pre-tested and easy-to-install form, which reduces installation and testing time considerably. Once OS/390 is in place, IBM provides several different ways to always keep your OS/390 installation up to date, even between new OS/390 releases.
1-27
Instructor Guide
Instructor Notes:
Purpose To give the students an idea of how the MVS-world looked before the arrival of OS/390, and how things changed with OS/390. Transition Statement What are an IS installations requirements and how are they met by OS/390?
1-28
Instructor Guide
1-29
Instructor Guide
Figure
1-11. IS Installation Requirements (ES271119)
Notes:
The visual lists some of the common requirements of any IS installation. One of them is high system availability and reliability. As OS/390 is based on the MVS operating system it also inherits its strengths. MVS already provided products for automated backup and recovery, as well as dynamic reconfiguration capabilities which made it a very stable platform. As MVS is part of OS/390, OS/390 provides the same robustness that MVS customers enjoyed for over 25 years with MVS. OS/390 is designed as a scalable system, which means it can be tailored to an IS installations needs, and supports a great number of users. OS/390 can further be understood as an open system, which makes it very flexible. It enables customers, for example. to run UNIX applications on MVS, to use MVS as a network server, etc. OS/390 meets various industry standards that allow applications to be ported to it, and assures a high degree of interoperability with other IBM or non-IBM platforms. As part of OS/390, IBM supplies diverse communication facilities, thus making an OS/390 system an ideal platform within a network of distributed computers.
1-30
Instructor Guide
Apart from its reliability, OS/390 also offers a high degree of system security. OS/390 provides the means to protect a customers resources within a single MVS system or a network of distributed systems.
1-31
Instructor Guide
Instructor Notes:
Purpose To list common IS requirements and indicate their coverage through OS/390. Transition Statement A look at the delivery of OS/390 - OS/390 Elements and Features.
1-32
Instructor Guide
1.2 OS/390 Overview

What students will learn The following topic reviews the basic concepts behind OS/390 and its components as taught in the preceding class, since their knowledge is required or helpful for the understanding of the following units. How this will help students on their job This topic is intended to refresh the students understanding of OS/390, its elements and features, as well as the basic concepts behind OS/390. This knowledge is essential before moving on to the succeeding units.
1-33
Instructor Guide
Figure
1-12. OS/390 Overview (ES271121)
Notes:
Prior to OS/390, the System/390 world consisted of tens of different products that had to be ordered, installed and maintained separately. Now, with OS/390 customers order products en bloc, that is, there is less need for separate orders. Customers order OS/390 and receive a tailored package of all the base and optional products they need for their IS installation. IBM ensures that all products shipped with the order are at the proper release level and that all prerequisites are met. OS/390 products are organized in functional groups such as: System Services A set of basic functions and services for storage, workload, and data management that is provided through the operating system MVS as well as other related products. Security Server The OS/390 Security Server provides all the necessary functions to ensure a high degree of security within a local or distributed environment.
1-34
Instructor Guide
System Management Services With its System Management Services, OS/390 delivers products that assist you in installing, configuring and maintaining software, as well as in managing a system. Application Enablement Services OS/390 delivers a language-independent service platform for traditional and object-oriented application programs, and enables 3270 terminal applications to exploit workstation graphics and dialogs. UNIX Services OS/390 meets open system standards like POSIX and XPG4, thus turning an OS/390 system into a platform for UNIX applications.
Distributed Computing Services Support for distributed applications based on common industry solutions such as Distributed Computing Environment, Distributed File System and Network File System. Communications Server OS/390 supports common programming interfaces such as APPC, SOCKETS, RPC, SNA(3270) and WAN protocols including SNA, TCP/IP, and ATM. LAN Services Enables the System/390 to actively participate in a Local Area Network (LAN) as data or print server, thus making S/390 resources accessible to LAN users and LAN resources to OS/390 users.
Network Computing Services Provides secure Internet access and enables System/390 to act as an Internet server. Allows Internet access to IMS , DB2 , and CICS transactions. Softcopy Services OS/390 provides the necessary services which allow you to manage, display, and search books online.
1-35
Instructor Guide
Instructor Notes:
Purpose To review OS/390 and its functional groups. Transition Statement OS/390 elements and features.
1-36
Instructor Guide
1-37
Instructor Guide
Figure
1-13. OS/390 Elements and Features (ES271123)
Notes:
IBM ships the OS/390 products in the form of OS/390 elements and features. The base elements of OS/390 deliver all essential system components, such as the basic operating system, communication functions, system management support, application development services, and so on. These base elements are part of every OS/390 order. The OS/390 features provide additional functionality over the OS/390 base elements. OS/390 features come in two different forms, those that support dynamic enablement and those that do not. The features that allow for dynamic enablement are shipped along with every OS/390 order. Unless they are ordered explicitly by the customer they are delivered in a disabled state and can not be used. If required, these features can be activated at a later stage (a process called dynamic enablement). The second kind of feature that does not allow dynamic enablement is not shipped with any OS/390 order unless the customer specifically ordered it.
1-38
Instructor Guide
IBM identified two forms of delivery for OS/390. These are ServerPac for OS/390 and the custom built product delivery offering (CBPDO ).
1-39
Instructor Guide
Instructor Notes:
Purpose To explain the difference between OS/390 elements and features. Details The chart shows that base elements are shipped with every OS/390 order while features have to be specifically ordered by a customer. Transition Statement Starting with the following page, we briefly revisit the main concepts and components behind OS/390, since this knowledge is essential for the remainder of the class.
1-40
Instructor Guide
1-41
Instructor Guide
Figure
1-14. OS/390 Delivery (ES271125)
Notes:
1-42
Instructor Guide
Instructor Notes:
1-43
Instructor Guide
Figure
1-15. Large Systems Storage Hierarchy (ES271126)
Notes:
The large systems storage hierarchy is designed to meet the large variety of data processing requirements.
1-44
Instructor Guide
Instructor Notes:
Purpose Details Additional Information Transition Statement
1-45
Instructor Guide
Figure
1-16. The Concept of Virtual Storage (ES271127)
Notes:
OS/390 allows users to access a greater range of storage than is actually physically available in the form of central storage. This storage range is called virtual storage. In the case of OS/390, each user has access to a maximum of 2GB of virtual storage. What makes virtual storage work, is that the operating system keeps only active portions of the virtual storage in central storage. Inactive portions are moved to expanded or auxiliary storage. Virtual storage consists of 4KB blocks called pages. A page may be stored in real storage or on auxiliary storage. A 4KB block in real storage is referred to as a frame, on auxiliary storage as a slot. A storage location within the virtual storage is identified through a virtual address. It consists of a segment number, a page number and a byte displacement.
1-46
Instructor Guide
Dynamic address translation (DAT) is the hardware process of translating a virtual storage address during a storage reference into the corresponding central storage address (called real address ).
1-47
Instructor Guide
Instructor Notes:
Purpose To review the basic concept behind virtual storage and its realization in OS/390. Details OS/390 organizes the 2GB assigned to each user in 2048 segments of 1MB each. Each segment is broken into 256 pages. Within a page a specific location is addressed by its byte displacement, that is, the number of bytes between page start and the specific location. Each user assigned virtual storage has a segment table and up to 2048 page tables. A page table has entries for the 256 pages within that segment. The page entry indicates whether a page is currently in central storage or not. At a page request the page is loaded into central storage. Transition Statement Address space, data space, and hyperspace.
1-48
Instructor Guide
1-49
Instructor Guide
Figure
1-17. Address Space, Data Space and Hyperspace (ES271129)
Notes:
The sequence of virtual addresses associated with virtual storage is called an address space. An address space contains 2GB of virtual storage. OS/390 offers this virtual addressing capability to every user in the system by assigning each user its own, separate address space. Programs in separated address spaces are protected from each other. Isolating data in its own address space also protects the data. The concept of having multiple virtual storages is the basic concept of the OS/390 operating system core Multiple Virtual Storage (MVS). System address spaces are created when MVS is started. Other address spaces are generated when a user logs on to the system or an initiator is started. Data spaces and hyperspaces are similar in that both are areas of virtual storage that can be created by the system upon user request. The size of data spaces and hyperspaces can range from 4KB to 2GB, depending on the users request. Unlike an address space, a data space or hyperspace contains only user data or user programs stored as data. Program code cannot directly be executed in a data space or a hyperspace.
1-50
Instructor Guide
A program references data in a data space directly, in much the same way it references data in an address space. The program uses the same instructions that it would use to access data in its own address space. Data stored in a hyperspace is not directly accessible. It has to be transferred to an address space or data space, before it can be accessed. This is done through system services.
1-51
Instructor Guide
Instructor Notes:
Purpose To explain the concepts of Address space, data space, and hyperspace. Details Data spaces and hyperspaces can be used to:

Obtain more virtual storage than a single address space provides Isolate data from other tasks in the address space. Share data among programs or users.
You can place all types of data such as tables, arrays, buffers, etc. in a data space or hyperspace, rather than in an address space or on DASD. Transition Statement Since the concept of virtual storage is based on keeping only active portions of the virtual storage in central storage, processes have been implemented to perform the necessary data transfer - paging and swapping.
1-52
Instructor Guide
1-53
Instructor Guide
Figure
1-18. Paging and Swapping (ES271131)
Notes:
Paging The process of moving single pages between central storage and expanded storage or between central storage and the page data sets. Because moving a page between central storage and expanded storage is much faster than performing an I/O, use of expanded storage can provide a significant performance advantage. When a page is to be removed from central storage (page out), the system first considers moving it to expanded storage instead of auxiliary storage. When a referenced page is not in central storage (page fault) the system first looks for it in expanded storage. If the page is in expanded storage, the system synchronously retrieves the page. Otherwise, the system schedules asynchronously the paging I/O to retrieve the page from auxiliary storage. The process of retrieving a referenced page is called page in. Swapping The process for physically or logically removing a user from central storage. Swap out means, all of a users currently active data and programs are written to expanded storage or
1-54
Instructor Guide
swap/page data sets (physical swapping) or marked as swapped (logical swapping). Swap in is the reverse of this process. Data spaces associated with a user address space are swapped when the user address space is swapped. Swapping occurs when a user becomes inactive or the system is overloaded.
1-55
Instructor Guide
Instructor Notes:
1-56
Instructor Guide
1-57
Instructor Guide
Figure
1-19. MVS Data Set Types (ES271135)
Notes:
Sequential data set In a sequential dataset, also referred to as physical sequential (PS), records are arranged sequentially in the order in which they are written. New records are appended at the end of the dataset. In sequential datasets, data is organized for sequential access. To retrieve the fifth record of the dataset, the system first has to read the preceding four. Sequential data sets can be stored on DASD or on tape. They are required for the use of magnetic tape devices or printed output. Partitioned data set A partitioned dataset (PDS) is divided into sequentially organized members, each of which can have one or more records. Each member has a unique name, stored in a directory that is part of the data set. The directory is located at the beginning of the data set and contains an entry for each member. Each directory entry contains the member name and the starting location of the member within the data set. The directory entries are arranged by name in alphanumeric
Instructor Guide
collating sequence. The main advantage of using a partitioned data set is that, without searching the entire data set, you can retrieve any individual member after the data set is opened. Individual members can be added or deleted as required. A deleted member is removed from the directory. Its space cannot be reused until the data set is reorganized using a system utility. Partitioned data set extended In appearance, a Partitioned Data Set Extended (PDSE) is very similar to a partitioned data set. For accessing a partitioned data set directory or member, most PDSE interfaces are indistinguishable from PDS data set interfaces. However, PDSEs have a different internal format, which gives them increased usability. The main advantage of using a PDSE over a PDS is, that PDSEs use DASD space much more efficiently. The size of a PDS directory is fixed regardless of the number of members in it, while the size of a PDSE directory is flexible and expands to fit the members stored in it. Also, the system reclaims space automatically whenever a member is deleted or replaced, and returns it to the pool of space available for allocation to other members of the same PDSE. The space can be reused without having to reorganize the data set.
1-59
Instructor Guide
Instructor Notes:
Purpose To introduce and compare the three types of MVS data sets. Details You may also want to mention the terms primary space and secondary space, as their knowledge is required in unit 3, when students allocate new data sets. When you allocate non-system-managed data sets or system-managed data sets without the guaranteed space attribute, MVS first allocates the amount of primary space defined for a data set. Once this primary space is used, it automatically allocates additional space, as defined by the secondary space specification.

A physical sequential data set can have 16 extents on each volume. An extended sequential data set can have 123 extents per volume. A partitioned data set can have 16 extents. A direct data set can have 16 extents on each volume. A PDSE can have 123 extents.
Transition Statement Lets do checkpoint exercises.
1-60
Instructor Guide
Checkpoint
Exercise Unit 1 Review of S/390 and OS/390

TF 1. A CPC can be partitioned using LPAR or VM. Correct Answer 1. True
2.
The following are resources of PR/SM . a. b. c. d. Processors Storage Channels All of the above. Correct Answer 2. d
TF
3.
To run a sysplex with only one PHYSICAL footprint a Sysplex timer is required. Correct Answer
3.
False
TF
4.
OS/390 comes in a pretested format. Correct Answer
4.
True
5.
Which of the following is not part of the OS/390 base element? a. b. c. d. System Services Unix Services Lan Services Security Services
1-61
Instructor Guide
Correct Answer 5. d
1-62
Instructor Guide
1-63
Instructor Guide
Figure
1-20. Unit Summary (ES271199)
Notes:
1-64
Instructor Guide
Instructor Notes:
1-65
Instructor Guide
1-66
Instructor Guide
Unit 2. Overview JES, TSO

This topic briefly introduces the students to the concept of JES2, JES3 and TSO. Discussed are the basic ideas.


Explain the differences between JES2 and JES3 Establish a TSO session and work with panels

Accountability:
References
GC28-1794 GC28-1808 GC28-1869
OS/390 JES2 INTRO OS/390 JES3 INTRO TSO Extensions Ver 2
2-1
Instructor Guide
Figure
Notes:
2-2
Instructor Guide
Instructor Notes:
Purpose To list the objectives of unit 4. Transition Statement Class Overview.
2-3
Instructor Guide
Figure
2-2. OS/390 Overview (ES271201)
Notes:
System Services JES TSO
2-4
Instructor Guide
Instructor Notes:
2-5
Instructor Guide
2-6
Instructor Guide
2.1 Overview of JES2, JES3, and TSO

What students will learn This topic briefly introduces the students to the concept of JES2, JES3 and TSO. Discussed are the basic ideas, and the benefits of NetView in OS/390. How this will help students on their job The knowledge of JES2, JES3 and TSO in an OS/390 system will allow them to tailor systems.
2-7
Instructor Guide
Figure
2-3. Job Entry Subsystem (ES271202)
Notes:
OS/390 uses a Job Entry Subsystem (JES) to receive jobs into the operating system, schedule them for processing, and to control their output processing. IBM provides two JESs: JES2 and JES3. The management of jobs and resources in OS/390 is handled between JES and the base control program (BCP). In this manner, JES manages jobs before and after execution; the base control program manages them during processing. JES2 maintains copies of its data sets that contain job queues (that is, lists of jobs to be processed by MVS) and output queues on direct access storage devices (DASD). Future work is added to these queues and JES2 selects work for processing from them. These data sets and queues are held on spool and checkpoint data sets. In an installation that has only one processor, JES2 and JES3 perform similar functions. That is, they read jobs into the system, convert them to internal machine-readable form, select them for processing, process their output, and purge them from the system.
2-8
Instructor Guide
However, for an installation that has more than one processor in a configuration, JES2 and JES3 work differently. Within JES2, each processor controls its own job input, job scheduling, and job output processing. In contrast, JES3 exercises centralized control over its processing functions through a single global JES3 processor. This global processor provides all job selection, scheduling, and device allocation functions for all the other JES3 systems. The centralized control that JES3 exercises provides: increased job scheduling control, deadline scheduling capabilities, and increased control by providing its own device allocation.
2-9
Instructor Guide
Instructor Notes:
Purpose To introduce JES2 and JES3 and compare their job management. Transition Statement A closer look at the job processing phases in JES2.
2-10
Instructor Guide
2-11
Instructor Guide
Figure
2-4. JES3 - Job Processing Phases (ES271203)
Notes:
Job management in JES3 can be divided into six stages. They are: Input Phase After JES3 reads the job-input which can be local or remote, a unique job number is assigned to each job. Then the job and its (SYSIN) data are written to a SPOOL volume. This phase determines whether the JCL contains procedure calls. If this is the case, the procedure code is added to the jobs JCL. The result is called internal text. During this phase a syntax check takes place. In case of an error the job branches directly to the output phase. Based on the internal text, the conversion phase also creates control blocks which are used for the resource allocation during the next phase. Resource Allocation Unlike JES 2, where the resource allocation takes place during job execution, JES 3 requires the allocation of all resources requested by a job prior to its execution. This prevents a job from being requeued in the JES queue due to the unavailability of a resource.
Conversion Phase
Instructor Guide
Execution Phase Whenever an initiator requests work, JES3 selects a job from the job queue for execution. In a multiprocessor JES3 environment this is handled by the global processor. During the execution phase, the programs of a job are processed. Output Phase After the completion of job processing, JES analyzes the output characteristics for the job. According to the specifications the job is now queued in an output queue. Now that the job has been fully processed JES frees all allocated SPOOL areas and signals the job completion to the operator.
Purge Phase
2-13
Instructor Guide
Instructor Notes:
Purpose To discuss in more detail the job management in JES3. Transition Statement MVS data set types.
2-14
Instructor Guide
2-15
Instructor Guide
JES2 Requirements
JES2 Member
Found in SYS1.PROCLIB Identifies the member that has JES2 Parameters Where to look for JES2 Parameters
JES2 Parameters
Usually in SYS1.PARMLIB Provides JES initialization requirements
Figure
2-5. JES2 Requirements (ES271205T)
Notes:
Refer to MVS Systems Programming , section 8.1.3.
2-16
Instructor Guide
Instructor Notes:
2-17
Instructor Guide
Types of JES2 Starts

Cold Start
A system restart that ignores previous data areas and accounting information on main storage and purges the queues upon starting.
Warm Start
A restart that allows reuse of previously initialized input and output work queues.
Hot Start
Same as a warm start, but without an intervening IPL.
Figure
2-6. Types of JES2 Starts (ES271207T)
Notes:
2-18
Instructor Guide
Instructor Notes:
2-19
Instructor Guide
JES2 Commands
JES2 commands, by default start with $
$C commands
cancel various JES2 functions

$D commands
display various JES2 information

$E commands
Reset various JES2 functions

$P commands
stop (Purge) various JES2 functions

$S commands
start various JES2 functions

Figure 2-7. JES2 Commands (ES271209T)
Notes:
The $ can be replaced by a customer-specified character.
2-20
Instructor Guide
Instructor Notes:
2-21
Instructor Guide
Figure
2-8. TSO Introduction (ES271217)
Notes:
2-22
Instructor Guide
Instructor Notes:
2-23
Instructor Guide
TSO Logon Panel

USERID must be already defined and RACF authorized for
access.
------------------------- TSO/E LOGON ----------------------------------Enter LOGON parameters below: Userid ===> SSRD New Password ===> Group Ident ===> RACF LOGON parameters:
Password ===> Procedure ===> SSRACCNT Acct Nmbr ===> ACCT# Size Perform Command ===> 4096 ===> ===>
Enter an S before each option desired below: -Nomail -Nonotice -Reconnect
-OIDcard
PF1/PF13 ==> Help PF3/PF15 ==> Logoff PA1 ==> Attention PA2 ==> You may request specific help information by entering a ? in any entry
Figure 2-9. TSO Logon Panel (ES271218T)
Notes:
2-24
Instructor Guide
Instructor Notes:
2-25
Instructor Guide
Figure
2-10. ISPF/PDF Introduction (ES271219)
Notes:
2-26
Instructor Guide
Instructor Notes:
2-27
Instructor Guide
Figure
2-11. Establishing a TSO Session (ES271221)
Notes:
Performing a logon to a TSO system means starting a TSO/E session and identifying yourself to TSO/E. To do so you have to provide:

A unique, valid user identification called a userid and A valid password that is associated with the userid.
(In addition you might also have to specify an account number, a procedure name, and possibly a RACF GROUP name.) To actually log on to a TSO system, you have to enter the LOGON TSO command. The logon request is passed on to TCAS (Terminal Control Access Space). If TCAS accepts the logon request, it creates the users address space and initializes its buffers. Once the user address space is set up, TCAS declares the user address space to VTAM, which now handles all further communications.
2-28
Instructor Guide
Instructor Notes:
Purpose A quick look at how a TSO session is established. Transition Statement The following page discusses how users can interact with TSO/E.
2-29
Instructor Guide
ISPF Main Menu
SSR MASTER APPLICATION MENU OPTION ===> p SCROLL ===> PAGE USERID - SSRx TIME - 10:53 A D HC IS O P R S SD SM T X APPC/MVS DITTO HCD ISMF Open/MVS PDF RACF DFSORT SDSF SMP/E TSO/E EXIT - APPC/MVS Administration Dialog - MVS/DITTO - Hardware Configuration Definition - Interactive Storage Management Facility - OpenEdition - ISPF/Program Development Facility - Resource Access Control Facility - Data Facility Sort - System Display and Search Facility - SMP/E and CBIPO Dialogs - TSO/E Information Center Facility - Terminate ISPF using list/log defaults
F1=HELP F7=UP
Figure
F2=SPLIT F8=DOWN
F3=END F9=SWAP
F4=RETURN F10=LEFT
F5=RFIND F11=RIGHT
F6=RCHANGE F12=RETRIEVE
2-12. ISPF Main Menu (ES271223T)
Notes:
2-30
Instructor Guide
Instructor Notes:
2-31
Instructor Guide
PDF Main Menu

Menu Utilities Compilers Options Status Help -----------------------------------------------------------------------------ISPF Primary Option Menu 0 1 2 3 4 5 6 7 8 9 10 Settings View Edit Utilities Foreground Batch Command Dialog Test LM Facility IBM Products SCLM Terminal and user parameters Display source data or listings Create or change source data Perform utility functions Interactive language processing Submit job for language processing Enter TSO or Workstation commands Perform dialog testing Library administrator functions IBM program development products SW Configuration Library Manager User ID . : Time. . . : Terminal. : Screen. . : Language. : Appl ID . : TSO logon : TSO prefix: System ID : MVS acct. : Release . : SSRx 13:26 3278 1 ENGLISH ISR IKJACCNT SSRx SSRx ACCT# ISPF 4.1
Enter X to Terminate using log/list defaults
Option ===> F1=Help F2=Split F10=Actions F12=Cancel

Figure
F3=Exit
F7=Backward F8=Forward
F9=Swap
2-13. PDF Main Menu (ES271225T)
Notes:
2-32
Instructor Guide
Instructor Notes:
Details
UTILITIES OPTION The UTILITIES option is selected from the ISPF/PDF PRIMARY OPTION menu. This option allows you to allocate, rename, delete, catalog, uncatalog or display information of an entire data set. Allocating a data set is when one is created because we allocate or allot space for data on a storage device. Space is first allocated then later something is put into that space.
DSLIST OPTION After creating a number of data sets, the DSLIST OPTION from the UTILITY OPTION allows you to display their names.
EDIT OPTION The EDIT OPTION is selected from the ISPF/PDF PRIMARY OPTION menu. To display a sequential data set to edit, specify the first three qualifiers on the edit entry panel and leave the MEMBER field blank. If the data set contains data, the data will be displayed. If it is an empty data set, a blank edit display panel appears. To display a partitioned data set to edit, specify the first three qualifiers on the edit entry panel and specify a member name in the MEMBER field. Leave the member field blank and press the enter key to see a list of members and information about each member. If no members exist, a message appears stating that the data set has no members. You can create a member by entering a name in the member field.
DATA SET OPTION To delete one or more data sets select the DATA SET OPTION from the UTILITY OPTION menu. The next panel allows you to do several data set management tasks. To delete a data set, type D on the option line. Then specify the three data set qualifiers in the ISPF LIBRARY fields. A confirm delete panel is displayed next to ensure your deletion request. Pressing the ENTER key will delete the data set.
LIBRARY OPTION To delete a single member of a data set, select the LIBRARY OPTION from the UTILITY OPTION. From the next panel select option D (Delete Member). Specify the three data set qualifiers plus the member name in the ISPF LIBRARY fields. When the enter key is pressed, the member is deleted with no chance to retract the deletion.
2-33
Instructor Guide
Figure
2-14. MVS Data Sets (ES271227)
Notes:
For additional overview material on basic data set organization refer to the EZED Student Workbook For Basic JCL sections 6, 7, and 8.
2-34
Instructor Guide
Instructor Notes:
2-35
Instructor Guide
Figure
2-15. Data Set Naming Conventions (ES271229)
Notes:
2-36
Instructor Guide
Instructor Notes:
2-37
Instructor Guide
Figure
2-16. Sequential Data Sets (ES271231)
Notes:
2-38
Instructor Guide
Instructor Notes:
2-39
Instructor Guide
Figure
2-17. Partitioned Data Sets (ES271233)
Notes:
2-40
Instructor Guide
Instructor Notes:
2-41
Instructor Guide
Figure
2-18. VSAM Data Sets (ES271235)
Notes:
2-42
Instructor Guide
Instructor Notes:
2-43
Instructor Guide
ISPF Utility Data Set View Panel

This is the ISPF utilities function Data Set panel used to
view data set information.

Menu RefList Utilities Help .---------------------------- Data Set Information ----------------------------. | | | | | Data Set Name . . . .: SYS1.PARMLIB | | | | General Data Current Allocation | | Volume serial . . : IODF03 Allocated cylinders : 10 | | Device type . . . : 3390 Allocated extents . : 1 | | Organization . . . : PO Maximum dir. blocks : 30 | | Record format . . : FB | | Record length . . : 80 | | Block size . . . . : 6160 Current Utilization | | 1st extent cylinder : 10 Used cylinders . . : 2 | | Secondary cylinders : 0 Used extents . . . : 1 | | Used dir. blocks . : 23 | | Creation date . . : 1995/06/16 Number of members . : 161 | | Expiration date . : ***None*** | | | | | | Command ===> | | F1=Help F2=Split F3=Exit F7=Backward F8=Forward | | F9=Swap F12=Cancel | ------------------------------------------------------------------------------
Figure
2-19. ISPF Utility Data Set View Panel (ES271245T)
Notes:
To view data set information for a specific data set: 1. You must be in PDF 2. Select Utilities 3. Select DATA SET from the Utilities menu 4. Type the data set name and press Enter (leave the option field blank).
2-44
Instructor Guide
Instructor Notes:
2-45
Instructor Guide
ISPF Utility Data Set Allocate Panel

This is the ISPF utilities function Data Set panel used to
allocate a new data set.

Allocate New Data Set More: Data Set Name . . . : SYS1.EXAMPLE Volume serial . . . Generic unit. . . . Space units . . . . Primary quantity. . Secondary quantity. Directory blocks. . Record format . . . Record length . . . Block size . . . . Expiration date . . . . . . . . . . . . IODF03 CYLINDER 10 0 30 FB 80 6160 (Blank for authorized default volume) (Generic group name or unit address) (BLKS, TRKS, CYLS, KB, MB or BYTES) (In above units) (In above units) (Zero for sequential data set)
Enter / to select option Allocate Multiple Volumes Command ===> F1=Help F9=Swap
Figure
(YY/MM/DD, YYYY/MM/DD YY.DDD, YYYY.DDD in Julian form DDDD for retention period in days or blank) F3=Exit F7=Backward F8=Forward
F2=Split F12=Cancel
2-20. ISPF Utility Data Set Allocate Panel (ES271247T)
Notes:
An easy way to allocate a new data set is to find an existing data set with the attributes you need, view its information, then select the allocate option to create the new one (make sure you put the name of the new data set with single quotes around it prior to selecting the allocate option). All the attributes will be copied over to the allocation panel (they can be changed however). This works great when copying data sets.
2-46
Instructor Guide
Instructor Notes:
2-47
Instructor Guide
JCL Sample
//COPY#1 JOB (2215,10),COPY,CLASS=A,MSGCLASS=A, // MSGLEVEL=(1,1),NOTIFY=JOE,REGION=1M,TYPRUN=SCAN // EXEC PGM=IEBGENER,REGION=512K //SYSPRINT DD SYSOUT=A //SYSUT1 DD DSN=DATA.OLD,DISP=SHR //SYSUT2 DD DSN=DATA.NEW,DISP=(NEW,CATLG,DELETE), // UNIT=SYSDA,VOL=SER=PACK12, // DCB=(RECFM=FB,LRECL=80,BLKSIZE=6400), // SPACE=(6400,(100,20),RLSE) //SYSIN DD DUMMY
Figure 2-21. JCL Sample (ES271249T)
Notes:
2-48
Instructor Guide
Instructor Notes:
2-49
Instructor Guide
Figure
2-22. Procedures (ES271251)
Notes:
2-50
Instructor Guide
Instructor Notes:
2-51
Instructor Guide
2-52
Instructor Guide
Checkpoint
Exercise Unit 2 Overview JES, TSO

TF 1. In an installation that has only one Processor JES2 and JES3 perform similar functions. Correct Answer 1. True
2.
To log on to TSO a USER must provide: a. b. c. d. e. USERID Password Account # A and C A and B Correct Answer 2. e
TF
3.
JES2 cold starts preserves spool data. Correct Answer
3.
False
TF
4.
A PROCs is also known as a procedure library. Correct Answer
4.
True
2-53
Instructor Guide
Summary
Purpose of JES2 and JES2 How to use TSO
Figure
2-23. S u m m a r y (ES271299)
Notes:
2-54
Instructor Guide
Instructor Notes:
2-55
Instructor Guide
2-56
Instructor Guide
Unit 3. MVS/ESA or OS/390 IPL Flow

This unit describes the steps required to perform a successful initial program load (IPL) of an MVS/ESA or OS/390 system.


Understand the functions performed by the Nucleus Initialization Program (NIP) to initialize the system. Respond to NIP messages Perform a successful load of any MVS/ESA or OS/390 system.

Accountability:
References
SC28-1752 GC28-1760 GC28-1781 GC28-1784 GC28-1785 GC28-1786 GC28-1787 GC28-1788
OS/390 MVS Init. and Tuning Reference OS/390 MVS Planning: Operations MVS/ESA System Commands OS/390 MVS System Messages, Vol 1 OS/390 MVS System Messages, Vol 2 OS/390 MVS System Messages, Vol 3 0S/390 MVS System Messages, Vol 4 OS/390 MVS System Messages, Vol 5
3-1
Instructor Guide
Figure
Notes:
3-2
Instructor Guide
Instructor Notes:
Purpose To explain the various steps involved in the IPL process.
3-3
Instructor Guide
Figure
3-2. OS/390 Overview (ES271301)
Notes:
System Services OS390 IPL
3-4
Instructor Guide
Instructor Notes:
3-5
Instructor Guide
3-6
Instructor Guide
3.1 MVS/ESA or OS/390 IPL
3-7
Instructor Guide
Figure
3-3. UCW and UCB Generation (ES271302)
Notes:
Every I/O device is defined to the channel subsystem with a Unit Control Word (UCW).

UCWs (subchannels) are generated by HCD or the stand-alone IOCP program. UCWs are loaded into the HSA during POR.
Every I/O device is defined to MVS/ESA or OS/390 via a Unit Control Block (UCB).
Data for the UCBs is generated by HCD and loaded from the production IODF data set during the IPL process. UCBs are built during IPL.
HCD using dynamic I/O can add, delete, or modify UCBs and UCWs.
3-8
Instructor Guide
Instructor Notes:
Purpose Provide background information on how UCWs and UCBs are created via HCD. Details Describe the big picture of what HCD does.

Creates IODF IODF contains multiple H/W and S/W configurations IOCDs is from IODF IOCDs contains all the information needed to describe the IO to the H/W (channel subsystem) The S/W configuration from an IODF is targeted at IPL time The S/W component of the IODF contains all the information needed to describe the I/O to MVS
Transition Statement Next, lets take a look at how we start an IPL on a CMOS machine.
3-9
Instructor Guide
Figure
3-4. Activate Task (ES271303)
Notes:
S/390 IPL is initiated from the HMC (hardware management console) using the Activate task. Multiple CPC images can be IPLed at the same time.

Open the Groups view Open the Correct Images group Drag and drop the selected objects with the correct profile assigned on the Activate task Activate confirmation panel indicates IPL status
Note: A manual IPL can be performed using the Load task on the CPC Recovery task list.
3-10
Instructor Guide
Instructor Notes:
Purpose To IPL an IMAGE from an HMC. Details Select the appropriate object and drop on activate. Transition Statement This requires a load profile which is shown on next page
3-11
Instructor Guide
Figure
3-5. Load Profile (ES271305)
Notes:
The Load Profile is assigned to an IMAGE object. It contains the IPL address and the load parameters that the system will use.
3-12
Instructor Guide
Instructor Notes:
Purpose To show the contents of a load profile Transition Statement An ES/9000 processor uses the OPRCTL frame to IPL.
3-13
Instructor Guide
Figure
3-6. ES/9000 IPL Using OPRCTL (ES271307)
Notes:
ES/9000 IPL is initiated using the OPRCTL or SYSCTL frame. When running in LPAR mode the SETLP command must be issued first to target the logical partition to be IPLed. Logical partitions are normally locked and the command UNLOCKLP must be issued before the OPRCTL frame can be used to IPL.
OPRCTL Specify the SYSRES device (L1 = Load Address) Specify the IODF volume, LOADxx member, NIP message suppression option and nucleus identifier (L2 = LOADPARMs) Enter O7 for system reset, clear and load or O4 for system reset and load (without clearing storage)
3-14
Instructor Guide
Instructor Notes:
Details ES/9000 IPL is initiated using the OPRCTL or SYSCTL frame.
OPRCTL Specify the SYSRES device (L1 = Load Address) Specify the IODF volume, LOADxx member, NIP message suppression option and nucleus identifier (L2 = LOADPARMs) Enter O7 for system reset, clear and load or O4 for system reset and load (without clearing storage)
Transition Statement The eight-position load parameter is used in all the previous examples and can be broken down as follows.
3-15
Instructor Guide
Figure
3-7. ES/9000 IPL Using SYSCTL (ES271309)
Notes:
The SYSCTL frame is similar to the OPRCTL frame. In addition to providing IPL capabilities, this frame is used to initiate the stand-alone dump, restart and instruction address tracing.
3-16
Instructor Guide
Instructor Notes:
Purpose To decode the load parameter. Details The SYSCTL frame is similar to the OPRCTL frame. In addition to providing IPL capabilities, this frame is used to initiate the stand-alone dump, restart and instruction address tracing. Some of the functions are:

Select the Target CP (Tn) IPL Specify the SYSRES device (A1 = Load Device number) Select the IODF volume, Loadxx member, Initial message suppression indicator and alternate nucleus identifier (A2 = Load Parameters). Initiate the Load Clear function (A3)
Stand-alone Dump Set the stand-alone dump device number (B1 = Load Device number) IPL the stand-alone dump device (B2 = perform load)
Restart the target CP (not present in LPAR mode). Trace 982 instructions on each CP and save on the PCE DASD for stand-alone dump or SVC dump (basic mode only).
3-17
Instructor Guide
Figure
3-8. Load Parameters (ES271313)
Notes:
3-18
Instructor Guide
Instructor Notes:
Details Once the system hardware is ready, you can use the system console to load the system software. Load the system as follows, using the following fields on the system control (SYSCTL) frame (this example uses the IBM 3090 for illustration):

T=TARGET CP: Specifies the target processor for initialization. A=INITIALIZE SYSTEM CONTROL PROGRAM, A1: Specifies the device number that contains the system residence volume (IPL volume). A=INITIALIZE SYSTEM CONTROL PROGRAM, A2: Specifies the LOAD parameter.
Format of the LOAD parameter: 1 4 5 6 7 8 |--------------|------------|------------|--------------| | IODF DASD | LOADxx |PROMPT FEAT.| ALT NUCx | |--------------|------------|------------|--------------| IODF LOADxx prompt nucleus device suffix feature suffix number
The LOAD parameter is eight characters long and contains the following information: 1. The first four characters (characters 1--4 above) specify the hexadecimal device number for the device that contains the I/O definition file (IODF) VSAM data set. This is also the device on which the search for the LOADxx member of SYSn.IPLPARMS or SYS1.PARMLIB begins. The device number can be in the range X0000 to XFFFF. If the number is less than four digits, specify leading zeroes before the device number. If you do not specify the device number, the system uses the device number of the system residence (SYSRES) volume. 2. The next two characters (characters 5--6) specify the suffix of the LOADxx parmlib member that the system is to use. The LOADxx member contains information about the name of the IODF data set, which master catalog to use, and which IEASYSxx members of SYS1.PARMLIB to use. The default for the LOADxx suffix is zeroes. The system reads the LOADxx and NUCLSTxx members from SYSn.IPLPARMS or SYS1.PARMLIB on the volume specified on the LOAD parameter (or the SYSRES volume, if no volume is specified). Once the system opens the master catalog, the system reads all other members from the SYS1.PARMLIB data set that is pointed to by the master catalog. This SYS1.PARMLIB might be different from the SYS1.PARMLIB to which the LOAD parameter points. 3. The next character (character 7) specifies the prompting and message suppression characteristics that the system is to use at IPL. This character is commonly known as an initialization message suppression indicator (IMSI).
3-19
Instructor Guide
Suppressing Informational Messages: Some IMSI characters suppress informational messages from the system console, which can speed up the initialization process and reduce message traffic to the console. It can also cause you to miss some critical messages, so you should always review the hardcopy log after initialization is complete. When the system suppresses informational messages, it still displays the following messages:

Messages with descriptor codes 1, 2, 3, 11, or 12 Write-to-operator with reply (WTOR) messages Command responses Synchronous messages that can indicate problems during initialization.
It does not, however, display the contents of a parmlib member, even if the L option has been specified. Prompting for Operator Responses: You can specify an IMSI character that tells the system to issue a MASTER CATALOG prompt, a SYSTEM PARAMETERS prompt, both, or none:
If the system issues a MASTER CATALOG prompt, the operator response overrides the values that are specified on the SYSCAT parameter in the LOADxx parmlib member. If the system issues a SYSTEM PARAMETERS prompt, the operator response overrides the values that are specified on the SYSPARM parameter in LOADxx. If the system does not prompt the operator, the system uses the values specified in LOADxx. If the SYSCAT and SYSPARM statements are not specified in LOADxx, the system issues one or both prompts to obtain the missing information.
Prompting for the Name of the Master Catalog: If you choose an IMSI character that tells the system not to prompt for the master catalog name, the system uses the name specified on the SYSCAT parameter in the LOADxx parmlib member. The default for the system parameter prompt is to use IEASYS00 in SYS1.PARMLIB, and the default for the master catalog prompt is to use SYSCATLG in SYS1.NUCLEUS. MVS 5.2 The following table shows the possible values for the IMSI character. The default value is period (.).
3-20
Instructor Guide
|-----------|--------------------|--------------------|--------------------| | IMSI | Display | Prompt for Master | Prompt for System | | Character | Informational | Catalog Response | Parameters | | | Messages | | Response | |-----------|--------------------|--------------------|--------------------| | period | No | No | No | | (.) | | | | | | | | | | or blank | | | | |-----------|--------------------|--------------------|--------------------| | A | Yes | Yes | Yes | |-----------|--------------------|--------------------|--------------------| | C (5.2) | No | Yes | No | |-----------|--------------------|--------------------|--------------------| | D (5.2) | Yes | Yes | No | |-----------|--------------------|--------------------|--------------------| | M | Yes | No | No | |-----------|--------------------|--------------------|--------------------| | P | No | Yes | Yes | |-----------|--------------------|--------------------|--------------------| | S (5.2) | No | No | Yes | |-----------|--------------------|--------------------|--------------------| | T (5.2) | Yes | No | Yes | |-----------|--------------------|--------------------|--------------------| Possible Values IMSI Characters
Additional Information 1. The last character (character 8) specifies the alternate nucleus identifier (0-9). Use this character at the system programmers direction. If you do not specify an alternate nucleus identifier, the system loads the standard (or primary) nucleus (IEANUC01), unless the NUCLEUS statement is specified in the LOADxx member. For more information, refer to the MVS/ESA SP V5 Initialization and Tuning Reference. Notes: a. Decide whether to accept the system prompt indicator default. The default causes the system to suppress messages and not prompt the operator. You might miss critical messages during initialization, so you should review the hardcopy log. New installations might want to select prompt feature A (display all messages and prompt the operator) or M (display all messages but do not prompt operator) on the system control frame while validating changes and analyzing system errors during the initialization process. Specifying either A or M might increase message traffic. b. Omit the LOAD parameter when you accept all the IBM-supplied defaults.
3-21
Instructor Guide
c. Each character in the LOAD parameter is positional. If you change any of the defaults you must retype the characters or use periods (....) to hold the positions. d. You cannot leave any leading spaces blank, unless the defaults are accepted for the rest of the LOAD parameter. 2. A=INITIALIZE SYSTEM CONTROL PROGRAM, A3: Specifies the operator load function to IPL the MVS operating system. Selecting the operator load function causes the hardware to read an IPL (initial program loader) program into storage from the system residence volume. For this reason, loading and initializing the system is often called the IPL procedure or just IPL. Likewise, IPLing the system means loading and initializing the system. The IPL program is what actually loads the system software; if the IPL program does not get into storage or does not receive control properly, the entire load process stops and the processor pauses. If the IPL program does not finish properly, it puts the system into a disabled wait state with an error code in the low-order 12 bits of the program status word (PSW). To continue loading the system, display the PSW, note the error code, and follow the instructions for that code given in MVS/ESA SP V5 System Codes. The processor operations manual tells you how to display the PSW. Transition Statement The load parameters are used to find the Loadxx member.
3-22
Instructor Guide
3-23
Instructor Guide
Figure
3-9. OS/390 MVS Data Set Connections (ES271315)
Notes:
The load parameter points to members in data sets that OS/390 uses to IPL. The Loadxx member contains more pointers that in turn point to additional Data sets and members that are required for OS/390 to IPL. OS/390 uses a preset search order to find the Loadxx member.
3-24
Instructor Guide
Instructor Notes:
Details IODF IODF suffix - used to form the name of the IODF data set which contains the device definition data. The IPL process uses this data to build the UCBs in the system queue area (SQA) of main storage. Alternate nucleus suffix - identifies the IEANUC0x member of SYS1.NUCLEUS to be used. Master catalog information (VOLSER and dataset name) Suffix to be appended to IEASYS to select a member of SYS1.PARMLIB for the system parameters. Specifies the name of a sysplex in which the system participates. Because the system processes LOADxx early during initialization, you can use the defined substitution text for the &SYSPLEX system symbol in other parmlib members. (5.2) Identifies one or more IEASYMxx members of SYS1.PARMLIB that the system is to use. (5.2)
NUCLEUS SYSCAT SYSPARM SYSPLEX
IEASYM
Transition Statement OS/390 uses a set search order for the Loadxx member.
3-25
Instructor Guide
Figure
3-10. IPL Flow (1 of 2) (ES271319)
Notes:
H/W IPL

S/390 Load complete window is displayed if successful ES/390 L indicator disappears if successful
IRIMs
Disabled wait state if unsuccessful See Loadxx Search sequence chart
NIP (with no available channel attached console)
S/390 NIP message response required Operating Message ICON flashes on the HMC and associated IMAGE object changes color.
ES/9000 Message waiting invoke OPRMSG frame is displayed on line 24
3-26
Instructor Guide
Note: All NIP responses will have prefix of R 00, A NIP console is required before DASD pathing takes place to allow the operator to respond to out-of-line conditions encountered during the DASD pathing. DASD pathing

32 devices are tested at a time After each successful I/O another DASD device tested If the I/O fails to complete in 15 seconds, the I/O operation is purged The I/O is rescheduled to be retried during master scheduler initialization
Sysplex Initialization
Couplexx determines Sysplex operational mode Sysplex Local Sysplex monosystem Sysplex multisystem
3-27
Instructor Guide
Instructor Notes:
Purpose Big picture timeline of IPL Details When the load function is invoked from the HMC (S/390) or the hardware system console (9021 or 9121), the hardware converts the device number entered in the load address to the corresponding subchannel number and enables that subchannel.
The hardware builds and stores the initial IPL CCW at location 0 in main storage. The CCW is: 02000000 60000018
The channel subsystem executes the initial CCW and reads 18 bytes of data from IPL device. The remainder of the IPL text is then read into main storage from the IPL device. The S/390 status of the hardware portion of load is indicated on the Activate Task confirmation panel The load is complete when the OK pushbutton is enabled and status is complete. Load failures will be indicated in the Activate panel and failure details will be provided.
The 9021 or 9121 will indicate load complete when the L indicator is turned off on the hardware system console. If IPL fails while the L indicator is still on, check for messages on the hardware system console (line 23) or conlog (press the VIEWLOG key). Ensure the correct IPL device was specified and that the device is ready.
At completion of the hardware IPL the SSID is stored at location B8- BB. This enables MVS/XA to identify the SYSRES device to the channel subsystem in future I/O operations.
3-28
Instructor Guide
M V S
I P L
P a c k
O r g a n i z a t i o n
Architected Hardware IPL Sequence CHPID executes a x02 Read of x18 bytes DASD Will Automatically: 1. SEEK Cyl=00 , Head=00 2. Read Rec=01 Records on MVS IPL Pack (Cyl=00 , Head=00) HA Rec=01 Home Address IPL Record Identifies Track ID x18 byte IPL CCW Chain written by ICKDSF at pack initialization time. CCW Chain designed to search past the VOLSER for IPL Text Volume Serial Number written by ICKDSF at pack initialization time IPL RIMs (IEAIPL00 - IEAIPL99) that begin the actual execution of MVS written code.
Rec=02
Bootstrap Record
Rec=03
VOLSER
Rec=04
IPL Text
IRIMs Test Block Inst (clean Stor) SCPINFO Get Loadparm Set autostore status on Find LOADxx Find IODF Load Nucleus Build UCBs Load Prefix Reg IRIMs Complete The search order for the LOADxx member is:

SYS0.IPLPARM to SYS9.IPLPARM on the IODF volume SYS1.PARMLIB on the IODF volume SYS1.PARMLIB on SYSRES
The FIRST SYSn.IPLPARM or if no SYSn.IPLPARMs present the SYS1.PARMLIB found is searched for the loadxx, if the loadxx is not found a disabled wait state occurs. A NIP console is required before DASD pathing takes place to allow the operator to respond to out-of-line conditions encountered during the DASD pathing.
Copyright IBM Corp. 1997, 1998 Unit 3. MVS/ESA or OS/390 IPL Flow 3-29
Instructor Guide
DASD pathing has changed in MVS V5 or higher:

32 devices are tested at a time After each successful I/O another DASD device tested If the I/O fails to complete in 15 seconds, the I/O operation is purged The I/O is rescheduled to be retried during master scheduler initialization IOS120A is not surfaced during NIP IGGN504, IGGN505 msg for missing data sets IOS120A may occur after responding to IGGN msg SSCH to 32 devices at a time Redrive another device after I/O completes on a device Path testing - each path No 1.5 second timeout (no IOS120A during path testing)
Device Characteristics-one path Self Description - each path (IOS291 msg) VOLSER Checking- one path for SDP products (all paths for other DASD) Duplicate VOLSER message (IEA213A-not SYSRES or IEA214A-SYSRES)
At end of pathing - wait 15 seconds for any outstanding I/O to Complete Mark any UCB with outstanding I/O to test again later Purge all outstanding I/O requests
1 (P) Path Testing Each Path
2 (D) UCB Device Characteristics Initialization One Path
3 (S) SDP
4 (V) VOLSER
Each Path
CCW 94 Release
CCWs E4 Sense Id 64 RDC 54 Subsystem FA RCD Message IEC334 Duplicate SSID
CCWs E4 Sense ID (one path) FA RCD (each path) Message IOS291I Configuration Mismatch
One Path SDP device Each Path Non SDP device
Message IGGN504A IGGN505A Required Data Set missing IOS120A moved to MSI
Message IEA213A IEA214A Duplicate VOLSER
DASD pathing consists of four different operations: path testing on each path (P),read device characteristics (D), self-describing product (S), and VOLSER processing (V).
3-30
Instructor Guide
Any error conditions detected during the DASD pathing steps are reported to the NIP console via the IGGN504A, IGGN505A, IEC334I, IOS291I, IEA213A or IEA214A message. Any A or action messages require operator response.

CCW = Channel Command Word MSI = Master Scheduler Initialization RDC = Read Device Characteristics RCD = Read Configuration Data SDP = Self Describing Product (all ESCON Control Units) SSID= Subsystem ID (DASD Control Units)
3-31
Instructor Guide
Figure
3-11. Operating System Messages (ES271323)
Notes:
In the example above the system found duplicate volume IDs on the SYSRES DASD during the Nucleus Initialization Program (NIP). NIP presents a message that requires an operator response. NIP messages that require a response are prefixed with R 00, as shown above.
3-32
Instructor Guide
Instructor Notes:
Purpose Show how the operator replies to a NIP message Transition Statement If you are joining an existing Sysplex you will sell the following.
3-33
Instructor Guide
Figure
3-12. Sysplex Initialization (ES271331)
Notes:
The Sysplex is initialized from information contained in the COUPLExx member of parmlib and information contained in the couple datasets. After the system being IPLed establishes communication with all existing Sysplex members it joins the Sysplex and no operator action is required.
3-34
Instructor Guide
Instructor Notes:
Details The sysplex is initialized from information contained in the COUPLExx member of parmlib and information contained in the couple datasets. After the system being IPLed establishes communication with all existing sysplex members it joins the sysplex and no operator action is required.
3-35
Instructor Guide
Figure
3-13. IPL Flow (2 of 2) (ES271333)
Notes:
During master scheduler the command member will be processed. The command member usually contains software subsystems and tasks that are to be started automatically at the end of IPL. Some examples are

JES VTAM TSO NETVIEW
Each of the above create their own address space that can be seen by using the Display Active List command (D A,L)
3-36
Instructor Guide
Instructor Notes:
Purpose Explain big picture IPL timeline sequence.
3-37
Instructor Guide
3-38
Instructor Guide
Checkpoint
Exercise Unit 3 MVS/ESA or OS/390 IPL Flow

TF 1. The LOADxx member can provide the IPL information that use to require operator intervention during the IPL process. Correct Answer 1. True
2.
DASD pathing is performed a. b. c. before NIP console processing takes place. after NIP console processing take place sequentially. If one device is busy, IPL processing waits until the problem is resolved. Correct Answer 2. b
3.
Match the following terms with their correct meanings. a. b. c. d. First 4 characters of the load parameter 5 and 6 characters of the load parameter Load device Load Clear Correct Answer 3. a, b, c, d IODF device number LOADxx to be used SYSRES device number Performs a system reset, clear storage and load
4.
Place the following in order to perform an activate of a LPAR partition named LP1 on a CEC named CEC1 in a group called IPL. Open Groups View Drag and drop CEC1 LP1 on the Activate Task Click on Yes to begin the activate process Verify that LP1 on CEC1 is targeted and the correct profile has been assigned
3-39
Instructor Guide
Correct Answer 4. 1, 2, 4, 3
5.
Place the following in order to perform a load clear operation of a partition named LPAR1 using the OPRCTL frame on a 9021. Verify load information and perform the Load Clear (O7) Invoke the OPRCTL frame UNLOCKLP LPAR1 SETLP LPAR1 LOCKLP ALL Correct Answer 5. 4, 2, 3, 1, 5
END OF CHECKPOINT EXERCISE.
3-40
Instructor Guide
3-41
Instructor Guide
Figure
Notes:
3-42
Instructor Guide
Instructor Notes:
3-43
Instructor Guide
3-44
Instructor Guide
Unit 4. MVS/ESA or OS/390 Consoles Operation

This unit describes the operation of consoles when operating OS/390.


Determine the status and parameters of any console. Perform recovery procedures for console error conditions.

Accountability:

Checkpoint questions Lab Projects
References
SC28-1452 GC28-1441 GC28-1442 GC28-1480 GC28-1481 GC28-1482 GC28-1483 GC28-1484 MVS/ESA Init. and Tuning Reference V5 MVS/ESA Planning: Operations V5 MVS/ESA System Commands V5 MVS/ESA (V5) System Messages, Vol 1 V5 MVS/ESA (V5) System Messages, Vol 2 V5 MVS/ESA (V5) System Messages, Vol 3 V5 MVS/ESA (V5) System Messages, Vol 4 V5 MVS/ESA (V5) System Messages, Vol 5 V5
4-1
Instructor Guide
Figure
Notes:
4-2
Instructor Guide
Instructor Notes:
4-3
Instructor Guide
Figure
4-2. OS/390 Overview (ES271401)
Notes:
System Services OS390 Consoles
4-4
Instructor Guide
Instructor Notes:
4-5
Instructor Guide
4-6
Instructor Guide
4.1 MVS/ESA or OS/390 Console Operation and Recovery
4-7
Instructor Guide
Figure
4-3. Console Information (ES271402)
Notes:
Beginning with MVS V4, a symbolic console name may be specified using the NAME parameter on the CONSOLE statement of CONSOLxx member of SYS1.PARMLIB. The use of symbolic names for consoles is highly recommended. Once a console has been initialized the IEE612I and IEE163I messages are displayed on the bottom of the console screen. IEE162I provides the console name, device number, name of system that this console is attached to and the name of the system that commands entered on this console will be executed on. IEE163I identifies the consoles roll mode. Note: IEE163 is not displayed if DEL=N is set.
4-8
Instructor Guide
Instructor Notes:
Purpose Details Field CN= DEVNUM= SYS= CMDSYS= IEE612I Explanation Name of this console if specified in CONSOLxx or MVS-generated ID if a name is not specified in the CONSOLxx member Device number of this console System that this console is attached to (from IEASYSxx SYSNAME=xxxx) System where commands entered on this console will be executed (SYSPLEX)
Additional Information Transition Statement
4-9
Instructor Guide
Figure
4-4. Console Display Commands (ES271403)
Notes:
The Display console commands can be used to obtain information about MCS consoles. The symbolic name is displayed if defined in CONSOLxx for that console. Otherwise, only the system-generated name (equivalent to the ID) is displayed.
4-10
Instructor Guide
Instructor Notes:
Purpose Details Syntax D C,* Requested Info Who am I? Explanation Symbolic name, device number and status of console issuing command Symbolic name, device number (online console only) and status of all consoles with AUTH=MASTER Symbolic name, device numbers and status of all active consoles Symbolic names, device numbers (online devices only) and status of all consoles (active and inactive) defined to the system in SYS1.PARMLIB(CONSOLxx) Symbolic names, device numbers, ID, system ID, and status of all active consoles. Symbolic names, device numbers, ID, system ID, and status of all inactive consoles. Symbolic names, device numbers and status of all consoles that are using WTO or WTOR buffers, listed in descending order by number of buffers used. Names of the console groups, suffix of the CNGRP member in PARMLIB used to define the console groups, console-names of the consoles that are members of each group
D C,M
Who has Master Authority?
D C,A or D C D C,L
What MCS consoles are active?
What devices are genned as consoles?
D C,A,CA
What are the console/system associations for all active consoles. What are the console/system associations for all inactive consoles. What devices have message buffers in use?
D C,N,CA
D C,B
D CNGRP
What console groups are active?
4-11
Instructor Guide
Figure
4-5. D C,*Command (ES271405)
Notes:
The D C,* command provides information about the console that the command was entered on. In this example:

The console name is SYSAMSTR The console device number is 0020 and its attached to SYSA UD=Y indicates that undeliverable messages will be received at this console (COND=M console always has UD=Y).
4-12
Instructor Guide
Instructor Notes:
Purpose Details Some of the fields in this display include:
CONSOLE/ALT Symbolic name of this console (for example, SYSAMSTR) If a symbolic name is not assigned in the CONSOLxx member then the system will assign a symbolic name that equates to the console ID number (CN=01). Symbolic name of the alternate (ALT561/TAPE661) This appears only if an alternate is specified in the CONSOLxx definition Beginning with MVS 4.2, ALTGRP may be specified instead of Alternate (highly recommended) Device number of this console - displayed for active consoles only Sysname of the system to which this console is attached (displayed for active consoles only); may be different from CMDSYS parameter
ID - Console identification assigned by MVS at IPL time COND - console status H - hardcopy M - master The first online console with master level authority (AUTH=MASTER) becomes the master console (COND=M). Only one console with COND=M may exist. A - active N - inactive SS - subsystem-allocatable SS,M - subsystem console with pseudomaster capability
AUTH - specifies command groups this console can enter. MASTER - Master console authority - multiple consoles may have this
authority
INFO - informational commands (default) SYS - system control and informational commands IO - I/O control and informational commands CONS - console control and informational commands ALL - system control, I/O control, console control and informational commands
DEL - message deletion mode R - roll mode (all messages roll off the screen)
4-13
Instructor Guide
RD - roll-deletable mode (all messages except action messages roll off the screen) N - No deletion (messages must be manually deleted from the screen) Y - automatic deletion (certain flagged messages are removed when the message area is full) W - wrap mode (new messages overlay older messages when the message area is full; WTORs and action messages are overlaid and not retained)

RTME - number of seconds between message rolls RNUM - number of message lines included in one message roll UD - (Undelivered message handling); Y specifies that this console is to receive undelivered messages. COND=M console will have UD=Y. MSCOPE - Systems from which messages are received *ALL indicates that this console will receive messages from all sysplex members (MAIN OPERATIONS CONSOLE SHOULD HAVE THIS SETTING)
ALTGRP - name of the alternate group for this console Specifies the consoles eligible to backup this console in the case of a console failure
NBUF - number of WTO message buffers currently queued to this console
4-14
Instructor Guide
4-15
Instructor Guide
Figure
4-6. D C,A or D C (ES271407)
Notes:
The D C,A command displays the characteristics of all the active consoles.
4-16
Instructor Guide
Instructor Notes:
4-17
Instructor Guide
Figure
4-7. D C,M Command (ES271409)
Notes:
The D C,M command displays all consoles with master authority including extended consoles (IDs 100 or higher). Note: In this example the hardware console has an ID of 100. The PD indicates that the V CN(*),ACTIVATE command has been previously issued.
4-18
Instructor Guide
Instructor Notes:
4-19
Instructor Guide
Figure
4-8. D C,A,CA and D C,N,CA Command (ES271411)
Notes:
D C,N,CA or D C,A,CA commands will list the console associations for inactive or active consoles.

The D C,A,CA command displays the active consoles. The D C,N,CA command displays the inactive consoles.
4-20
Instructor Guide
Instructor Notes:
Purpose Details The D C,A,CA command displays the active consoles. Message IEE890I provides one line of information for each active console in the system or sysplex and they are sorted by name. The console with a status of Master in response to the D C,A,CA command is the console with COND=M (this example, SYSAMSTR is MSTCONS) The D C,N,CA command displays one line of information for all the inactive consoles in the system or sysplex. The D C,N,CA command is the only way to obtain the device number for an inactive console that did not have the name specified in the active CONSOLxx member (in this example the console named 09 is device number 029). Additional Information Transition Statement
4-21
Instructor Guide
Figure
4-9. CONSOLxx Member of SYS1.PARMLIB (ES271413)
Notes:
The console name, device number and console attributes for every MCS console is defined in the CONSOLxx member of SYS1.PARMLIB.
4-22
Instructor Guide
Instructor Notes:
Purpose Details The RMAX value was introduced in SP V4. A value between five and 9999 may be used. If a value larger than 99 is used, installations may have to adjust the size of the sysplex couple data set (maximum number of members in a group). Consoles create members in the SYSMCS2 XCF group based on the value specified for RMAX. The purpose of these members is to use the couple data set member user state data to build a table of the reply id numbers. This is the way the console in a JES2 sysplex environment is sharing reply ids across the sysplex to ensure that the reply id value is unique. In V5, if you specify an RMAX value less than 99, and the CURRMAXSYS (maximum number of systems allowed in the sysplex) is greater than eight, consoles will automatically change the RMAX value to 99, adjust the size of the sysplex couple data set, and issue message IEA403I to indicate that RMAX is 99. This change in reply id processing for more than eight systems in the sysplex is set by a trigger which will occur when the sysplex couple data set is formatted by the V5 utility and the max systems is set greater than eight using MAXSYSTEM. Note: RMAX cant be greater than 99 in a JES3 complex. Reply ID processing is different in V5 in a sysplex environment. In pre-SP V5, systems in the sysplex would use XCF services to access the XCF member user data on the couple data set to determine the next available reply id. The performance overhead of this method would be too great in a greater than eight-way sysplex. In V5, reply ids are still unique in the sysplex, however, MVS will no longer preserve any observable sequential order to reply ids. Allocation of reply ids will be from storage instead of the couple data set whenever possible. Recently freed reply ids will not be immediately reused. Hardcopy to EMCS consoles can be defined with MCSOPER. The MCSOHDCY flag in OPERPARM parmlist (IEZVG111) can be used. The RACF OPERPARM does not support this, there are no plans to add the support to RACF OPERPARM. The hardcopy to EMCS console function could be used to create a combined SYSLOG. Note: RACF OPERPARMS are essentially frozen at SP V4.2.2. Additional Information Transition Statement
4-23
Instructor Guide
Figure
4-10. Console Groups (CNGRP) (ES271415)
Notes:
The CNGRP group is used to provide for console recovery. The D CNGRP command will display the current CNGRP and all members. Console names are required for all consoles in the CNGRP.
The ALTGRP member in the CONSOLxx member of SYS1.PARMLIB defines the switch to console in the event of a console failure (ALTGRP member is named ALTCONS in this example) The SYNCHDEST member specifies the name of the consoles that can receive synchronous WTOR messages (SYNCCON in this example). If a SYNC WTOR condition occurs and the console is not in the SYNCHDEST group or not currently active, the COND=M console will be used if it is on the system that experienced the SYNC WTOR condition; otherwise the Operating System Messages (9672) or OPRMSG (9021,9121 or 3090) will be used.
The NOCCGRP - member provides a list of eligible consoles that may become the Master Console if a NO consoles condition (NOCONS in this example).
4-24
Instructor Guide
Instructor Notes:
Purpose Details
Alternate console group - during a console switch, MVS searches for an alternate console based on the order of the consoles defined in the group. The name of the alternate console group to be used by each console is specified using the ALTGRP parameter of the CONSOLE statement. The named console group is defined in CNGRPxx. It is highly recommended that an alternate console group be defined.
Synchronous message console group - specifies the name of the console group whose members can receive synchronous WTOR messages. The name of this console group is specified using the SYNCHDEST parameter of the DEFAULT statement. The named console group is defined in CNGRPxx. If a SYNC WTOR condition occurs and the console is not in the SYNCHDEST group or not currently active, the COND=M console will be used if it is on the system that experienced the SYNC WTOR condition; otherwise the Operating System Messages (9672) or OPRMSG (9021/9121) will be used. Note: No more than one console from each image in the sysplex should be specified in the SYNCHDEST member.
No Consoles group - specifies the name of the console group from whose members the system can select a master console during a no consoles condition. The name of this console group is specified using the NOCCGRP parameter of the INIT statement. The named console group is defined in CNGRPxx.
Console groups are optional. In general, if no console groups are specified, the system will use the master console by default (if it is physically attached to the system encountering the condition). All console groups are defined in the CNGRPxx member of SYS1.PARMLIB.
Console names must be used when defining a console group.
GROUP Identifies the beginning of a console group definition. Each group definition consists of one NAME keyword and one MEMBERS keyword. You can specify more than one GROUP statement in one CNGRPxx parmlib member. NAME(group name) Specifies the name of the console group. Use this name in the CONSOLxx parmlib member for one of the following reasons: On the CONSOLE statement to identify a switch candidate in case of a console failure. On the HARDCOPY statement to identify a backup hard-copy console device.
4-25
Instructor Guide
On the INIT statement to identify master console candidates in a no master consoles condition. These master console candidates cannot be extended MCS consoles. On the DEFAULT statement to specify the order in which consoles are to receive synchronous messages. MEMBERS(console name ,console name,...) Specifies the ordered list of console names belonging to the specified group. Depending on whether a console is an MCS console or an extended MCS console, define its name through either: The CONSOLE statement of the CONSOLxx parmlib member for MCS consoles RACF or TSO/E for extended MCS consoles. The following reserved console names have special meanings when used as part of a console group:
Console name *SYSCON*
Meaning When used in a group specified on the SYNCHDEST keyword on the DEFAULT statement in CONSOLxx, this routes a synchronous message to the system console. When used in a group specified on the SYNCHDEST keyword on the DEFAULT statement in CONSOLxx, this routes a synchronous message to the master console. When used in a group specified on the HCPYGRP keyword on the HARDCOPY statement in CONSOLxx, this selects SYSLOG as a hard-copy switch candidate.
*MSTCON*
*SYSLOG*
4-26
Instructor Guide
4-27
Instructor Guide
Figure
4-11. Console Switching (ES271417)
Notes:
The alternate console group for any console can be determined by displaying that consoles status (D C,*) and looking at the ALTGRP=field. Only consoles with master authority (AUTH=MASTER) can issue the V dddd,MSTCONS command (single system in scope) or V consname,MSTCONS (sysplex wide in scope).
4-28
Instructor Guide
Instructor Notes:
Purpose Details During IPL the console defined as the NIP console by HCD is used by the system. When nucleus initialization is complete, the NIP console switches to the consoles defined in the CONSOLxx member of SYS1.PARMLIB. The COND=M console is the first console defined with AUTH=MASTER on the first system IPLed in the sysplex. The master and NIP console should be the same physical console. After IPL, the master console may switch to an active alternate for one of several reasons. If an ALTGRP is defined for the master console, a switch causes the system to locate the first active console in the alternate console group and switches the master console functions to that console. The alternate console group for any console can be determined by displaying that consoles status (D C,*) and looking at the ALTGRP=field. Additional Information Transition Statement
4-29
Instructor Guide
Figure
4-12. Console Failure Example (ES271419)
Notes:
The active CNGRPxx console group member definitions can be displayed by entering D CNGRP command. The active sysplex consoles can be determined by issuing the D C,A,CA and comparing this list against the ALTGRP (ALTCONS in this example). In this example even though four consoles are active, only two of the consoles are in the ALTCONS group, SYSAMSTR and SYSAALT1
4-30
Instructor Guide
Instructor Notes:
Purpose Use these displays with the next two visuals to demonstrate how console groups and console switching work. Details Referring to D CNGRP and D C,A,CA displays, the only active consoles listed in ALTCONS member of CNGRP(S1) (SYSAMSTR and SYSAALT1) are eligible for switch selection in the event of a console failure. Note:
If no ALTGRP or ALTERNATE is specified, the console with COND=M becomes the backup. If the console definition has an ALTERNATE parameter specified, the switch will cause the alternate (if active) to become the master. However, unlike previous releases of MVS, if the alternate is unavailable MVS will not continue to search down the chain of alternates for an active console. A no master console condition occurs in this case (IEE141A MASTER AND ALL ALTERNATES UNAVAILABLE)
When a switch occurs the new master console has (COND=M) and master authority (AUTH=MASTER). This authority is maintained even if you later switch the master console to another console with the MVS V ddd,MSTCONS command. To change the authority of a console, use the V CN(xx),AUTH=xxxx command. In this example, the master console (SYSAMSTR) is defined with ALTGRP=ALTCONS. MVS will attempt to switch to the first active console listed in the ALTCONS console group, starting from the beginning of the list. Additional Information Transition Statement
4-31
Instructor Guide
Figure
4-13. Console Switching Example (ES271421)
Notes:
The D CNGRP display indicates that only two consoles in the CNGRP group are currently active in the sysplex. The D C,A,CA command displays all the active consoles. In this example four consoles are active.
4-32
Instructor Guide
Instructor Notes:
Purpose The D CNGRP display indicates that only two consoles in the CNGRP group are currently active in the sysplex (switch to candidates) Use this visual to demonstrate console switching. The sysplex has four active consoles, but only two switch candidates, so the IEE141A condition will be created. Details Additional Information Transition Statement
4-33
Instructor Guide
Figure
4-14. Console Named SYSAMSTR Fails (ES271423)
Notes:
In this example:

SYSAMSTR was the current COND=M console SYSAMSTR console fails SYSAMSTR is defined with an ALTGRP member ALTCONS Searches the ALTCONS member for the first active console The SYSAALT1 console becomes the new COND=M console
4-34
Instructor Guide
Instructor Notes:
Purpose The master console failed and switched to the first available console in the console group. Use the CNGRP and D C,A,CA visuals to demonstrate switching to SYSAALT1. Details Additional Information Transition Statement
4-35
Instructor Guide
Figure
4-15. IEE141A Condition (ES271425)
Notes:
Any console receiving the IEE141A message can issue the V cn]dddd,MSTCONS command to make itself the master console. The Operating System Messages Task (S/390) or the OPRMSG frame (9021, 9121) can also be used to recover from the IEE141A condition. Note: Message IEE141A will be issued to all active consoles that are not part of the alternate console group specified for the former master console.
4-36
Instructor Guide
Instructor Notes:
Purpose In this example, the last active console in the ALTCONS member of the CNGRP failed. However, two active consoles still exist but they are not switch candidates. Therefore the IEE141A message is issued to each active console. Any console receiving this message can make itself the new master console by issuing the V dddd]con-name,MSTCONS command. Details Any console receiving the IEE141A message can issue the V cn]dddd,MSTCONS command to make itself the master console.

No active consoles are available in the ALTGRP member of the CNGRP. Active consoles still exist in the sysplex.
The Operating System Messages Task (S/390) or the OPRMSG frame (9021, 9121) can also be used to recover from the IEE141A condition. A new master console can be assigned by issuing the V cn]dddd,MSTCONS command for any console displaying the IEE141A message. Note: Message IEE141A will be issued to all active consoles in the sysplex that are not part of the alternate console group specified for the former master console. Additional Information Transition Statement
4-37
Instructor Guide
Figure
4-16. No Active MCS Consoles Exist (ES271427)
Notes:
A console of last resort always exists. The hardware console can be used in these situations and until an MCS console has been repaired. The V CN(cnname or console ID),ONLINE command will restore an MCS console.
4-38
Instructor Guide
Instructor Notes:
4-39
Instructor Guide
4-40
Instructor Guide
Checkpoint
Exercise Unit 4 Checkpoint

TF 1. Only the COND=M console has master authority. Correct Answer 1. false
2.
ans=c,d,a,b keep=20p. Match the following console terms with their correct meanings. a. b. c. d. D C,A,CA V CN(cn\ID),ONLINE D C,N,CA D C,B Displays the inactive consoles Displays console with buffers currently in use Displays the active consoles Activates a console
Correct Answer 2. a, b, c, d
TF
3.
Once IPL has completed the V CN(*), ACTIVATE command must be entered before any MVS commands may be entered on the Operating System Messages Task. Correct Answer
3.
true
4-41
Instructor Guide
Figure
4-17. S u m m a r y (ES271499)
Notes:
4-42
Instructor Guide
Instructor Notes:
4-43
Instructor Guide
4-44
Instructor Guide
Unit 5. OS/390 MVS Commands

This unit describes the various MVS commands that may be used for problem determination and recovery.


Issue OS/390 MVS commands with the correct syntax. Be familiar with the new OS/390 MVS commands. Interpret the results of MVS commands.

Accountability:

Checkpoint questions Lab exercises
References
SC28-1752 GC28-1760 GC28-1781 GC28-1784 GC28-1785 GC28-1786 GC28-1787 GC28-1788
OS/390 MVS Init. and Tuning Reference OS/390 MVS Planning: Operations OS/390 MVS System Commands OS/390 MVS System Messages, Vol 1 OS/390 MVS System Messages, Vol 2 OS/390 MVS System Messages, Vol 3 OS/390 MVS System Messages, Vol 4 OS/390 MVS System Messages, Vol 5
5-1
Instructor Guide
Figure
Notes:
5-2
Instructor Guide
Instructor Notes:
Purpose To be able to issue commands using the proper syntax and interpret command and message output. Details The correct syntax and commands are documented in System Commands. To interpret message output use System Message Vol. 1 through 4. Transition Statement The key to issuing OS/390 commands is not only knowing the proper command but also the correct syntax. Next we look at how to interpret the required syntax from the system commands book.
5-3
Instructor Guide
Figure
5-2. OS/390 Overview (ES271501)
Notes:
System Services OS390 Commands
5-4
Instructor Guide
Instructor Notes:
5-5
Instructor Guide
5-6
Instructor Guide
5.1 OS/390 MVS Commands Syntax, Messages, and Meanings
5-7
Instructor Guide
Figure
5-3. Message Format (ES271502)
Notes:
Messages are the systems chief means of communication with you.
Informational Which are important but do not require a response.
Immediate action Require that you perform the requested action at once. The action might be required because the message issuer waits until the action is performed, or because taking the action as soon as possible can improve system performance.
Eventual action and critical eventual action The message issuer is not waiting for you to perform the action, but a number of unanswered requests might degrade system performance.
5-8
Instructor Guide
Instructor Notes:
Details
|------------------------------------------------------------------------| | id CCCnnn text | | id CCCnnns text | | id CCCnnnns text | | id CCCnnnnns text | | id CCCSnnns text | | | |------------------------------------------------------------------------|
id Reply identifier: optional. It appears if an operator reply is required. The operator specifies it in the reply.
CCCnnn, CCCnnns, CCCnnnns, CCCnnnnns, CCCSnnns Message identifier. CCC A prefix to identify the component, subsystem, or product that produced the message. The prefix is three characters. S The subcomponent identifier, which is an optional addition to the prefix to identify the subcomponent that produced the message. The subcomponent identifier is one character. nnn, nnnn, nnnnn A serial number to identify the individual message. The serial number is three, four, or five decimal digits. s An optional type code, which is one of the following: A Action: the operator must perform a specific action. D Decision: the operator must choose an alternative. E Eventual action: the operator must perform action when time is available. I Information: no operator action is required. Most information messages are for a programmer. S Severe error: severe error messages are for a programmer. W Wait: processing stops until the operator performs a required action.
5-9
Instructor Guide
Figure
5-4. Optional Code Meanings (general usage) (ES271503)
Notes:
Descriptor codes are associated with message type codes, specified by a letter following the message serial number, as follows:
Descriptor Code 1 2 3 4 through 10 11 12 and 13
Type Code W (wait) A (action) or D (decision) E (eventual action) I (information) E (eventual action) I (information)
5-10
Instructor Guide
Instructor Notes:
Details Descriptor codes describe the significance of messages. They indicate whether the system or a task stops processing, waits until some action is completed, or continues. This code also determines how the system will display and delete the message. Descriptor codes are associated with message type codes, specified by a letter following the message serial number, as follows:
Descriptor Code 1 2 3 4 through 10 11 12 and 13
Type Code W (wait) A (action) or D (decision) E (eventual action) I (information) E (eventual action) I (information)
Descriptor Code Meaning 1. System Failure The message indicates an error that disrupts system operations. To continue, the operator must reIPL the system or restart a major subsystem. 2. Immediate Action Required The message indicates that the operator must perform an action immediately. The message issuer could be in a wait state until the action is performed or the system needs the action as soon as possible to improve performance. The task waits for the operator to complete the action. 3. Eventual Action Required The message indicates that the operator must perform an action eventually. The task does not wait for the operator to complete the action. 4. System Status The message indicates the status of a system task or of a hardware unit. 5. Immediate Command Response The message is issued as an immediate response to a system command. The response does not depend on another system action or task. 6. Job Status The message indicates the status of a job or job step. 7. Task-Related The message is issued by an application or system program. Messages with this descriptor code are deleted when the job step that issued them ends. 8. Out-of-Line
5-11
Instructor Guide
The message, which is one line of a group of one or more lines, is to be displayed out-of-line. If a message cannot be printed out-of-line because of the device being used, descriptor code 8 is ignored, and the message is printed in-line with the other messages. 9. Operators Request The message is written in response to an operators request for information by a DEVSERV, DISPLAY, TRACK, or MONITOR command. 10. TRACK Command Response The message is issued in response to a TRACK command. 11. Critical Eventual Action Required The message indicates that the operator must perform an action eventually, and the action is important enough for the message to remain on the display screen until the action is completed. The task does not wait for the operator to complete the action. 12. Important Information The message contains important information that must be displayed at a console, but does not require any action in response. 13. Automation Information Indicates that this message was previously automated. Routing Codes-The routing codes are specified in the ROUTCDE parameter of the WTO or WTOR macro. If you specify a message which contains no routing codes, MVS may provide one or more default routing codes based upon the presence or lack of other queueing specifications. Routing Code and Meaning: 1. Operator Action The message indicates a change in the system status. It demands action by the operator at the console with master authority. 2. Operator Information The message indicates a change in system status. It does not demand action; rather, it alerts the operator at the console with master authority to a condition that might require action. This routing code is used for any message that indicates job status when the status is not requested specifically by an operator inquiry. It is also used to route processor and problem program messages to the system operator. 3. Tape Pool The message gives information about tape devices, such as the status of a tape unit or reel, the disposition of a tape reel, or a request to mount a tape. 4. Direct Access Pool
5-12
Instructor Guide
The message gives information about direct access storage devices (DASD), such as the status of a direct access unit or volume, the disposition of a volume, or a request to mount a volume. 5. Tape Library The message gives tape library information, such as a request by volume serial numbers for tapes for system or problem program use. 6. Disk Library The message gives disk library information, such as a request by volume serial numbers for volumes for system or problem program use. 7. Unit Record Pool The message gives information about unit record equipment, such as a request to mount a printer train. 8. Teleprocessing Control The message gives the status or disposition of teleprocessing equipment, such as a message that describes line errors. 9. System Security The message gives information about security checking, such as a request for a password. 10. System/Error Maintenance The message gives problem information for the system programmer, such as a system error, an uncorrectable I/O error, or information about system maintenance. 11. Programmer Information The message is intended for the problem programmer. This routing code is used when the program issuing the message cannot route the message to the programmer through a system output (SYSOUT) data set. The message appears in the job log. 12. Emulation The message gives information about emulation.

13-20 For customer use only. 21-28 For subsystem use only. 29-40 For IBM use only. 41 42 The message gives information about JES3 job status. The message gives general information about JES2 or JES3.
43-64 For JES use only. 65-96 Messages associated with particular processors. 97-128 Messages associated with particular devices.
5-13
Instructor Guide
Figure
5-5. Messages Requiring a Response (WTOR) (ES271505)
Notes:
5-14
Instructor Guide
Instructor Notes:
Details The DISPLAY R command can be issued to display outstanding messages requiring operator action. These messages include WTOR messages, action messages saved by AMRF, action messages issued by the communications task, and action messages that were not displayed on all necessary consoles. You can request that the system display:
The immediate action messages (descriptor codes 1 or 2), eventual action messages (descriptor code 3), and critical eventual action messages (descriptor code 11) The device numbers of devices waiting for mount requests to be fulfilled The device numbers of devices waiting for operator intervention The status of the action message retention facility An alphabetical list of keynames of outstanding action messages The messages issued by a specified system The messages that await operator response at a specified console The messages that have specific routing codes
5-15
Instructor Guide
Figure
5-6. Determining Outstanding WTORs (D R,R) (ES271507)
Notes:
If the D R,R command is issued on a console that has master authority, ALL outstanding WTORs will be displayed. If the issuing console does not have master authority, the CN=(ALL) parameter should be included with any D R,L,CN=(ALL) command. Otherwise, the system only displays information about those messages that appeared on the console that issues the D R,R command
5-16
Instructor Guide
Instructor Notes:
Purpose To show and explain the output of the D R, R command. Details The texts and message identification numbers of all messages awaiting replies are to be displayed. The system also displays a number that represents the total of all outstanding WTORs or action messages. Note: If the issuing console has master authority, the system displays, on the issuing console, all outstanding WTORs. Otherwise, unless you specify the CN parameter on the command, the system displays information about only those messages that appeared on the console that issues the D R command Transition Statement Next we will look at display type commands.
5-17
Instructor Guide
System Command Syntax

Table 5-1. System Command Syntax
Notation Apostrophes Comma Ellipsis... Lower Case Parameter
Meaning Must be entered as shown. Must be entered as shown. The parameter can be repeated. Do not enter the ellipsis. A parameter must be substituted. You can enter the command and the parameter in either upper or lower case. You must enter one of the items. You cannot enter more than one. Must be entered as shown.
Example Book Syntax
SEND message , NOW DISPLAY C,K VARY (conspec[,conspec]...),ONLINE MOUNT devnum
Or-bar (I) Parentheses and special characters Single parameter in brackets Stacked items in braces Stacked items with or-bars (I) and brackets
ACTIVATE[,RECOVER=SOURCE|TARGET] DUMP COMM=(text)
The parameter is optional.
DISPLAY DMN[=domainum] {DSNAME} {SPACE } {STATUS} ,SDUMP ] |,SYSABEND |,SYSUDUMP |,SYSMDUMP |,ALL
You must enter one of the items. You cannot enter more than one. Optional, mutually exclusive parameters. Enter one or none.
MN
CD RESET [
Underline
If you do not enter one of the parameters, the system supplies the underlined parameter, which is the default The parameter must be spelled as shown. You can enter the command and the parameter in either upper or lower case.
K T [,REF ] [,UTME=nnn]
Upper Case Parameter
DISPLAY SMF
Figure
5-7. System Command Syntax (ES271509T)
Notes:
Syntax Information: You must follow certain rules (syntax) when you code commands.
5-18
Instructor Guide
Instructor Notes:
Purpose To define the symbols used in the command book to issue the correct syntax for MVS commands. Additional Information Listed in the MVS commands document. Transition Statement Next we will see some examples.
5-19
Instructor Guide
Figure
5-8. MVS/ESA Operator Commands (ES271511)
Notes:
Description: Vary device command Examples

V 400,ONLINE V (400,401),ONLINE V 400,ONLINE,UNCOND
5-20
Instructor Guide
Instructor Notes:
Show how to read syntax information.
5-21
Instructor Guide
D A,L Command
D A,L IEE114I 21.45.20 96.081 ACTIVITY 566 JOBS M/S TS USERS SYSAS INITS 00000 00008 00002 00019 00017 LLA LLA LLA NSW S VLF APPC APPC APPC NSW S ASCH ESCM E PSTEP01 OWT S NET JES2 JES2 IEFPROC NSW S TSO RSK OWT STEW IN
ACTIVE/MAX VTAM 00002/00050 VLF VLF ASCH ASCH NET VTAM TSO STEP1
OAS 00000 NSW S NSW S NSW S OWT S
IN = OUT = OWT = OU* = IN* = NSW =
Swapped in Swapped out, ready to run Swapped out, waiting, not ready to run In the process of being swapped out In the process of being swapped in Non-swappable
A J M S *
= = = = =
ATX Job Mount Started task System address space
Figure
5-9. D A,L Command (ES271513T)
Notes:
The D A,L command will list the address spaces currently in the system.

JOBS - The number of address spaces running under initiators. M/S - The number of address spaces created by a MOUNT or START command, but not an initiator. TS USERS - The number of active Time Sharing Option Extensions (TSO/E) address spaces. SYSAS - The number of system address spaces. INITS - The number of started job entry subsystem (JES) and advanced program-to-program communications (APPC) initiators in the system. ACTIVE/MAX VTAM - The number of active TSO/E address spaces using the Virtual Telecommunications Access Method (VTAM) and the maximum number of TSO/E address spaces that could use VTAM. OAS - The total number of OpenMVS address spaces on this system.
5-22
Instructor Guide
Instructor Notes:
Details
IEE114I hh.mm.ss yy.ddd ACTIVITY JOBS xxxxx M/S xxxxx jjj jjj sss sss TS USERS xxxxx ppp ppp
idr SYSAS xxxxx INITS xxxxx o o ACTIVE/MAX VTAM xxxxx/xxxxx OAS xxxxx
www zz x www zz x
jjj sss... stradrK - endadrK
userid www zz userid www zz ... DISPLAY TRUNCATED - INSUFFICIENT STORAGE NO ENTRIES FOUND WITH USERID=rquserid
Explanation: The system issues this message when the operator enters a DISPLAY command with either:

JOBS, or TS, or A as a single parameter The JOBS,LIST or the TS,LIST or the A,LIST parameters
D A,L - The displays for both JOBS,LIST and TS,LIST. In the message text:

JOBS - The number of address spaces running under initiators. M/S - The number of address spaces created by a MOUNT or START command, but not an initiator. TS USERS - The number of active Time Sharing Option Extensions (TSO/E) address spaces. SYSAS - The number of system address spaces. INITS - The number of started job entry subsystem (JES) and advanced program-to-program communications (APPC) initiators in the system. ACTIVE/MAX VTAM - The number of active TSO/E address spaces using the Virtual Telecommunications Access Method (VTAM) and the maximum number of TSO/E address spaces that could use VTAM. OAS - The total number of OpenMVS address spaces on this system.
Note: If the value for JOBS is less than the value for INITS, some initiators are inactive. The sum of the values for JOBS, M/S, TS USERS, and SYSAS is the total number of active address spaces.
jjj - One of the following: The name of a job or ATX attached by an initiator. The procedure name of a task created by a START or MOUNT command. STARTING if initiation of a started job, task, or ATX is incomplete.
sss - One of the following: The step name for a job or ATX attached by an initiator. The identifier of a task created by the START command. The step name for a step that called a cataloged procedure.
5-23
Instructor Guide
STARTING if initiation of a started job, task, or ATX is incomplete. Blank, if there is no stepname or procedure stepname.
ppp - One of the following: For APPC-initiated transactions, the userid requesting the transaction. The step name within a procedure that was called by the step specified in field sss. Blank, if there is no procedure or procedure stepname.
www - The status of the job, task, ATX, or TSO/E address space: IN Swapped in. OUT Swapped out, ready to run. OWT Swapped out, waiting, not ready to run. OU* In the process of being swapped out. IN* In the process of being swapped in. NSW Non-swappable.
zz - One of the following: LW Address space is in long wait.
Note: LW appears only when the address space is swapped in or is non-swappable. LW indicates an abnormal condition. NF - Address space is not dispatchable because of a failure in the address space. PR - Address space has a program event recording (PER) SLIP trap active.
x - The type of user: A ATX J Job M Mount S Started task * System address space An OpenMVS dubbed address space.
o -
userid - One of the following: The identifier of an active TSO/E user. *LOGON*, if initiation of the address space is incomplete.
5-24
Instructor Guide
5-25
Instructor Guide
Figure
5-10. MVSESA and OS/390 Address Spaces (ES271515)
Notes:
There are five different types of address spaces in OS/390. Each type is defined by the type of work performed and how the address space was created.

System address spaces - created by OS/390 when the system is initialized. Subsystem address spaces - created by OS/390 during system initialization on the START command (JES, VTAM). Started task programs are created using the START command. TSO user address spaces are created at LOGON time. Batch job address spaces are created with the START INIT command.
System and subsystem address space have more authority and capabilities than other address spaces.
5-26
Instructor Guide
Instructor Notes:
Details There are five different types of address spaces in OS/390. Each type is defined by the type of work performed and how the address space was created.

System address spaces - created by OS/390 when the system is initialized. Subsystem address spaces - created by OS/390 during system initialization on the START command (JES, VTAM). Started task programs are created using the START command. TSO user address spaces are created at LOGON time. Batch job address spaces are created with the START INIT command.
System and subsystem address space have more authority and capabilities than other address spaces.
5-27
Instructor Guide
D A,A Command
D A,A IEE115I 21.46.44 96.081 ACTIVITY 568 JOBS M/S TS USERS SYSAS INITS ACTIVE/MAX VTAM OAS 00000 00008 00002 00019 00017 00002/00050 00000 *MASTER* *MASTER* NSW * A=0001 PER=NO SMC=000 PGN=000 DMN=000 AFF=NONE CT=00.24.45 ET=14.34.43 WUID=STC00110 CONSOLE CONSOLE NSW * A=000A PER=NO SMC=000 PGN=005 DMN=006 AFF=NONE CT=018.156S ET=14.34.43 JES2 JES2 IEFPROC NSW S A=001D PER=NO SMC=000 PGN=009 DMN=006 AFF=NONE CT=202.337S ET=14.34.30 INIT INIT IEFPROC OWT I A=0024 PER=NO SMC=000 PGN=000 DMN=000 AFF=NONE CT=000.024S ET=NOTAVAIL WUID=STC00115 USERID=++++++++ RSK OWT A=0036 PER=NO SMC=000 PGN=002 DMN=001 AFF=NONE CT=008.976S ET=00.28.43 WUID=TSU00270
Figure 5-11. D A,A Command (ES271517T)
Notes:
The D A,A command will list all active address spaces.

* = System Address Space S = Started Task I = Initiator Address Space A=Address space identifier (ASID), in hexadecimal. PER=YES or NO - PER trap is active or not active in the address space SMC = Number of outstanding step-must-complete requests. PGN = Performance group number. DMN = Domain number AFF = The identifier of a specific processor (None=job can run on any processor). CT = The processor time used by the address space, including the initiator. ET = Elapsed time for the address space.
5-28
Instructor Guide
Instructor Notes:
Details
IEE115I hh.mm.ss yy.ddd ACTIVITY JOBS xxxxx jjj sss ppp www zz x o M/S xxxxx TS USERS xxxxx
idr INITS xxxxx ACTIVE/MAX VTAM xxxxx/xxxxx OAS xxxxx
SYSAS xxxxx
A=asid PER=aaa SMC=bbb
PGN=ccc DMN=eee AFF=ffff CT=nnnnnnnn ET=nnnnnnnn WUID=workid USERID=rquserid WKL=kkkkkkkk SCL=llllllll P=m RGP=rrrrrrrr SRVR=vvv QSC=qqq stradrK - endadrK ADDR SPACE ASTE=gggggggg DSPNAME=hhhhhhhh ASTE=iiiiiiii DISPLAY INCOMPLETE userid www zz o A=asid PER=aaa SMC=bbb
PGN=ccc DMN=eee AFF=ffff CT=nnnnnnnn ET=nnnnnnnn WUID=workid WKL=kkkkkkkk SCL=llllllll P=m RGP=rrrrrrrr SRVR=vvv QSC=qqq ADDR SPACE ASTE=gggggggg DSPNAME=hhhhhhhh ASTE=iiiiiiii DISPLAY INCOMPLETE

A = Address space identifier (ASID), in hexadecimal. PER = YES A PER trap is active in the address space. NO No PER trap is active in the address space. S M C = Number of outstanding step-must-complete requests. PGN = Performance group member N/A, not applicable. PGN=N/A is displayed for one of the following reasons: If WKL= , SCL= , P= , RGP= , SRVR= , QSC= are displayed, PGN is irrelevant because the system is operating in goal mode. If the above WLM information is not displayed, PGN=N/A means the system is not able to retrieve either PGN or WLM information. DMN = Domain number N/A, not applicable. DMN=N/A is displayed for one of the following reasons: If WKL= , SCL= , P= , RGP= , SRVR= , QSC= are displayed, DMN is irrelevant because the system is operating in goal mode.
5-29
Instructor Guide
If the above WLM information is not displayed, DMN=N/A means the system is not able to retrieve either DMN or WLM information. AFF = CP affinity The identifier of the processor, for up to any four processors, if the job requires the services of specific processors. ffff can also be one of the following: NONE The job can run on any processor. *VF* Vector Facility (VF) affinity is required, but there is no processor with an attached Vector Facility available. CT = Computer time - The processor time used by the address space, including the initiator. This time does not include SRB time. ET = Elapsed Time For address spaces other than system address spaces, the elapsed time since job select time. For system address spaces created before master scheduler initialization, the elapsed time since master scheduler initialization. For system address spaces created after master scheduler initialization, the elapsed time since system address space creation. nnnnnnnn has one of these formats, where ttt is milliseconds, sss or ss is seconds, mm is minutes, and hh or hhhhh is hours: sss.tttS When time is less than 1000 seconds hh.mm.ss When time is at least 1000 seconds, but less than 100 hours hhhhh.mm When time is at least 100 hours ******** When time exceeds 100000 hours NOTAVAIL When the TOD clock is not working
5-30
Instructor Guide
5-31
Instructor Guide
Figure
5-12. Display Commands (ES271519)
Notes:
The D U commands get most of their information from the UCB. The D M commands get information from the UCB, UCW and the channel subsystem (CSS). The DevServ Paths command gets its information from the UCB, control unit and device as a result of actual I/O operations on each path. The DevServ Paths command supports DASD and tape only.
5-32
Instructor Guide
Instructor Notes:
Details The D U commands get most of their information from the UCB. The D M commands get information from the UCB, UCW and the channel subsystem (CSS). The DevServ Paths command gets its information from the UCB, control unit and device as a result of actual I/O operations on each path. The DevServ Paths command supports DASD and tape only.
5-33
Instructor Guide
D U Command
D U,devicetype,ONLINE,dddd,n DASD ,OFFLINE D U,VOL=vvvvvv TAPE ,ALLOC D U,IPLVOL UR ,AUTOSWITCH (MVS 5.2) D IPLINFO CTC GRAPHIC
D U,,,160,1 SYEB IEE457I 11.05.32 UNIT STATUS 117 UNIT TYPE STATUS VOLSER VOLSTATE 0160 3270 C
Figure
5-13. D U Command (ES271521T)
Notes:
The D U command displays the current status of any device using information contained in the UCB.
OFFLINE O A AS S C -SPD -BSY -R -P -M -PND -BOX A-NRD F-NRD F-SYS

5-34
The device is offline. Online Allocated Automatically Switchable SYSRES device Console (an MVS/SP console) Suspended - a paging volume I/O operation in progress (sent to Channel Subsystem) Reserved DASD or single-system assigned 3480/3490 Reserve to DASD device is pending Multi-system assigned 3480/3490 Pending state change to the offline state The device is in a boxed state Allocated and placed in the not ready (NRD) state; The device is offline and not ready. It may also be in The device is offline and allocated to the system.
Instructor Guide
Instructor Notes:
Details If the number of devices is not specified the D U command will display 16 lines of data or 16 devices. The IEE457I message replaced the IEE450I message at MVS 5.2. The status values may include:
OFFLINE O A AS S C -SPD -BSY -R -P -M -PND -BOX A-NRD
F-NRD
F-SYS
The device is offline. Online Allocated Automatically switchable SYSRES device Console (an MVS/SP console) Suspended - a paging volume I/O operation in progress (sent to Channel Subsystem) Reserved DASD or single-system assigned 3480/3490 Reserve to a DASD device is pending Multi-system assigned 3480/3490 Pending state change (the device is in the process of being varied offline) The device is in a boxed state (refer to account procedures for recovering a boxed device) Allocated and placed in the not ready (NRD) state; When establishing a dual copy pair with a pace of zero, the Primary device will be placed in this state if any other activity is requested against the device until the copy process is complete. Device is offline and not ready. It may also be in the SYS state. Use DEVSERV PATHS to determine if it is NOT-ALLOCATABLE, i.e. is the device being controlled by the system. The device is offline and allocated to the system. This can occur for the following functions: - ICKDSF - Dual Copy (Secondary Device) - OLTEP is running against the device.
5-35
Instructor Guide
D U Command Continued
D U,DASD,ONLINE,210,4 SYEB IEE457I 11.05.51 UNIT TYPE STATUS 0228 3390 A -R 0229 3390 O 0231 3390 A-BSY 0232 3390 A-SPD
UNIT STATUS VOLSER BCXKN1 BDXK02 BDXK04 PAGE02
934 VOLSTATE PRIV/RSDNT PRIV/RSDNT PRIV/RSDNT PRIV/RSDNT
D U,VOL=CSAR01 SYEB IEE457I 11.07.01 UNIT STATUS UNIT TYPE STATUS VOLSER VOLSTATE 03BC 3390 S CSAR01 PRIV/RSDNT
Figure
5-14. D U Command Continued (ES271523T)
Notes:
5-36
Instructor Guide
Instructor Notes:
Purpose To show different outputs of the DU command. Transition Statement Next we will look at the command to Display Configuration information.
5-37
Instructor Guide
D M=DEV Command
IEE174I 08:08:08 DISPLAY M DEVICE STATUS: NUMBER OF CHANNEL PATHS ONLINE 0 1 2 3 4 5 6 7 8 9 A B C D E F 000 . . . . . . . . . DN . . . . 1 . 00C 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 00D 1 1 1 1 1 1 1 1 1 1 BX 1 1 1 1 1 012 2 2 2 2 2 2 2 2 2 2 2 2 # # # # 014 2 2 2 2 2 2 2 2 2 2 2 2 # # # # 016 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 126 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3@ 134 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 135 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 136 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 137 4 4 4 4 4 4 4 4 4 4 4 4 # # # # 252 4@ 4@ 4@ 4@ 4@ 4@ 4@ 4@ 4@ 4@ 4@ 4@ # # # # ***************************** SYMBOL EXPLANATIONS ****************** @ ONLINE, PHYSICALLY ONLINE, AND OPERATIONAL INDICATORS ARE NOT EQUAL + ONLINE # DEVICE OFFLINE . DOES NOT EXIST BX DEVICE IS BOXED SN SUBCHANNEL NOT AVAILABLE DN DEVICE NOT AVAILABLE PE SUBCHANNEL IN PERM ERROR
Figure 5-15. D M=DEV Command (ES271525T)
Notes:
The D M command is used to display information about the hardware components of the system. The status of specific hardware resources can be displayed by using certain operands. This display shows the device status and number of online channel paths to all devices in the system.
5-38
Instructor Guide
Instructor Notes:
Details The symbols have the following meanings:
DN - the device has been defined to MVS in the MVSCP or HCD but not defined in the IOCP (there is no subchannel for this device; or the device exists in the IOCDS but has not been defined in the MVSCP/HCD (UCB has the Not Connected bit (byte 7 bit 2) on). This situation may occur because: The same MVSCP/HCD input was not used for the IOCP input. The wrong IOCDS has been loaded.
. - the device has not been defined to in the MVSCP/HCD or the IOCDS. Not all non-existent devices numbers are displayed in message IEE174I - only those in the range XX0-XXF where other device numbers do exist.
Numbers (1, 2, 3, 4) - indicate the number of online CHPIDS for the device. @ - indicates an out-of-line condition (online, physically online and operational indicators are not equal) for at least one of the paths. Use the D M=DEV(ddd) command to determine which indicators are not equal (that is, not all Y or not all N): online (path online), physically online (CHPID physically online), and operational (path operational)
5-39
Instructor Guide
Figure
5-16. D M=DEV(dddd) (ES271527)
Notes:
The D M=DEV command provides information on the availability of a device and the status of channel paths (CHPIDs) to this device. The Path Online field indicates whether the path is logically online to MVS and will change as a result of the VARY PATH command. The CHP Physically Online field indicates whether the channel is physically available. This field will change as a result of the MVS CF CHP command. The Path Operational status is changed as a result of the channel subsystem attempting an I/O operation on a path and the path responding with a not operational I/O interface sequence (select-in).
5-40
Instructor Guide
Instructor Notes:
Details The D M=DEV command provides information on the availability of a device and the status of channel paths (CHPIDs) to this device. The Path Online field indicates whether the path is logically online to MVS and will change as a result of the VARY PATH command. Information for this field is obtained from the UCBLPM. The CHP Physically Online field indicates whether the path is physically available. This field will change as a result of the MVS CF CHP command. Information for this field is obtained from the PAM in the UCW. Note: The Path Operational field might not be accurate when the CHPID has been stolen from MVS using the CHNCFA frame instead of using the MVS CF CHP(cc), OFF command. The Path Operational status is changed as a result of the channel subsystem attempting an I/O operation on a path and the path responding with a not operational I/O interface sequence (select-in). This can be due to:

Disabling of a channel interface at a control unit Disabling or switching a channel interface at switch unit (3814) Powering off a control unit, storage director or DASD controller
Warning - This line of the display can easily be misinterpreted. It is a direct

reflection of a path mask called the POM in the UCW.
5-41
Instructor Guide
Figure
5-17. Paths Not Validated (ES271529)
Notes:
The PATHS NOT VALIDATED line will appear if no successful I/O was done during IPL or during a Vary Device command to validate the paths. Once any I/O has been successful on any path, all paths will be validated.
5-42
Instructor Guide
Instructor Notes:
Purpose To explain what path not validated means. Details The PATHS NOT VALIDATED line will appear if no successful I/O was done during IPL or during a Vary Device command to validate the paths. If the device is defined to come up offline at IPL time, no path validation occurs. For these devices, the UCBVALPH bit is set on to indicate that the paths to this device were not validated. Validation will occur the first time the device is varied online. The UCB LPM is set to the PIM value when this condition exists. Transition Statement Next we will look at information displayed about the system channels.
5-43
Instructor Guide
D M=CHP(cc) Command
D M=CHP(2E) IEE174I 14.23.08 DISPLAY M 485 DEVICE STATUS FOR CHANNEL PATH 2E 0 1 2 3 4 5 6 7 8 9 A B C D 0F1 $@ $@ $@ $@ $@ $@ $@ $@ . . . . . . 0F2 $@ $@ $@ $@ $@ $@ $@ $@ . . . . . . 0F3 $@ $@ $@ $@ $@ $@ $@ $@ . . . . . . 0F4 $@ $@ $@ $@ $@ $@ $@ $@ . . . . . . 0FD . + . . . . . . . . . . . . 401 $ $ $ $ + $ + + . . . . . . 402 $@ $@ $@ $@ $@ $@ $@ $@ . . . . . . 403 $ $ $ $ + $ + + . . . . . . 404 $ $ $ $ + $ + + . . . . . . 405 $ $ $ $ + $ + + . . . . . . 406 $ $ $ $ + + + + . . . . . . ************************ SYMBOL EXPLANATIONS + ONLINE @ PATH NOT VALIDATED - OFFLINE * PHYSICALLY ONLINE $ PATH NOT OPERATIONAL
E F . . . . . . . . . . . . . . . . . . . . . . ************************ . DOES NOT EXIST
Figure
5-18. D M=CHP(cc) Command (ES271531T)
Notes:
This command provides the path status for every device defined on this channel. The ONLINE status (+) indicates the logical path status of this path to the device (NOT device status). The PHYSICALLY ONLINE status (*) indicates that the CHPID is configured online but that the path is LOGICALLY OFFLINE to MVS. This status indicator is affected by the VARY PATH(ddd) command.
5-44
Instructor Guide
Instructor Notes:
Purpose To explain the output of the D M = CHP (CC). Details A range may also be specified D M = CHP (xx-xx) Transition Statement Next lets look at what the output would be if no chpid paths were specified.
5-45
Instructor Guide
Figure
5-19. D M=CHP Command (ES271533)
Notes:
The D M=CHP command now provides the type of channel along with the channel state. A reconfigurable CHPID that is (physically) offline from its owning partition appears offline to all logical partitions (-). In both basic and LPAR mode, a CHPID that is not defined in the IOCDS is marked does not exist (.).
5-46
Instructor Guide
Instructor Notes:
Purpose To explain the output of the command. Details This can be a very useful command to show you very quickly the status of all the channels on your system. Transition Statement Next we will look at the D M = CPU command.
5-47
Instructor Guide
D M=CPU Command
D M=CPU IEE174I 18.49.57 DISPLAY M PROCESSOR STATUS ID CPU SERIAL 0 + 0241569672 1 + 1241569672 2 + 2241569672 3 + 3241569672 4 + 4241569672 5 + 5241569672 CPC ND = 009672.RX5.IBM.02.000000044156 CPC ID = 00
Figure
5-20. D M=CPU Command (ES271535T)
Notes:
D M=CPU or CPUID Command.
Displays the online and offline status of one or more processors and any vector facilities or ICRFs attached to those processors also provide the node descriptor and CPC ID. The node descriptor provides the: Processor type Model number Manufacturer Plant of manufacturer Sequence number
5-48
Instructor Guide
Instructor Notes:
Details Message format:
ID CPU VF CF SERIAL cpuid s s s ser_no cpuid s s s ser_no CPC ND = tttttt.nnn.mmm.pp.ssssssssss CPC ID = ii + ONLINE OFFLINE . DOES NOT EXIST
VF VECTOR FACILITY CF CRYPTO FACILITY CDC ND CENTRAL PROCESSING COMPLEX NODE DESCRIPTOR CDC ID CENTRAL PROCESSING COMPLEX IDENTIFIER CPC ND = tttttt.nnn.mmm.pp.ssssssssss ttttt The central processing complex node descriptor type number, in EBCDIC. nnn The central processing complex node descriptor model number, in EBCDIC. mmm The central processing complex node descriptor manufacturer, in EBCDIC. pp The central processing complex node descriptor plant of manufacture, in EBCDIC. ssssssssssss The central processing complex node descriptor sequence number, in EBCDIC. ii The central processing complex node identifier, in binary.
5-49
Instructor Guide
CONFIGxx Member of SYS1.PARMLIB

Contents of a CONFIGxx Member of SYS1.PARMLIB
CPU(0),ONLINE CPU(1),ONLINE CPU(2),ONLINE CHP(00-9F),ONLINE STOR(0M-2048M),ONLINE ESTOR(0M-128M),ONLINE DEV(02A0-02AF),(12,20,40,50),ONLINE DEV(0520-052F),(21,23,61,63),ONLINE DEV(07B0-07B7),(10,15),ONLINE DEV(07B8-07BF),OFFLINE DEV(001F),00,ONLINE
Figure
5-21. CONFIGxx Member of SYS1.PARMLIB (ES271537T)
Notes:
The D M=CONFIG(xx) command is used to call member CONFIGxx in SYS1.PARMLIB. It is strongly recommended that all accounts have a current CONFIGxx member that reflects critical resources required for efficient system operation. Operations should execute the D M=CONFIG(xx) command at least once per shift.
5-50
Instructor Guide
Instructor Notes:
Details The D M=CONFIG(xx) command is used to call member CONFIGxx in SYS1.PARMLIB. The CONFIGxx data set contains a predefined hardware configuration that should reflect all the resources critical to system operation. In response to the D M=CONFIG(xx) command, the system compares the contents of the CONFIGxx member to the current configuration. It then displays the differences, if any exist, to the operator. The operator may then take the necessary steps to correct the deviations. It is strongly recommended that all accounts have a current CONFIGxx member that reflects critical resources required for efficient system operation. Operations should execute the D M=CONFIG(xx) command at least once per shift. The CONFIGxx member specifications for devices should include both the device number range and the paths to those devices. This allows the system to report deviations for either a device or a path that is not in the desired state.
5-51
Instructor Guide
D M=CONFIG Command Output
D M=CONFIG(S1) If NO deviation is found, the following message appears: IEE097I 13.46.14 DEVIATION STATUS FROM MEMBER CONFIGS1 NO DEVIATION FROM REQUESTED CONFIGURATION
D M=CONFIG(S1) If a deviation is found the message format appears as follows: IEE097I 13.46.14 DEVIATION STATUS FROM MEMBER CONFIGS1 DEVICE DESIRED ACTUAL 02A6 ONLINE OFFLINE 07B8 OFFLINE ONLINE 0520,61 ONLINE OFFLINE 052F ONLINE BOXED 07B0,10 ONLINE NOT OPERATIONAL
Figure 5-22. D M=CONFIG Command Output (ES271539T)
Notes:
The CONFIGxx member specifications for devices should include both the device number range and the paths to those devices. This allows the system to report deviations for either a device or a path that is not in the desired state.
5-52
Instructor Guide
Instructor Notes:
Details In response to a reconfiguration display request, the system issued this message to display the deviation between the configuration that actually exists and the configuration described in the CONFIGxx parmlib member.
IEE097I hh.mm.ss DEVIATION STATUS FROM MEMBER CONFIGxx elemtype elemadr DESIRED desstat ACTUAL actstat
NO DEVIATION FROM REQUESTED CONFIGURATION NO DEVIATION COMPARISONS MADE CONFIG MEMBER CONTAINS NO VALID INPUT DISPLAY M RESOURCE PATH IS CURRENTLY IN USE DISPLAY M RESOURCE CPU IS CURRENTLY IN USE
In the message text:
FROM MEMBER CONFIGxx - This heading appears for each record in the CONFIGxx parmlib member in which the system detected an error. xx is the suffix of the CONFIGxx parmlib member. elemtype - The name of the system element for which the actual status does not match the desired status. The possible system elements are: CPU or CPUAD - Processor. CHP - Channel path. CHP(ALL,x) - All channel paths on side x. DEVICE - Device. ESTOR(E=id) - The expanded storage element. VOLUME - Volume. STORAGE RANGE - Central storage range. STOR AMOUNT - Central storage amount. STOR(E=x) - Central storage element. ESTOR RANGE - Expanded storage range. elemadr - The address of the system element with the incorrect status, or the volume serial number of a volume that is not correctly mounted. For storage, only one storage range or amount appears on each line: desstat - The desired status of the system element. Possible values are: ONLINE - Indicates that the central processor, channel path, device, storage range, or storage element should be online. OFFLINE - Indicates that the central processor, channel path, device, storage range, or storage element should be offline. dev - The device number of the device on which the volume should be mounted. An X in the number indicates that the digit can be any value. For example, if dev is XXX, the volume can be mounted on any direct access device. actstat - The actual status of the resource. Possible values are: ONLINE - Indicates that the central processor, channel path, device, storage range, or storage element is online. OFFLINE - Indicates that the central processor, channel path, device, storage range, or storage element is offline.
Unit 5. OS/390 MVS Commands 5-53
Instructor Guide
NOT AVAILABLE - Indicates that the central processor, channel path, or storage element was in another partition. NOT GEN]NOT GEND - Indicates that the central processor, channel path, device, storage range, or storage element was not specified when the system was installed. PARTIAL - Indicates that only a portion of the requested amount of storage or some of the channel paths on a side were allocated. UNCHANGED - Indicates that the requested storage was not allocated. NOT OPERATIONAL - Indicates that the path was not operational. SUBCHANNEL STATUS NOT AVAILABLE - Indicates that the device is not defined in the I/O configuration data set (IOCDS). SUBCHANNEL IN PERMANENT ERROR - Indicates that the subchannel is broken. DEVICE NOT AVAILABLE - Indicates that the device is deferred. BOXED - Indicates that the device is boxed, that is, placed offline, because of a hardware problem. NOT MNTD]NOT MTD - Indicates that the volume is not mounted. NO DEVIATION FROM REQUESTED CONFIGURATION - The system found no deviations. DISPLAY M RESOURCE PATH IS CURRENTLY IN USE - The system could not obtain the SYSZVARY.PATH resource to serialize the DISPLAY M=CONFIG command with commands such as CONFIG; therefore, displayed information might be incorrect. To determine which jobs currently hold the SYSZVARY.PATH resource, issue the DISPLAY GRS,RES=(SYSZVARY,PATH) command. Reissue the DISPLAY M=CONFIG command when the resource becomes available. DISPLAY M RESOURCE CPU IS CURRENTLY IN USE - The system could not obtain the SYSZVARY.CPU resource to serialize the DISPLAY M=CONFIG command with commands such as CONFIG; therefore, displayed information might be incorrect. To determine which jobs currently hold the SYSZVARY.CPU resource, issue the DISPLAY GRS,RES=(SYSZVARY,CPU) command. Reissue the DISPLAY M=CONFIG command when the resource becomes available.
5-54
Instructor Guide
5-55
Instructor Guide
Figure
5-23. DS Paths Command (ES271541)
Notes:
The DEVSERV PATHS command supports both tape and DASD. The output of the DEVSERV PATHS command is based on the results of actual I/O operations attempted over each path for the device (non-boxed devices). I/O is performed down every path in the UCBLPM field, even those paths that are offline. DEVSERV I/O operations are tried as follows:
To non-boxed online or offline devices when the path is either online or offline and the CHPID is in the configuration.
If the DEVSREV paths command is issued to a 3990 model 3 or model 6, message IEE459I will contain status information for the extended functions CFW, cache, DASD Fast Write, dual copy and the SSID.
5-56
Instructor Guide
Instructor Notes:
Details See next visual instructor notes for IEE459I explanation.
5-57
Instructor Guide
DevServ Paths to DASD
DS P,1D7,2 IEE459I 15.50.07 DEVSERV PATHS UNIT DTYPE M CNT VOLSER CHPID=PATH STATUS RTYPE SSID CFW TC DFW PIN DC-STATE CCA DDC ALT CU-TYPE 01D7,33903,A,006,SLT1D7,41=+ 52=+ 4C=+ 5D=* 0001 Y YY. YY. N PRIMARY 17 17 1E7 3990-3 01D8,33903,N,000, ,41=+ 52=+ 4C=+ 5D=+ 0001 Y YY. YY. N SECONDARY 18 18 1E8 3990-3 ************************ SYMBOL DEFINITIONS ************************ N = DEVICE NOT ALLOCATABLE A = ALLOCATED + = PATH AVAILABLE * = LOGICALLY OFFLINE, PHYSICALLY ONLINE
DS P,620 IEE459I 14.30.50 DEVSERV PATHS 422 UNIT DTYPE M CNT VOLSER CHPID=PATH STATUS RTYPE SSID CFW TC DFW PIN DC-STATE CCA DDC ALT CU-TYPE 0620,33903 ,O,000,RAS620,61=+ 65=+ 93921 000A Y NY. NY. N SIMPLEX 20 60 3990-3 ************************ SYMBOL DEFINITIONS ************************ O = ONLINE + = PATH AVAILABLE
Figure 5-24. DevServ Paths to DASD (ES271543T)
Notes:
5-58
Instructor Guide
Instructor Notes:
Details The DEVSERV PATHS command supports both tape and DASD. The output of the DEVSERV PATHS command is based on the results of actual I/O operations attempted over each path for the device (non-boxed devices). I/O is performed down every path in the UCBLPM field, even those paths that are offline. It therefore may reflect a more accurate picture of the device and path status than the D U,,,ddd,1 or D M=DEV(ddd) commands. Refer to the messages manual for a description of the IEE459I message associated with the DEVSERV PATHS command. DEVSERV I/O operations are tried as follows:
To non-boxed online or offline devices when the path is either online or offline and the CHPID is in the configuration.
Message IEE459I is issued in response to the DEVSERV command and displays the following information for one device or a group of devices (tape or DASD only):

The logical mode of the device The number of data sets allocated on the volume The volume serial label The channel path ID The status of the path Fence conditions or DASD attached to a 3990 3990-3 or 3990-6 extended functions SSID of this 3990 subsystem State of cache fast write State of device and subsystem caching State of device DASD fast write and NVS State of pinned data Dual copy status The channel unit address (CCA) The director to device connection address (DDC) Control unit type
An explanation of the symbol definitions is presented in the (dynamic) legend following the device entries. The format of the DEVSERV PATHS command is:

DS DS DS DS
P,ddd display data for device ddd P,ddd,nn display data for nn devices beginning with ddd P,ddd,nn,ONLINE P,ddd,nn,OFFLINE
The fields have the following meanings: UNIT - device number DTYPE - device type and model For 3480s the characters indicate features:
5-59
Instructor Guide
3480S - 3480 with automatic cartridge loader 3480X - 3480 with the compaction feature (IDRC) 3480SX - 3480 with both the automatic cartridge loader and the compaction feature (IDRC)
M - logical mode (device status) A - allocated F - logically offline to MVS M - mount pending O - logically online to MVS P - pending offline to MVS N - Not allocatable; a system component has control CNT - number of data sets allocated on the volume VOLSER - volume serial number CHPID - channel path ID and path status + = Path is logically and physically available and I/O on the path was successful * = Path is physically but not logically available. The VARY PATH (ddd,nn),ONLINE command can be issued to bring the channel path online. - = Path is neither logically nor physically available. The CHPID is configured offline. & = The device is reserved to another path. < = Path is installed but not physically available. > = Device microcode has detected an error and will not allow I/O to complete on the path. B = Path is unable to communicate. The device indicates that a busy or reserve condition exists on the path. C = Controller error occurred while accessing the device D = A device error occurred while accessing the device I = Intervention is required; device is not ready R = Path is available and the device is reserved to this path T = A time out has occurred; there is no response from the device. U = Storage control unit or storage director error occurred while accessing the device. X = Unable to determine the failing unit. If the DEVSERV Paths command is issued to a 3380/3390 attached to a 3990 model 3 or model 6, message IEE459I will contain status information for the extended functions CFW, cache, DASD Fast Write, dual copy and the SSID, as shown in the following example: For DASD devices attached to a 3990 model 3 or 6, two data lines are displayed for each device. The first data line is common to all devices that the DS PATHS command supports. The second data line applies only to DASD attached to a 3990-3 or 6 and is offset from the first data line. SSID is the Subsystem ID for this storage subsystem CFW field displays the state of Cache Fast Write Y - Cache Fast Write is active
Instructor Guide
N - Cache Fast Write is inactive S - Cache Fast Write is suspended for pinned data TC field displays the state of caching for the device and storage subsystem. Both the T & C fields have to be YY for device caching to be active. 1st character (under the T) indicates whether this device is eligible for caching. Y - Device cache is active N - Device cache is inactive P - Device cache is pending inactive, destage is in progress F - Device cache is pending inactive, destage has failed 2nd character (under the C) displays the state of subsystem cache. Y - Subsystem cache is active N - Subsystem cache is inactive A - Subsystem cache is pending active F - Subsystem cache is pending inactive, destage has failed M - Subsystem cache is disabled for maintenance P - Subsystem cache is pending inactive, destage in progress T - Subsystem error has caused cache to be terminated 3nd character is a period . - Caching does not occur until both the first and second characters are Y DFW field is used to display the state of DASD fast write (DFW). Both DFW fields have to be YY along with device cache (TC=YY) for device DFW to be active 1st character (under the F) indicates whether this device is eligible for DFW. Y - DFW is active for this device N - DFW is inactive for this device I - DFW is inhibited for this device, destage is in progress U - Data exists in failed NVS for this device S - Device DASD fast write is suspended due to pinned data 2nd character (under the W) displays the state of non-volatile storage (NVS). Y - Subsystem NVS is available and DFW is allowed N - Subsystem NVS is unavailable and DFW is not allowed P - Subsystem NVS is pending unavailable, destage is in progress F - Subsystem NVS is pending unavailable, destage failed U - Subsystem NVS is failed I - Subsystem NVS battery is defective, DFW is inhibited M - Subsystem NVS is disabled for maintenance 3nd character is a period . - DFW does not occur until both the first and second characters are Y and both TC characters are Y PIN - State of pinned data N - Device does not have data pinned in cache or NVS Y - Device has data pinned in cache or NVS; CFW and DFW are permitted S - Device has data pinned in cache or NVS; CFW and DFW are suspended DC-STATE - Reflects the dual copy state SIMPLEX This device is not a member of a dual copy pair PRIMARY device of a dual copy pair in active duplex state
5-61
Instructor Guide
SECONDARY device of a dual copy pair in active duplex state PRI-PNDG establishment of a duplex pair is in progress; this will be the primary device SEC-PNDG establishment of a duplex pair is in progress; this will be the secondary device PRI-SDPL Dual Copy pair is in a suspended duplex state, this is the current and original Primary device. SEC-SDPL Dual Copy pair is in a suspended duplex state, this is the current and original Secondary device. PRI-SSEC Dual Copy pair is in a suspended duplex state, this is the device that was the secondary and is now the primary SEC-SPRI Dual Copy pair is in a suspended duplex state, this is the device that was the primary and is now the secondary CCA - The channel subsystem device address (one hex byte) DDC - Subsystem internal logical device address (one hex byte) ALT - The address of the other device of a dual copy pair. CU-TYPE - Control unit type and model A character X in any field indicates the status is not recognized by the DS paths command.
5-62
Instructor Guide
5-63
Instructor Guide
Figure
5-25. Vary Commands (ES271545)
Notes:
The MVS VARY command is used to cause the logical reconfiguration of I/O devices or I/O paths. By using the VARY command, certain system resources can be made available or unavailable for system use. The VARY command can be used to:
Change the online or offline status of resources: Place an I/O device (or a range of I/O devices) online or offline Place an I/O path (or paths) online or offline Assign the 3480 tape device as shareable among more than one system Place a secondary console online or offline Change the master console Control a global resource serialization (GRS) complex
5-64
Instructor Guide
Instructor Notes:
Purpose Explain the various uses of the vary command. Details Entering the Vary device online command will make the device or range of devices available for allocation provided there is an online path to the devices. Note: The Vary device command will not place a device online if all the paths have been taken offline or no operational paths exist. Entering the Vary device offline command will place the device or range of devices in the offline state provided the device is not currently allocated and not allocation contention exists. The system takes offline any device that is currently in use only after the tasks to which it is allocated terminate. The VARY device,OFFLINE command takes effect when a system task starts. Beginning at MVS 4.3 allocation is invoked when the V dddd, offline command is accepted, thereby reducing but not eliminating the need to enter a START DEALLOC (or account equivalent) to cause a system task to start, allowing the system to take device(s) offline. Use the VARY device,OFFLINE,FORCE command only with great care in situations where the system is in serious trouble. When this command is executed, the system:
Immediately places the device in pending-offline status, even if it is currently active, allocated, or reserved. Stops I/O in progress on the device and rejects future I/O requests to the device as permanent I/O errors.
Even if a specified device is already offline, the command immediately terminates all I/O in progress on the device. Thus, the command might cause the loss of data, as well as a data integrity problem if the command prematurely releases a reserved device or unassigns an assigned device. Use the VARY PATH command to move a path to a device or range of devices online or offline. A path is the local route between a processor and a device, consisting of the processor, a channel path, and a control unit. A path can be offline if:

One or more of the path components is offline A VARY PATH OFFLINE command has been entered
Paths taken offline with a VARY PATH command can only be brought online again with another VARY PATH command. When you enter the VARY PATH,OFFLINE command, the system takes the specified paths offline. The system rejects this command if the specified path is the last available path to a device that is:
5-65
Instructor Guide
Online (either allocated or unallocated) In use by the system A console Assigned to JES3
5-66
Instructor Guide
5-67
Instructor Guide
Figure
5-26. Vary Offline Commands (ES271547)
Notes:
5-68
Instructor Guide
Instructor Notes:
Purpose To show and explain examples of the Vary Offline command. Details Entering the Vary device offline command will place the device or range of devices in the offline state provided the device is not currently allocated and not allocation contention exists. The system takes offline any device that is currently in use only after the tasks to which it is allocated terminate. The VARY device,OFFLINE command takes effect when a system task starts. Beginning at MVS 4.3 allocation is invoked when the V dddd, offline command is accepted, thereby reducing but not eliminating the need to enter a START DEALLOC (or account equivalent) to cause a system task to start, allowing the system to take device(s) offline. Transition Statement Next we will look at how to vary devices online.
5-69
Instructor Guide
Figure
5-27. Vary Online Commands (ES271549)
Notes:
5-70
Instructor Guide
Instructor Notes:
Purpose To show and explain the use of Vary Online command. Details Entering the Vary device online command will make the device or range of devices available for allocation provided there is an online path to the devices. Note: The Vary device command will not place a device online if all the paths have been taken offline or no operational paths exist. Transition Statement Next we will look at configure commands.
5-71
Instructor Guide
Figure
5-28. Configure Commands (ES271551)
Notes:
Uses of the CONFIG command to directly reconfigure resources include: CF CHP(cc),ON]OFF CF CHP(cc),ON,NOVARY CF CPU(n),ONOFF To reconfigure one or more CHPIDs, both logically and physically. To reconfigure one or more CHPIDs online but leave this path offline for all the devices. To reconfigure one or more processors, both logically and physically.
5-72
Instructor Guide
Instructor Notes:
Purpose To show and explain the use of configure command. Details The CONFIG command reconfigures (both logically and physically) available processors, vector facilities attached to online processors, real storage ranges, amounts, and elements, extended storage elements, and channel paths. The CONFIG command can be used to reconfigure these resources:

Directly In response to a configuration display With the options in a CONFIGxx member of SYS1.PARMLIB
You can enter the CONFIG command only from a console with master authority. The proper way to reconfigure a CHPID is to issue the MVS CONFIG CHP command. For example: CF CHP(12),ONLINE CF CHP(10-12),OFFLINE
5-73
Instructor Guide
Figure
5-29. Configure Command Examples (ES271553)
Notes:
5-74
Instructor Guide
Instructor Notes:
Purpose More configure commands. Transition Statement Next we will step through a process of how to take an allocated device offline.
5-75
Instructor Guide
Figure
5-30. Taking a Device Offline (ES271555)
Notes:
The V dddd,OFFLINE command will not remove an allocated device. The device can not be taken offline until the allocation is removed. This can be accomplished by:

Waiting until the jobs or subsystems owning the allocation end. Determining what jobs or subsystems have the allocation and take the proper steps to remove the allocation.
5-76
Instructor Guide
Instructor Notes:
Details
An allocated device cannot be varied offline. Before attempting to vary the device offline, check its status: Issue the D U,,ALLOC,ddd,1 command. If the device is not allocated, it can be varied offline issuing the V ddd,OFFLINE command. It may be necessary to S DEALLOC or the account equivalent to get the device to go offline.
When the device is allocated by a subsystem (VTAM), remove the resource from that subsystems use: V NET,INACT,ID=xxxxxx When the device is no longer allocated, it can be varied offline by issuing the V ddd,OFFLINE command.
When the device is allocated by a subsystem (JES2), remove the resource from that subsystems use. For example to remove a printer allocated by JES2: Interrupt the printer: $IPRTnn Stop the printer: $PPRTnn When the device is no longer allocated, it can be varied offline.
When the device is allocated by a subsystem (GRS) remove the resource from that subsystems use: To cause GRS to switch from the active to backup CTC device, it is necessary to quiesce GRS (that is, temporarily suspend this system from the GRS ring), vary the CTC offline, then restart GRS on this system: V GRS(SYx),QUIESCE V ddd,OFFLINE S DEALLOC V GRS(SYx),RESTART
Check that the device was successfully varied offline: D U,,,ddd,1
If the device remains pending, check for enqueue contention.
5-77
Instructor Guide
5-78
Instructor Guide
Checkpoint
Exercise Unit 5 OS/390 MVS Commands

TF 1. The DS P command can be issued to any class of I/O device. Correct Answer 1. False
2.
What command can be issued to determine the status of the first online DASD device? a. b. c. D U,,ONLINE,100,1 D U,DASD,200,8 D U,DASD,ONLINE,0000,1 Correct Answer 2. c
3.
Match the following terms with their correct meanings. a. b. c. d. D M=DEV DS P,dddd D M=CHP D M=DEV(dddd) Provides path, channel and operational path status for any device Provides the number of online paths Performs actual I/O to a tape or DASD device Provides the status of each channel and type of channel.
Correct Answer 3. d, a, b, c
4.
What commands can be issued to determine the paths to a tape device?
5-79
Instructor Guide
Correct Answer 4. DS P,dddd D M=DEV(dddd)
5-80
Instructor Guide
5-81
Instructor Guide
Figure
Notes:
5-82
Instructor Guide
Instructor Notes:
5-83
Instructor Guide
5-84
Instructor Guide
Unit 6. OS/390 Communication Server

This unit introduces the students to the OS/390 Communications Server, the telecommunication access methods it provides, and the various network architectures it supports.


Describe the OS/390 Communications Server as an integral part of the base OS/390 services. List the components of the Communications Server. Explain the Virtual Telecommunications Access Method and its purpose. Outline the concepts behind various kinds of SNA networks, such as APPC, APPN , and APPN/HPR. Give an overview of TCP/IP and its basic components including IP, TCP, UDP, etc. Identify MPTN as a way to connect networks that use different network protocols. Describe benefits of NetView in OS390.

Accountability:
References
GC30-3073-04 Systems Network Architecture Technical Overview SV40-0089-03 Multi-platform APPC Configuration Guide GC31-7073-00 Multiprotocol Transport Networking (MPTN) Architecture: Technical Overview GG24-3376-04 TCP/IP Tutorial and Technical Overview SG24-4170-01 Multiprotocol Transport Networking (MPTN) Architecture: Tutorial and Products Implementations
6-1
Instructor Guide
GG24-4395-00 AnyNet : SNA over TCP/IP Installation and Interoperability GG24-4396-00 AnyNet: Sockets over SNA Netbios over SNA Installation and Interoperability GC31-8226
NetView for OS/390 Planning Guide
6-2
Instructor Guide
6-3
Instructor Guide
Figure
Notes:
6-4
Instructor Guide
Instructor Notes:
Purpose To list the objectives of this unit. Transition Statement Lets take a look at the components that make up OS/390 Communication server.
6-5
Instructor Guide
Figure
6-2. OS/390 Overview (ES271601)
Notes:
Communications Server SNA APPC APPN APPN/HPA TCP/IP
6-6
Instructor Guide
Instructor Notes:
6-7
Instructor Guide
6-8
Instructor Guide
6.1 OS/390 Communication Server

What students will learn The students learn about the OS/390 Communication Server, its components, and the different network architectures it supports. Each architecture is briefly described in terms of structure and components. How this will help students on their job It will help the student to understand the different network architectures and how they can cooperate in a single, logical network.
6-9
Instructor Guide
Figure
6-3. OS/390 Communication Server (ES271602)
Notes:
The OS/390 Communication Server is part of the OS/390 base operating system and provides the networking infrastructure for open, distributed, enterprise-wide computing. The OS/390 Communication Server is composed of the following program products for MVS/ESA:

VTAM V4R3 VTAM AnyNet feature V4R3 IBM TCP/IP for MVS V3R1 Terminal Input Output Controller (TIOC) R1
The Communication Server supports two types of network architectures:

System Network Architecture (SNA) Transmission Control Protocol / Internet Protocol (TCP/IP)
6-10
Instructor Guide
Instructor Notes:
Purpose To explain what the Communication Server is and which products it includes. Details VTAM VTAM is a network communication access method that implements Systems Network Architecture (SNA) and Advanced Peer-to-Peer Networking (APPN). It provides the interface between application programs in a host processor and other resources in an SNA network, and links peer users of the network. VTAM establishes and terminates sessions between users of the network, and forwards session data to and from each session partner. The AnyNet feature implements the multiprotocol transport networking (MPTN) architecture. The AnyNet feature enables application programs to communicate without changes over different transport networks and across interconnected networks. TCP/IP is a set of industry standard protocols and applications that allow users to share data and computing resources with other computers, both IBM and non-IBM. By using TCP/IP commands users can perform tasks and communicate easily with a variety of other systems and workstations. TCP/IP allows users to perform tasks independent of the computer type. UNIX applications use TCP/IP. Some common uses of TCP/IP include:

VTAM AnyNet Feature
TCP/IP
Electronic Mail File Transfer Remote Logon Internet
TIOC
The Terminal Input Output Controller is the TSO component that is the interface between VTAM and the TSO user interface, the Terminal Control Address Space (TCAS). It allows TSO to communicate with the terminal hardware.
Transition Statement VTAM and the TIOC.
6-11
Instructor Guide
Figure
6-4. VTAM and TIOC (ES271603)
Notes:
VTAM The virtual telecommunication access method can be understood as the middleman between application programs and network resources. VTAM for example, can be used to connect 3270 terminals to an OS/390 system. Data transfers between the application and the terminal occur either in record or basic mode. In record mode, the application issues macro instructions to transmit data between the terminal and storage. In basic mode, the application uses macro instructions to transmit messages between the terminal and storage. VTAM is the primary access method used to support SNA and SNA/APPN networks. IT establishes and terminates sessions and handles and monitors all data transfers between the terminal and the MVS system. VTAM AnyNet VTAM AnyNet provides additional functionality over VTAM. It enables SNA applications to run over TCP/IP networks and TCP/IP applications to run over SNA.
6-12
Instructor Guide
Instructor Notes:
Purpose Overview of VTAM to introduce SNA Transition Statement Lets take a closer look at the system network Architecture and what it consists of.
6-13
Instructor Guide
Figure
6-5. Networking Architectures: SNA (ES271605)
Notes:
The Systems Network Architecture (SNA) is a data communication architecture established by IBM to specify common conventions for communication among the wide array of IBM hardware and software data communication products. SNA is a comprehensive specification that describes:

the logical structure of data communication networks protocols (rules) for synchronizing communication between network resources message formats used within a network operational sequences for controlling network resources, network configuration and for transmitting information through the network.
The manner in which products internally implement this common convention can differ from one product to another. But because the external interface of each implementation is compatible, different products can communicate without the need to distinguish among the many possible product implementations. An SNA network is made up of:
6-14
Instructor Guide
Physical Components Physical SNA components (that is, hardware) consist of processors, communication controllers and terminal controllers. These physical components are interconnected by data links: processor channels, telephone lines, microwave links, etc. Software Components SNA software components consist of access methods (for example VTAM), application subsystems (for example CICS and IMS), network control programs (for example NCP) and user application programs.
6-15
Instructor Guide
Instructor Notes:
Purpose To explain the SNA architecture. Details SNA functions are divided into a hierarchical structure that consists of seven well-defined layers. Each layer in the architecture performs a specific set of functions. SNA defines formats and protocols between layers that permit equivalent layers (layers at the same level within the hierarchy) to communicate with one another. Each layer performs services for the next higher layer, requests services from the next lower layer, and communicates with equivalent layers. Hardware and software components implement the functions of the seven architectural layers. Hardware components include:

processors such as the ES/9000 family distributed processors such as the Application System/400 communication controllers such as the 372x and 374x series cluster controllers workstations printers
The software components that implement SNA functions include:

operating systems such as MVS/ESA, OS/400 , OS/2 and AIX. telecommunication access methods such as VTAM and CM/2 application subsystems such as CICS network control programs such as the NCP
Transition Statement Native SNA is a hierarchical architecture.
6-16
Instructor Guide
6-17
Instructor Guide
Figure
6-6. VTAM and SNA (ES271607)
Notes:
The physical components of a data communications network that are interconnected via data links are called SNA nodes. An SNA network has subarea nodes and peripheral nodes. A host processor that contains a telecommunication access method (for example, VTAM) is a subarea node and may be referred to as a host subarea node. The telecommunications access method controls the network, including all resources in all nodes. A communication controller with its Network Control Program (NCP) is a subarea node and may be referred to as a communication controller subarea node. This node, under direction from the host subarea node, controls the links and terminals attached to the node. All other nodes are called peripheral nodes. They range from very simple function devices to broad function devices. A peripheral node could consist of a controller with a single display device, a controller that supports several output devices or a processor.
6-18
Instructor Guide
Major VTAM Functions
Starting and stopping the network- VTAM allows the operator the function of activating the network, or allowing terminals and applications to communicate. An example of a command procedure to start the network could be for example, S VTAM.NET. VTAM once it is started, obtains these network resource definitions and uses them to monitor and control the network. VTAM also allows the network operator to deactivate network resources with the use of commands for example, V NET INACT, ID=XXXX (X meaning the terminal ID). Loading the NCP program into the 37x5 Network Controller - once VTAM is activated, the NCP may be loaded using the following command: V NET,ACT,ID=NCP loadmod name,LOAD=YES,SCOPE=ALL Changing the Network Configuration - VTAM can have devices and paths defined which are not yet physically there. This enables hardware and software to be added later and then activated for general use without interruption of existing components. Allocating Network Resources -When VTAM is active, the terminals path to an application is not critical to the application. Before VTAM, each application had to own the path as well as the terminals that could logon to the application. Sending and Receiving Messages - VTAM handles the flow of data from a terminal to an application, or moving data between applications.
6-19
Instructor Guide
Instructor Notes:
6-20
Instructor Guide
6-21
Instructor Guide
Figure
6-7. Why a Communication Controller? (ES271609)
Notes:
Why a Communications Controller?
WHY is a communications controller needed? To connect those users who are remote from the CPU and its databases. Because the channel cables have length restrictions. To allow information to be shipped over the telephone facilities. To remove work from the CPU.
WHERE is a communications controller needed? One should be channel attached to the host CPU to have access to the data bases on the host computer. There may also be one at the remote site acting as a concentrator. They serve as gateway functions to provide access to the host for LAN connectivity. If two systems, in different parts of the country, are used to back each other up or share information, a Communications Controller on each end is required.
WHAT type of communications controller is needed?
6-22
Instructor Guide
This is the difficult part, IT DEPENDS. How many lines need to be attached? Are LANs required? How many high speed digital facilities are to be attached? Is there a host at the remote site? Is a back up unit needed? Types of Communications Controllers

3705-SNA 3725-SNA 3745-SNA 3172-Gateway for LANs Communications Controllers may also be referred to as Front End Processors (FEP)
Network Control Program (NCP) Four of the five controllers previously mentioned, require a program to be loaded that will control the SNA network.
6-23
Instructor Guide
Instructor Notes:
6-24
Instructor Guide
6-25
Instructor Guide
Figure
6-8. SNA: APPC (ES271611)
Notes:
The SNA architecture provides formats and protocols that define a variety of physical and logical SNA components. One such logical component, called the Logical Unit (LU), is responsible for handling communication between end users and provides each end user with access to the SNA network. SNA defines different types of logical units to meet the different needs of specific end users. LU 6.2 is a type of logical unit that is specifically designed to handle communications between application programs. Advanced Program-to-Program Communication (APPC) is an implementation of the SNA LU 6.2 protocol on a given system and allows interconnected systems to communicate and share the processing of programs. Using LU 6.2, an APPC application running on one of these processors can communicate with a remote APPC application running on another processor, regardless of the type of processor on which the remote application is running.
6-26
Instructor Guide
Instructor Notes:
Purpose To explain APPC. Details APPC provides the ability to connect to every other operating platform in the enterprise. MVS applications can act as servers for application clients implemented in personal systems controlled by DOS, Windows or IBM OS/2, midrange systems controlled by IBMs OS/400, AIX, VM systems and a numerous set of OEM systems that provide APPC connectivity. APPC implements two types of interfaces for program-to-program communication. One is MVS-specific and exploits the MVS unique strengths and another is the SAA defined Common Programming Interface - Communication (CPI-C). The latter is not limited to SNA networks but is supported across many other transports. Examples include TCP/IP, Novells Internetwork Packet Exchange (IPX), and IEEE 802.2 for a wide variety of workstation clients (AIX, DOS, Windows, NetWare and OS/2). All of these clients are able to interface to APPC/MVS. Transition Statement APPC capabilities are enhanced by APPN.
6-27
Instructor Guide
Figure
6-9. SNA - Advanced Peer-to-Peer Networking (ES271613)
Notes:
The Advanced Peer-to-Peer Networking is an extension to the SNA architecture (especially to the APPC concept) and offers enhanced functions suitable for doing client/server and cooperative processing. APPN provides two basic functions:

keeping track of the location of resources in the network selecting the best path to route data between resources.
The APPN extensions allow greater distribution of network control by enhancing the dynamic capabilities of the node. Nodes with these extensions are referred to as APPN nodes, and a network of APPN nodes makes up an APPN network. In an APPN network only LU 6.2 are supported. APPN nodes dynamically exchange information about each other; therefore, users may never have to deal with complicated system and path definitions. APPN nodes limit the information they exchange, enabling more efficient use of network resources.
6-28
Instructor Guide
APPN was designed to make networks where computers of every type can participate on equal terms, as either an application processor/client, End Node (EN), or a router/server Network Node (NN).
6-29
Instructor Guide
Instructor Notes:
Purpose To explain APPN. Details The APPN architecture builds upon the basic SNA peer node definition to provide a dynamic, open and distributed networking environment. APPN enhances the Advanced Program-to-Program Communication (APPC) capabilities by providing new routing capabilities and reducing network definition and updating requirements. APPN networks include three types of computers: Low Entry Networking (LEN) The LEN architecture was the first to allow two non-mainframe SNA nodes to act as peers, with reduced system-definition requirements and improved ease-of-use. End Node (EN) EN nodes provide all the functions of LEN nodes but also use the services offered by APPN networks. For example, when an APPC application is started, the End Node works with the APPN network to find the application partner. NN nodes provide all the functions of an End Node and add two important services. First, network nodes work together to route information from one node to another. The second service is to help LEN and EN nodes to locate partners in the network. By doing this dynamically, very little system definition is required at each node in the network. APPN networks may consist of any number of LEN nodes, APPN End Nodes and APPN Network Nodes. LEN and APPN End Nodes participate only as session destinations or origins, and rely upon adjacent APPN Network Nodes to provide the required networking services. Transition Statement APPN network performance can be increased using APPN/HPR.
Network Node (NN)
6-30
Instructor Guide
6-31
Instructor Guide
Figure
6-10. SNA : APPN/HPR (ES271615)
Notes:
APPN High Performance Routing (APPN/HPR) is a further extension of APPN to take advantage of fast links with low error rates. One of its key benefits is the ability to nondisruptively reroute sessions around failed nodes and links. HPR nodes interoperate with existing APPN nodes permitting an easy and gradual migration. SNA sessions will run over any combination of APPN and HPR nodes. The two main components of HPR are: RTP Rapid Transport Protocol is a connection-oriented transport that exploits the fact that new computers often have large buffer capacities and can send at high speed. It determines the largest packet size supported across an entire route and segments packets exceeding this maximum. RTP provides reliability by byte-sequence-numbering the data, identify missing sequence numbers and selectively retransmitting missing data.
6-32
Instructor Guide
ANR
Automatic Network Routing routes packets on a predetermined path, omitting connection awareness, software overhead and control blocks in intermediate nodes.
6-33
Instructor Guide
Instructor Notes:
Purpose To explain the evolution of APPN networks by means of HPR. Details HPR is an enhancement to APPN that provides improved performance, reliability and availability. Improved performance is manifested as increased throughput and reduced storage and utilization in network components such as communication controllers and network nodes. Throughput improvements result from fast low-level routing at intermediate nodes, referred to as Automatic Network Routing (ANR) nodes. Storage usage is reduced at intermediate nodes by eliminating the need to maintain session awareness. HPR provides end-to-end data recovery and flow/congestion control. End-to-end recovery requires transmitted data to be stored at the sender until acknowledged by the receiver. Nodes performing this function are referred to as Rapid Transport Protocol (RTP) endpoints. Transition Statement Another network architecture available in the OS/390 Communication Server is the TCP/IP network.
6-34
Instructor Guide
6-35
Instructor Guide
Figure
6-11. Networking Architectures: TCP/IP (ES271617)
Notes:
While SNA was evolving in the IBM product line, the Transmission Control Protocol / Internet Protocol (TCP/IP) was evolving in the multivendor environment used primarily by government and research organizations. The TCP/IP protocol suite is named for two of its most important protocols: the Transmission Control Protocol (TCP) and the Internet Protocol (IP). The first design goal of TCP/IP was to build an interconnection of networks that provided universal communication services: an internetwork, or internet. Communication services are provided by software that runs between the physical network and the user applications, independent of the underlying physical network. The second aim is to interconnect different physical networks to form what appears to the user to be one larger network. TCP/IP is a peer-to-peer networking architecture; all systems, regardless of size, appear the same to all other systems in the network.
6-36
Instructor Guide
To be able to interconnect two networks, we need a computer that is attached to both networks and that can forward data from one network to the other; this is called a router.
6-37
Instructor Guide
Instructor Notes:
Purpose To explain TCP/IP and how it differs from the SNA architecture. Details A great difference between SNA and TCP/IP is that TCP/IP is not an IBM proprietary architecture, but a set of protocols and application standards developed and created by an association of users. It was first included in the UNIX system offered by the University of Berkeley and is now delivered with most UNIX systems. The word internet (also internetwork) is simply a contraction of the phrase interconnected network. However when written with a capital I the internet refers to a worldwide set of interconnected networks, so the Internet is an internet but the reverse is not valid. The basic properties of a router are:

from the network standpoint, a router is a normal host from the user standpoint, routers are invisible. The user sees only one large internetwork.
Transition Statement TCP/IP is modeled in layers.
6-38
Instructor Guide
6-39
Instructor Guide
Figure
6-12. TCP/IP: Architectural Layers (ES271619)
Notes:
Although TCP/IP is not an architecture but a set of industry standard protocols and applications, it is modeled in layers. This layered representation leads to the term protocol stack which is synonymous with protocol suite. It can be used for situating, but not for comparing functionally, the TCP/IP protocol suite against others, for example SNA. The Internet protocol is modeled in four layers: Application It is a user process cooperating with another process on the same or a different host. Examples are Telnet or the File Transfer Protocol (FTP). It provides the end-to-end data transfer. Example protocols are TCP (connection-oriented) and User Datagram Protocol (UDP) (connectionless). It provides the virtual network of the internet. Internet Protocol (IP) is the most important protocol in this layer.
Transport
Internetwork
6-40
Instructor Guide
Network Interface
It is the interface to the network hardware. This interface may or may not provide reliable delivery; in fact, TCP/IP does not specify any protocol here. One can use almost any network interface available (token-ring, Ethernet, FDDI, Wireless, SNA, etc).
6-41
Instructor Guide
Instructor Notes:
Purpose To explain the four layers TCP/IP is composed of. Transition Statement To identify a host on the internet, an address is needed, the IP address.
6-42
Instructor Guide
6-43
Instructor Guide
Figure
6-13. TCP/IP: Internet Address (ES271621)
Notes:
To be able to identify a host on the internet, each host is assigned an address, the IP address, or Internet Address. When the host is attached to more than one network, this is called multihomed and the host has one IP address for each network. The IP address has the following format:
IP address = <network number> <host number>

The network number, part of the IP address, is centrally administered by the Internet Network Information Center (InterNIC) and is unique throughout the Internet. IP addresses are 32 bit numbers usually represented in a dotted decimal form as the decimal representation of four 8-bit values concatenated with dots. IP addresses can also be specified in a symbolic format; for example, p_maldini@ac.milan.it. The mapping between the two is done by the Domain Name System (DNS) application protocol.
6-44
Instructor Guide
IP addresses are used by the IP protocol to uniquely identify a host on the internet and to send datagrams (the basic data packets exchanged among hosts) between the source IP address and the destination IP address.
6-45
Instructor Guide
Instructor Notes:
Purpose To explain the structure of an IP address. Details The first bits of the IP address specify how the rest of the address is to be split up into its network and its host part. There are five classes of IP addresses: Class A These addresses use 7 bits (the first bit is always 0) for the network number and the remaining 24 bits for the host number. These addresses use 14 bits (the first two bits are always 10) for the network number and 16 bits for the host number. These addresses use 21 bits (the first three bits are always 110) for the network number and 8 bits for the host number. These addresses are reserved for multicasting, which is used to address groups of hosts in a limited area. These addresses are reserved for future use.
Class B Class C Class D Class E
It is clear that class A addresses will only be assigned to networks with a huge number of hosts and that class C addresses are suitable for networks with a small number of hosts. Transition Statement Datagrams are sent to a process more specific than that identified by the IP address, a port.
6-46
Instructor Guide
6-47
Instructor Guide
Figure
6-14. TCP/IP: Ports and Sockets (ES271623)
Notes:
Applications sending datagrams to a host need to identify a target which is more specific than the IP address, since datagrams are normally directed to certain processes and not to the system as a whole. Each process that wants to communicate with another process identifies itself to the TCP/IP protocol suite by one or more ports. A port is a 16-bit number (0-65535) used by the host-to-host protocol to identify to which higher-level protocol or application program (process) it must deliver incoming messages. As some higher-level programs are themselves protocols, standardized in the TCP/IP protocol layer, such as Telnet and FTP, they use the same port number in all TCP/IP implementations. Each client process is allocated to a port number as long as it needs it by the host it is running on. A higher-level protocol or an application program is uniquely identified, on a specific host, by the following:
transport protocol,ip address,port number
6-48
Instructor Guide
This is called a socket. That is, a socket is an end point that can be named and addressed in a network. A socket interface is one of the several Application Programming Interfaces (APIs) to the communication protocol.
6-49
Instructor Guide
Instructor Notes:
Purpose To explain how processes on different hosts can communicate with each other. Details The port numbers assigned to higher-level programs standardized in the TCP/IP suite (for example, Telnet and FTP) are called well-known ports and the standardized applications well-known services. The well-known ports are controlled and assigned by the Internet Assigned Number Authority (IANA) and occupy port numbers in the range 0 to 1023. The reason for well-known ports is to allow clients to be able to find servers without configuration information. For example, Telnet always occupies port number 23 and FTP port number 21. Confusion due to two different applications trying to use the same port numbers on one host is avoided by making those applications request an available port from TCP/IP. Because this port number is dynamically assigned, it may differ from one invocation of an application to the next. Transition Statement The logical vision of a single virtual network is provided by the Internet Protocol.
6-50
Instructor Guide
6-51
Instructor Guide
Figure
6-15. TCP/IP: Internet Protocol (ES271625)
Notes:
IP addresses are used by the IP protocol to uniquely identify a host on the internet. IP is the protocol that hides the underlying physical network by creating a virtual network view. The internet protocol datagram (IP datagram) is the base transfer packet in the internet protocol suite. It consists of a header containing information for IP and data that is relevant only to the higher level protocols. IP adds no reliability, flow control or error recovery to the underlying network interface protocol. Datagrams may be lost, out of order or even duplicate, and IP will not handle these situations. It is up to higher layers to provide these facilities.
6-52
Instructor Guide
Instructor Notes:
Purpose To explain the Internet Protocol. Details The IP datagram is encapsulated in the underlying networks frame depending on the hardware used. Other protocols exist in the internetwork layer of the TCP/IP suite: ICMP Internet Control Message Protocol is a standard protocol that is used when a router or a destination host must inform the source host about errors in datagram processing. It is an integral part of IP and must be implemented by every IP module. ICMP is used to report occurring errors, not to add reliability to the IP. Address Resolution Protocol is a network specific standard protocol and is responsible for converting the higher level protocol addresses (IP addresses) to physical network addresses. Reverse Address Resolution Protocol is a network specific standard protocol. Some network hosts, such as diskless workstations, do not know their own IP address when they are booted. To determine their own IP address, they use a mechanism where the address of the host is the known parameter and the IP address the queried parameter: this is called RARP.
ARP
RARP
Transition Statement The reliable transmission of datagrams is provided through TCP.
6-53
Instructor Guide
Figure
6-16. TCP/IP: Transmission Control Protocol (ES271627)
Notes:
Transmission Control Protocol (TCP) is a standard protocol that provides considerable facilities for:

error recovery, flow control and reliability.
The primary purpose of TCP is to provide a reliable logical circuit or connection service between pairs of processes. TCP does not expect reliability from the lower-level protocols (such as IP), so TCP must assure this itself. TCP is a peer-to-peer, connection-oriented protocol.
6-54
Instructor Guide
Instructor Notes:
Purpose To explain the role of TCP. Details Two processes communicate via TCP sockets. Each side of a TCP connection has a socket which can be identified by:
<TCP,IP address,port number>.

This is also called half association. It two processes are communicating over TCP, they have a logical connection that is uniquely identifiable by the two sockets involved, that is by the combination:
<TCP, local IP address,local port,remote IP address,remote port>.

User Datagram Protocol (UDP) is another protocol at the same layer level of TCP and is basically an interface to IP. UDP provides a mechanism for one application to send a datagram to another. The UDP layer adds no reliability, flow-control or error recovery to IP. Consequently it has low overheads but it requires the application to take responsibility for error recovery and flow-control. Transition Statement The higher levels of the TCP/IP suite are the applications.
6-55
Instructor Guide
Figure
6-17. TCP/IP: Application Protocols (ES271629)
Notes:
The highest-level protocols are called application protocols. They communicate with applications on other internet hosts and are the user-visible interface to the TCP/IP protocol suite. All of the higher-level protocols have some common characteristics:
they can be user-written applications or applications standardized and shipped with the TCP/IP product. Indeed, the TCP/IP protocol suite includes application protocols such as: Telnet - for interactive terminal access to remote internet hosts FTP (File Transfer Protocol) - for high speed disk to disk transfers SMTP (Simple Mail Transfer Protocol) - as an internet mail system These are the most widely implemented application protocols, but many others exist.
they use either TCP or UDP as a transport mechanism. most of them use the client/server model of interaction.
6-56
Instructor Guide
Instructor Notes:
Purpose To explain the application protocols available in the application layer. Details The following TCP/IP applications are included in the OS/390 Communication Server: Telnet Provides a standardized interface, through which a program on one host may access the resources of another host as though the client were a local terminal connected to the server. File Transfer Protocol provides data transfer from one host to another. Supports MVS data set types and OS/390 Unix directories and files. Simple Mail Transfer Protocol provides the capability of sending electronic mail to internet users on other hosts. Remote Procedure Call allows programs to call subroutines that are executed at a remote system. It is a graphical user interface (GUI) supported by most workstation vendors. It provides authentication and security services to applications in a TCP/IP network environment. Remote Execution Command protocol allows TSO users to execute commands on a remote host and receive the results on their terminal. Domain Name System allows mapping of numeric IP addresses to symbolic names. LPR/LPD Line Printer Daemon supports local and remote printing. Network Computing System is an API to develop distributed applications. It is based on RPC and used by DCE. Simple Network Management Protocol provides the ability to manage distributed networks. Network File System is developed by SUN Microsystems and enables machines to share file systems across a network. It uses RPC and is delivered as part of DFSMS/MVS.
FTP
SMTP RPC XWindows Kerberos REXEC
DNS
NCS SNMP NFS
Transition Statement TCP/IP and SNA networks can be interconnected by means of the MPTN architecture.
6-57
Instructor Guide
Figure
6-18. Networking Architectures: MPTN (ES271631)
Notes:
Multiprotocol Transport Networking (MPTN), developed by IBM, is an open architecture for:
Mixed protocol networking: Applications designed to use a specific network protocol can establish a session over a backbone network, that is, executing a different protocol. Network concatenation: Connecting matching applications across a number of different networks each of them possibly using their own protocol. The connection is achieved via gateways.
Networking protocols generally provide three types of functions:

transport naming and addressing higher-level functions
Transport functions are those that provide the basic facilities for two partners to communicate. Naming and addressing conventions define how entities are
6-58
Instructor Guide
known and how they can be found. The higher-level functions include allocation of the connections to users and control of their use. MPTN separates transport functions from higher-level functions and from the address format as seen by the user of the protocol. Its goal is to allow any higher level protocol using the corresponding address structure to run over any transport function. This is provided by two aspects of MPTN:

the MPTN access node the MPTN gateway
An MPTN access node provides a semantic interface so that higher-level protocols or application interfaces can be transported over another protocol with no apparent change. The MPTN gateway connects different single-protocol transport networks.
6-59
Instructor Guide
Instructor Notes:
Purpose To explain what the MPTN architecture is. Details A Single Protocol Transport Network (SPTN) consists of a group of nodes that are physically connected and implement the same transport protocol. These nodes may be connected by protocol specific gateways, such as IP routers in a TCP/IP network. A Multiprotocol Transport Network (MPTN) is a confederation of SPTNs, each of which has its own transport protocol. The MPTN network appears to its users as a single logical network having the corresponding transport protocol of the user. The IBM products which implement the MPTN architecture are collectively referred to as the AnyNet family of products. With the AnyNet feature of VTAM for MVS, SNA applications can run over TCP/IP and TCP/IP Socketsapplications can run over SNA. With the AnyNet feature SNA emulator, terminal, printer or APPC applications can run across TCP/IP networks. Whats more, Sockets applications run over SNA and APPN LANs. Transition Statement A summary of unit 5.
6-60
Instructor Guide
Checkpoint
Exercise Unit 6 OS/390 Communication Server

TF 1. OS/390 Communication Server is a program product that does not come with the base operating system. Correct Answer 1. False
TF
2.
OS/390 Communication Server supports the network architecture TCP/IP. with the base operating system. Correct Answer
2.
True
TF
3.
VTAM supports the Systems Network Architecture. Correct Answer
3.
True
TF
4.
The SNA LU 6.2 connections can allow communication between application programs running on different host systems. Correct Answer
4.
True
TF
5.
TCP/IP is a specific network architecture with a set standard protocol.
6-61
Instructor Guide
Correct Answer 5. False
Ref: TCP/IP is not an architecture but a set of industry standard protocols modeled in 4 layers.
6-62
Instructor Guide
6-63
Instructor Guide
Figure
Notes:
This unit introduced you to OS/390 Communications Server. We discussed VTAM, TIOC, the different kinds of SNA and TCP/IP Networks as well as their connection through MPTN. Let us now recall the different SNA network architectures, the components of TCP/IP, and the concept of MPTN.
6-64
Instructor Guide
Instructor Notes:
Purpose To summarize the contents of Unit 5.
6-65
Instructor Guide
6-66
Instructor Guide
Unit 7. Netview

This unit describes Base NetView product for OS/390. It introduces and overviews several components within NetView.


Describe the 3 ordering options for NetView The major components within NetView Have a basic understanding of what NetView can provide for your enterprise.

Accountability:

Checkpoint questions Machine exercises
References
SC31-8241 GC31-8226 NetView for OS/390 users guide NetView for OS/390 planning guide

Unit 7. Netview
7-1
Instructor Guide
Figure
Notes:
7-2
Instructor Guide
Instructor Notes:

Unit 7. Netview
7-3
Instructor Guide
Figure
7-2. OS/390 Overview (ES271701)
Notes:
System Management Services
7-4
Instructor Guide
Instructor Notes:

Unit 7. Netview
7-5
Instructor Guide
7-6
Instructor Guide
7.1 Netview

Unit 7. Netview
7-7
Instructor Guide
Figure
7-3. Bringing the Pieces of NetView Together (ES271703)
Notes:
With NetView, one operator can monitor all of your network and system resources from a single display. NetView lets you automate many of your network and systems operations tasks, improving the reliability and effectiveness of the systems and networks throughout your business.
7-8
Instructor Guide
Instructor Notes:
Overvew NetView and discuss some of the bascis components. Introduce some additional option components that may also be added for more specialized functions TME 10 NetView for OS/390 Version 1 Release 1 (NetView) can quickly contain and resolve remote operational emergencies from a single desktop. It can handle enterprise management problems and more. The NetView product is a key component of IBMs network and systems management solutions. Using the NetView licensed program, you can centrally manage the systems and networks in complex distributed environments easily and reliably.

Unit 7. Netview
7-9
Instructor Guide
Figure
7-4. NetView and the Tivoli Management Environment (ES271705)
Notes:
The NetView product is an integral part of IBMs Tivoli Management Environment (TME). The TME environment provides a comprehensive set of tools for maintaining complex, multivendor networks and systems from a single point of control. NetView works with other products in the TME environment. You can use these TME products together to monitor your entire enterprise from a single console to quickly identify and resolve enterprise wide problems.
7-10
Instructor Guide
Instructor Notes:
Introduce NetView and show its relationship to other Netview based such as System Automation, Performance Monitor, Performance Reporter, ect... NetView can help improve your network efficiency, increase system availability, and reduce your overall cost of systems management. With NetView, one operator can monitor all of your network and system resource from a single display. NetView also lets you automate many of your net and systems operations tasks, improving the reliability and effectiveness of the systems and networks throughout your business. Lets see some of the ordering options

Unit 7. Netview
7-11
Instructor Guide
Three Packaging Options

1. Unattended Option
for lights out from a centrally-located staff. Can only be run in conjunction with one or more
instances of Procedural Option or Graphical Enterprise Option 2. Procedural Option

Includes all functions of the unattended Option plus the
automation capabilities include H/W monitor Session monitor Status monitor 3. Graphical Enterprise Option
Includes Unattended and Procedural Option plus supports
graphical displays
Figure 7-5. Three Packaging Options (ES271707T)
Notes:
NetView package different features is currently available in three different options. You chose the NetView that best meets your business needs. Each option package includes a combination of features, and each is priced competitively for the you want.
7-12
Instructor Guide
Instructor Notes:
Purpose To show the different packages options Details This is what is included in the options
Table 7-1 (Page 1 of 2). Benefits of Individual NetView Functions
NetView Function Application programming
Package Available All
Benefit to You Lets you tailor or supplement NetView to satisfy unique requirements or operating procedures. Command procedures can be written in PL/I, C, Assembler, REXX, or NetView CLIST languages. Installation exits can be written in PL/I, C, or Assembler. Provides drop-in automation for VTAM SNA, Token Ring LAN, and TCP/IP resources using NetView AON automation policy Allows repetitive or routine tasks to be performed without operator action Provides a way for you to look at logs, data sets, and files on either a local or remote NetView Provides basic command support for the NetView product; lets you issue VTAM, MVS, and NetView commands from the NetView command line. With the Graphical Enterprise option, the Command Tree facility also allows commands to be issued by pointing and clicking on NGMF menus. Provide a more consistent MVS operation interface, an alternative to the subsystem interface (SSI) Collects and stores data about failed resources in networks; the Procedural and Graphical Enterprise options also offer a full-screen interface Provides online help for messages and commands Provides online help for diagnosing problems Provides an integrated, centralized network management facility that enables you to manage your network resources from a single NGMF workstation Allows easier installation, administration, and maintenance of NetView Displays topology and status information about network and system resources in a graphic format on an OS/2 workstation
Automated Operations Network (AON) Automation Browse facility
Procedural & Graphical Enterprise All Procedural and Graphical Enterprise All
Command facility
Extended MCS consoles Hardware Monitor
All
All
Help facility Help Desk facility MultiSystem Manager
Procedural and Graphical Enterprise Procedural and Graphical Enterprise Graphical Enterprise
NetView Installation and Administration Facility/2 (NIAF/2) NetView Graphic Monitor Facility (NGMF)
All
Graphical Enterprise

Unit 7. Netview
7-13
Instructor Guide
Table
7-1 (Page 2 of 2). Benefits of Individual NetView Functions
NetView Function Program-to-Program Interface (PPI)
Package Available All
Benefit to You Enables user programs to send or receive data buffers from other user programs; also allows system and application programs to send alerts to the Hardware Monitor Permits access to program interfaces that allow NetView to interact with local and remote Information/Management databases in the MVS environment Allows operators to interact with remote SNA systems without the overhead of cross-domain logons. (The receiver can be an unattended system.) Provides a central location for storing, retrieving, and managing operational resource information Collects and stores data about SNA resources in subarea, APPN, and mixed networks; the Procedural and Graphical Enterprise options also offer a full-screen interface Obtains the status and topology information for SNA subarea and SNA APPN resources dynamically, for graphical display using NGMF Collects status information about SNA resources in the network, with the Procedural and Graphical Enterprise options, the status information is displayed full-screen, by domain, in a tabular format Allows MVS operations to send commands to NetView and NetView operators to receive output from commands sent to MVS through the SSI; also lets you monitor MVS operations, since unsolicited messages are sent to NetView through the SSI.
NetView bridge
All
Remote operations
All
Resource Object Data Manager (RODM) Session Monitor
All
All
SNA Topology Manager Status Monitor
Graphical Enterprise
All
Subsystem interface (SSI)
All
Transition Statement Lets take a closer look at some of the basic components.
7-14
Instructor Guide

Unit 7. Netview
7-15
Instructor Guide
Figure
7-6. More on NetView (ES271709)
Notes:
NetView Components
Command facility, status monitor, session monitor, hardware monitor, automation table, service point command service
Operating System Interfaces

MVS, VM, VSE
VTAM Interfaces
API, PPO, SPO, CNM
7-16
Instructor Guide
Instructor Notes:
To Overview the many components of NetView, flexibility of the different operating systems and customization possibilities. You can customize NetView to meet your specific business needs. NGMF views can be customized to add text or geographic backgrounds. You can create customized views of subsets of your network topolog You can also customize colors, add or change icons, and change font sizes and mouse actions. You can customize NGMF command profiles using the Command Profile Editor. You can add automation table statements, modify host and workstation help panels, and create your own help panels. You can extend NetView to include user-written functions. You can, for example, write a command procedure, command list, or command processor. You can write an installation exit routine to view, delete, or replace data flowing in the NetView program. You can set up off-shift processing using the AT and EVERY timer

Unit 7. Netview
7-17
Instructor Guide
Command Facility
AOFPMAIN
SA/MVS - NetView Main Menu OPERATOR ID = MARQUE APPLICATION = CNMA7022 SELECT 1 2 3 4 5 6 7 8
NETVIEW COMMAND BROWSE NCCF HELPDESK TARA NPDA NLDM STATMON AOC DISPFK LOGOFF
DESCRIPTION Browse Facility Command Facility Help Desk Facility 4700 Support Facility Hardware Monitor Session Monitor Status Monitor System Automation for OS/390 PF Key Settings To Exit NetView
Enter a SELECTION NUMBER or COMMAND ==} _ PF1= Help PF2= End PF3= Return PF6= Roll
Figure
7-7. Command Facility (ES271711T)
Notes:
The above example also shows an entry for the option component of NetView SA / OS390
Browse Facility Provides a way for you to look at logs, data sets, and files on either a local or remote NetView Help Desk Facility Provides online help for messages, commands and diagnosing problems Hardware Monitor Collects and stores data about failed resources in networks. Session Monitor Collects and stores data about SNA resources in subarea, APPN, and mixed networks. Status Monitor Collects and stores data about SNA resources in the network.
7-18
Instructor Guide
Instructor Notes:
To show the main menu and to list some of the facilities here New in TME 10 NetView for OS/390 V1R1
The following table lists some of the new functions in TME 10 NetView OS/390 V1R1 and their potential benefits to you. Table 3. What Is New in TME 10 NetView for OS/390 V1R1 Function Description Improved VSAM access Allows direct access to VSAM files from NetView REXX procedures, CLISTs, and PL/I an C/370 programs Resource utilization Allows you to monitor and set limits on your management system resource usage for tasks in the NetVi address space Full-screen Allows a REXX, PL/I, or C program to perform automation any NetView full-screen component function NetView cloning Allows use of one set of definitions to brin up NetView systems on several system images Automatic Restart Decreases the need for operator intervention Manager support to restart NetView after an abnormal termination Session data from Allows NGMF operators to display the NGMF information for a given resource HPR and MNPS support The Session Monitor provides new data for AP High-Performance Routing (HPR) sessions and Multi-Node Persistent Sessions (MNPS) Refreshable span of Lets you define and refresh view names and control resource names to spans of control without recycling NetView; allows you to use a new NetView span table to define NGMF view and resource names to spans of control; supports generic characters (wildcards) in resource a view span definitions Applying span of Allows you to restrict operators access to
Unit 7. Netview
7-19
Instructor Guide
control to NGMF views NGMF views or specific resources within view High-level language Lets you use LE/370 with your HLL command (HLL) support for processors and for graphics support (GMFHS a AD/Cycle RODM) NIAF/2 support Allows new and migrating users to install th NetView program, perform administrative task and maintain a current level of the NetView program Multiple graphical Allows multiple copies of the Graphical NetView releases Enterprise NetView program to run on a singl system Hardware Monitor VSAM Improves the storage performance for Hardwar performance Monitor alerts, allows you to better manage enhancements Hardware Monitor VSAM databases, and increas the wrap count RODM enhancements Requires less storage for RODM objects, improves performance with new locking mechanism, and adds new dump options. GMFHS serviceability Allows sending GMFHS trace output to the generalized trace facility (GTF) SNA Topology Manager Improves availability and serviceability, enhancements reduces the storage requirements, and enhanc the trace function Message and command Now stored as members of a partitioned data help set and displayed by WINDOW; allows easy searching Log browse BLOG, LOCATE, and ALL commands help you enhancements quickly locate and display the log records y want to see Help desk Provides information to assist you in proble improvements determination and other network management functions PIPE enhancements Allows processing of stages with multiple input and output data streams for complex pipelines
7-20
Instructor Guide
REXX enhancements Enables REXX programs to determine the name which they are invoked and to check the security authorization of the NetView operat executing the program Installation exit Allows you to selectively load only the enhancements installation exits you need and to accept or discard session awareness (SAW) records base on their content NGMF enhancements Allows you to perform IMLs for 3174 controllers from NGMF and to decide which operators can mark and suspend resources fro NGMF Date and time Allows you to customize the format used to customization display dates and times in many host NetView functions Integrated The NetView MultiSystem Manager MVS/ESA MultiSystem Manager product has been integrated into NetView and component enhanced to allow better management of netwo nodes. Integrated Automated The Automated Operations Network/MVS (AON/MV Operations Network product has been integrated into NetView and component enhanced to help you better manage network automation. NetView commands from Allows the master console to be switched to MVS master console another terminal without redefining in NetVi Automation of action Allows you to automate on the removal of message deletion (DOM messages resulting from NetView and MVS DOM automation) (Delete Operator Message) signals SSIEXT option for Allows you to use the SSI to deliver enhanced SSI and unsolicited messages and extended MCS consol extended MCS support to invoke MVS commands TAF OPCTL session Allows TSO sessions to run in OPCTL mode, an support of TSO provides samples with pipeline capabilities automation for TSO line-mode commands
Next, lets see what some of these facilities look like

Unit 7. Netview
7-21
Instructor Guide
(Command Facility)
NCCF
N E T V I E W
CNM05 MARQUE
07/08/94 09:47:03
???
Figure
7-8. (Command Facility) (ES271713T)
Notes:
The NetView command facility is the programming and operations base for NetView. Commands, command lists, and command processors are executed through the command facility. This component also handles automation.
Requirement
An installation has a large network with distributed processors and wants to centralize control.
Functions
A NetView operator can enter VTAM, NetView, operating system commands to control both SNA and non-SNA resources. An operator at a central site terminal can receive messages from the host operating system, subsystems, network resources and applications. The command facility provides automation capabilities.
7-22
Instructor Guide
Value

Centralize system and network management Consolidate the operations of many systems in a multiple-host environment Consolidated operations staff can monitor and operate from central site.

Unit 7. Netview
7-23
Instructor Guide
Instructor Notes:
To show the NCCF screen The command facility serves as the primary operator interface for NetView You use it to communicate with other NetView components and programs, VTAM the operating system (including MVS as a system operator), and service points By issuing VTAM and NetView commands in the command facility, you can control and monitor resources and sessions. The command facility also includes network/trace logging and automation facilities. The command facility is often referred to as NCCF. NCCF is actually a command you use to enter the command facility or return to it from another component. It is also a prefix which allows you to enter command facility commands as needed from other NetView components. The command facility controls security for NetView by requiring you to log on using a userid and password that it recognizes. It can limit the types of commands you enter (command security) and the resources you control Next we will look at the status monitor
7-24
Instructor Guide

Unit 7. Netview
7-25
Instructor Guide
Status Monitor
STATMON.BROWSE INACTP NETWORK LOG FOR 07/08/94 (94189) COLS 017 094 17:15 A HOST: HOST5 *1* *2* *3* *4* SCROLL ==> CSR ---2----+----3----+----4----+----5----+----6----+----7----+----8----+----9---CNM05 % 08:41:37 1 IST259I INOP RECEIVED FOR P51J08 CODE = 01 CNM05 % 08:41:37 IST619I ID = P51J08 FAILED - RECOVERY IN PROGRESS CNM05 P% 08:41:37 CNM039I A MESSAGE HAS BEEN LOGGED THAT HAS TURNED ON AN IM CNM05 % 08:41:44 IST621I RECOVERY SUCCESSFUL FOR NETWORK NODE P51J08 CNM05 % 08:41:52 1 IST259I INOP RECEIVED FOR P51K08 CODE = 01 CNM05 % 08:41:52 IST619I ID = P51K08 FAILED - RECOVERY IN PROGRESS CNM05 P% 08:41:52 CNM039I A MESSAGE HAS BEEN LOGGED THAT HAS TURNED ON AN IM CNM05 % 08:42:03 1 IST259I INOP RECEIVED FOR P51L08 CODE = 01 CNM05 % 08:42:03 IST619I ID = P51L08 FAILED - RECOVERY IN PROGRESS CNM05 P% 08:42:03 CNM039I A MESSAGE HAS BEEN LOGGED THAT HAS TURNED ON AN IM CNM05 % 08:42:14 1 IST259I INOP RECEIVED FOR P51M08 CODE = 01 CNM05 % 08:42:14 IST619I ID = P51M08 FAILED - RECOVERY IN PROGRESS CNM05 P% 08:42:14 CNM039I A MESSAGE HAS BEEN LOGGED THAT HAS TURNED ON AN IM CNM05 % 08:42:20 IST621I RECOVERY SUCCESSFUL FOR NETWORK NODE P51K08 CNM05 % 08:42:21 IST621I RECOVERY SUCCESSFUL FOR NETWORK NODE P51L08 CNM05 % 08:42:23 IST621I RECOVERY SUCCESSFUL FOR NETWORK NODE P51M08 CNM05 % 08:49:27 2 IST663I SESSION SETUP REQUEST CDINIT FAILED, SENSE = CNM05 % 08:49:27 IST664I ORIG LU = CNM05LUC SSCP = NCH5 NETID = WSNETC CMD==>
Figure
7-9. Status Monitor (ES271715T)
Notes:
The NetView status monitor collects status information about SNA resources in the network. The status monitor can forward status information to the NetView Graphic Monitor Facility (NGMF).
Requirement
Monitor resources on a single display
Functions
The status monitor summarizes the status of SNA resources for a single NetView domain and displays this information on a single screen. The status monitor automatically reactivates specified failing resources. The status monitor allows an operator to browse the NetView log.
7-26
Instructor Guide
Value

Displays status information to the operators Status monitor can automatically reactivate failing resources to assist operators The log browse function is useful for problem determination

Unit 7. Netview
7-27
Instructor Guide
Instructor Notes:
To show the Status Monitor screen and explain The status monitor collects and summarizes data on the status of resources in a VTAM domain. It also monitors important NetView messages and helps automate error recovery by restarting certain failing resources. You can also browse the network log from it. The status monitor is often referred to as STATMON. STATMON is actually a command you can use to enter the status monitor and display information on nodes. (For more information on the STATMON command, type HELP STATMON on the action line and press ENTER. Then select command and command list help) The data that the status monitor collects is displayed on a series of status summary and status detail screens. The format of these screens is based on a hierarchy of resources, or nodes, in a VTAM domain. Resources lower in the hierarchy, such as single devices or applications defined to VTAM, are called minor nodes and are grouped to form major nodes
Next we will look at Hardware Monitor
7-28
Instructor Guide

Unit 7. Netview
7-29
Instructor Guide
(Hardware Monitor)
N E T V I E W SESSION DOMAIN: CNM05 MARQUE 07/08/94 18:06:40 NPDA-BNIFE119 * RECOMMENDED ACTION FOR SELECTED EVENT * PAGE 1 OF 1 CNM05 NCP51 K5111 +--------+ DOMAIN | COMC |----LINE---+--------+ USER CAUSED - LOCAL MODEM POWER OFF ACTIONS - D001 - CORRECT THEN RETRY INSTALL CAUSED - CABLE ACTIONS - D022 - CHECK PHYSICAL INSTALLATION FAILURE CAUSED - LOCAL MODEM LOCAL MODEM INTERFACE CABLE ACTIONS - D002 - RUN MODEM TESTS D022 - CHECK PHYSICAL INSTALLATION D005 - CONTACT APPROPRIATE SERVICE REPRESENTATIVE
ENTER D TO VIEW DETAIL DISPLAY ??? CMD==>
Figure
7-10. (Hardware Monitor) (ES271717T)
Notes:
The NetView hardware monitor collects and stores information about failed resources in the network.
Requirement
Installations need a facility to monitor hardware resources in the network.
Functions
Information collected includes records generated in the network and forwarded by VTAM to NetView. Alerts from other NetViews are forwarded. System format records for the hardware monitor can be sent from MVS over SVC 76 or from VM over IUCV. In addition to storing data captured from failing resources, the hardware monitor analyzes the data and provides the operator with probable causes for failures and recommended actions.
7-30
Instructor Guide
The hardware monitor data can optionally be written to an external log which can be used to produce reports at a later date.
Value
The alerts dynamic screen continuously updates, displaying a short description and a probable cause, keeping the operator aware of what is going on in the network and operating system. With customization, operators can focus on a subset of the problems. Problem determination can be centralized. Recommended action can assist in problem determination.

Unit 7. Netview
7-31
Instructor Guide
Instructor Notes:
To show and explain the H/W monitor The hardware monitor collects, organizes, and displays data on the physical components of your communication network: communication controllers and links control units, terminals, and other link-attached resources as well as channel-attached resources and the host. These resources send information and error records to the host system. You can use the hardware monitor to display the most recent events and statistics recorded about a network resource. The hardware monitor also analyzes errors data and offers recommended actions. You can use filters to manage data flow and alerts to inform you of high priority problems quickly. You can also record problems directly into the Information/Management system from the hardware monitor. The hardware monitor is often referred to as NPDA. NPDA is actually a command you use to enter the hardware monitor or return to it from another component It is also a prefix which allows you to enter hardware monitor commands as needed from other components. Next we look at the Session Monitor
7-32
Instructor Guide

Unit 7. Netview
7-33
Instructor Guide
(Session Monitor)
NLDM.STIME SESSION RESPONSE TIME BY COLLECTION PERIOD PAGE 1 ------------- PRIMARY -------------+------------ SECONDARY ------------- DOM NAME VAPPL05 SA 00000005 EL 02B5 | NAME L51Q79B SA 00000033 EL 02DD | CNM05 -----------------------------------+-----------------------------------------RESPONSE TIME FROM 08/24 16:15 TO 08/25 11:43 NETID WSNETC CLASS_NAME: DEFAULT | ACT: 86% UNDER 6 SEC | OBJ: 90% UNDER 6 SEC | 71% | | **** V | **** ***************** | **** |----+----+----+----| | **** 0% 25% 50% 75% 100% | **** NUMBER OF TRANS: 1343 | **** 8% 7% 10% LAST TRANS TIME: 0.7 SEC | **** **** **** 4% **** AVG RESP TIME: 2.2 SEC --------------------------------------------------0 - 1 S - 3 S - 6 S - 8 S OVER 8 S CUM % : 71% 79% 86% 90% 100%
100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%
END OF DATA ENTER R TO RETURN TO PREVIOUS DISPLAY - OR COMMAND CMD==>
Figure
7-11. (Session Monitor) (ES271719T)
Notes:
The NetView session monitor collects and stores data about SNA sessions.
Requirement
Installations need a facility that helps identify session activity within the network.
Functions
The session monitor collects session awareness, session trace, session response time, route, network accounting and availability data. The data is stored in virtual memory and at session end is written to a VSAM database. Network accounting, availability data, and response time data can optionally be written to an external log which can be used to produce reports at a later date.
7-34
Instructor Guide
Value
The session monitor provides online information from VTAM about session activation status, session type, and partner names. This includes BIND, INIT failures, and UNBIND sense and reason codes. VTAM PIU data can be displayed for all sessions for which the session monitor collects session trace data. NCP trace data can be displayed for sessions involving NCP-attached resources: boundary function and gateway function trace data. NetView is designed to manage RTM measurements. The session monitor provides online access to response time data for monitoring and problem determination procedures.

Unit 7. Netview
7-35
Instructor Guide
Instructor Notes:
To show and explain the Session Monitor The NetView session monitor collects and correlates data bout System Network Architecture (SNA) sessions and provides access to the data online. Full operator interfaces for session monitor is available only on a central system such as Procedural or Enterprise. The NetView session monitor collects and correlates data about System Network Architecture (SNA) sessions and provides access to the data online. You can use the session monitor to identify network problems and undetected errors. For example, the session monitor collects data on failing terminals, lost path information units (PIUs), buffer errors, and resource status errors. You can view this data by displaying the appropriate session monitor panel or panel sequence. You can move through the hierarchy of panels with PF keys or by following the prompts appearing on the panels. You can also use the NLDM COPY command to create a copy of a panel. The session monitor is often referred to as NLDM. NLDM is actually a command you use to enter the session monitor or return to it from another component. It is also a prefix which allows you to enter session monitor commands as Next we discuss NetViews logging capabilities
7-36
Instructor Guide

Unit 7. Netview
7-37
Instructor Guide
Figure
7-12. NetView Logging Capabilities (ES271721)
Notes:
NetView provides a variety of logging and recording capabilities. The hardware monitor and session monitor each provide their own VSAM databases. In addition, NetView provides a network log, trace log, save/restore database, Resource Object Data Manager (RODM) log, Central Site Control Facility (CSCF) log, external logs, as well as user-provided logs.
Requirement
Installations need to provide an audit trail of events that occurred for tracking or when operational problems occur. Installations can define one or more sequential log tasks to create their own logging schemes.
Functions
The NetView program records messages to a log data set. The NetView BROWSE function can be used to view the log. The NetView program puts session data into a session monitor database and network events and statistics into a hardware monitor database.
7-38
Instructor Guide
Value
The network log records all operator station activity, including commands issued and messages received. You can use the network log to correlate operator console activities with other events in the network. You can use CNM493I to analyze automation use and as an audit trail to determine if your automation is processing as intended. The trace log is a sequence of internal processing. You can use it to identify the source of command facility problems or user errors.

Unit 7. Netview
7-39
Instructor Guide
Instructor Notes:
7-40
Instructor Guide

Unit 7. Netview
7-41
Instructor Guide
Figure
7-13. NetView Automation Facilities (ES271723)
Notes:
NetView allows you to automate many system and network management tasks.
Requirement
Installations have a requirement to reduce the impact of problems and achieve high levels of system availability.
Functions
You can invoke commands at specified times or intervals using NetView timer commands. A new technique for handling messages and commands called NetView Pipelines reduces the complexity of message handling. NetView Pipelines help you to solve a complex problem by dividing it up into a series of smaller simpler steps. Command lists are a series of system and network commands that are grouped under one name. Command lists can be invoked under timer commands as well
7-42
Instructor Guide
as from the automation table. The automation table provides powerful message and management service unit- (MSU-) processing capabilities. Automated operator tasks (autotasks) are used to enhance NetViews automation capabilities. Autotasks can receive messages, execute commands and command lists. In addition to automatically monitoring and processing events and error conditions, the NetView program can also automatically recover from error conditions. The Resource Object Data Manager (RODM) provides a central location for storing, retrieving, and managing the operational resource information needed for network and systems management. It stores configuration data, status information, execution information and other details about resources or classes of resources in an object-oriented structure.
Value
NetView automation capabilities increase productivity by reducing the amount of repetitive routine tasks that operators must perform. Once configuration information is in RODM, automation routines can access the information for such uses as automated diagnosis and fault correlation for multivendor networks. Automation recovery is faster and more accurate than manual recovery procedures. Automation increases availability by implementing a predetermined course of action.

Unit 7. Netview
7-43
Instructor Guide
Instructor Notes:
To discuss some of the basic Automation facilities in NetView The Automated Operations Network (AON) uses NetView automation facilities to automate the recovery of network resources. AON can monitor messages and alerts, then automatically invoke recovery actions. AON also provides an automated help desk to assist with resolving network problems, and generates reports so you can monitor how well your automation is working AON is shipped with default values that enable automation, without lengthy configuration, as soon as AON is installed. You can use the AON/LAN feature operating under the NetView program to extend automation capabilities to token-ring LAN resources such as LAN Network Managers (LNMs), adapters, bridges, segments, and controlled access units (CAUs). The AON/SNA feature extends automation capabilities to SNA networks and systems.
RODM The Resource Object Data Manage (RODM) is an object-oriented data cache Objects in RODM can represent resources in your network. The data cache i located entirely in the memory of the host processor for fast access to data and high transaction rates. Use RODMView to simplify the process of adding, deleting, querying, and changing classes, objects, and fields in RODM. The NetView GMFHS program uses RODM to maintain status information for resources controlled by service points, SNA APPN resources, and relationships between these resources and SNA subarea resources. For instance, you can use the NetView program and NetView MultiSystem Manager MVS/ESA to maintain LAN and client/server data using RODM. The NetView program can then use this information to dynamically build graphical view on a workstation using NGMF. When resource status changes occur in RODM. methods will automatically update views that currently include those resources.
Automation Automating the network and system consists of developing procedures which respond to specific events. Development of an automated procedure require you to understand how to detect the condition to which you want to respond automatically, and what action the automatic response includes. You can then use a combination of the NetView automation table and RODM to correlate events and their automated responses. You have the flexibility of using the automation table and RODM together or each can be used separately. These automated responses can include the invocation of a command list or command processor using an automation task.
Next we take a closer look at the automation table
7-44
Instructor Guide

Unit 7. Netview
7-45
Instructor Guide
Figure
7-14. NetView Automation Table (ES271725)
Notes:
The NetView automation table receives and automates messages and management services units. Through automation table statements you can define actions to be taken when NetView receives certain messages and Management Service Units (MSUs).
Requirement
Installations use extensive automation for systems and network management and require a table with flexibility for maintenance to enable them to respond automatically to messages and MSUs.
Functions
The automation table contains statements that define actions the NetView program should take when it receives specific messages or MSUs.
7-46
Instructor Guide
Value

Promotes proactive management Faster recognition and identification of problems

Unit 7. Netview
7-47
Instructor Guide
Instructor Notes:
To discuss the Automation Table The NetView automation table enables you to examine and separate data, then take actions in response. Its purpose is for:

Processing system, subsystem, application, and network messages Scanning for any errors or indicators of significant events in the network Collecting status information by analyzing messages Examining network management service units (MSUs) for errors or significant events in the network. An MSU is a data structure, such as an alert major vector X0000 contained within a Network management vector transport (NMVT) that carries management services data that the NetView program uses to manage the system or network. Many IBM and non-IBM products send data to the NetView program in the form of MSUs. You can also create your own MSUs. NetView automation processes the following MSU types: Network management vector transports (NMVT), including alerts, resolutions, link configuration data, link events, and problem determination statistics Control point management services units (CP-MSU) Multiple domain support message units (MDS-MU), which usually contains a CP-MSU Record maintenance statistics (RECMS) Record formatted maintenance statistics (RECFMS)
The generic, automation receiver function of the NetView program enables you to send data from your application to the NetView program without having to provide your own receiving application. The data must be in the form of a multiple domain support message unit (MDS-MU). The generic automation receiver presents the received data to the NetView automation table. For more information about the generic automation receiver, refer to the TME 10 NetView for OS/390 Customization Guide. Automation Table and Alerts You can use the SRFILTER and PDFILTER commands to change recording filters. The PDFILTER command is called from a statement in the sample NetView automation table (DSITBL01) when the NetView BNJDSERV task completes initialization. Normally, you set the AREC (alert recording) filters to cause the hardware monitor to send alerts for any high-priority problem records that require immediate attention. The following types of data can become hardware monitor alerts:

Alert major vectors carried to the hardware monitor in MSUs System-format alert records, such as OBR, MCH, CWR, and SLH records received from local MVS or VM devices
7-48
Instructor Guide
Many of the records that the hardware monitor receives go to the automation table during the course of normal processing. There, you can have the automation table change filtering and highlighting attributes or issue automatic responses. Next we discuss NetView Customization Facilities

Unit 7. Netview
7-49
Instructor Guide
Figure
7-15. NetView Customization Facilities (ES271727)
Notes:
To customize NetView functions, you can add your own, or modify the existing NetView program. Customization of the NetView program takes place at various stages of network and system implementation.
Requirement
Installations have a need to add their own function or modify NetView
Functions
There are many ways to modify existing function. Some ways might be by filtering records, reformatting, analyzing, or compressing operator messages. You can extend or customize some of the NetView programs operator presentation functions using the VIEW command or by modifying panels that some components of the NetView program use to present data to operators. There might be devices and applications in your installation that the NetView program does not automatically support. Generic alerts and code points are used to obtain problem determination support for these.
7-50
Instructor Guide
Value
You might need to present new data to operators, change the information that is being presented, or provide another way to request information.

Unit 7. Netview
7-51
Instructor Guide
Instructor Notes:
7-52
Instructor Guide

Unit 7. Netview
7-53
Instructor Guide
Figure
7-16. Centralized Operations (ES271729)
Notes:
You can centralize operations so that you can manage all of your systems, networks and data centers from a single system or a few centralized systems. With automation you may be able to run many of your systems unattended and consolidate your operation staff at a single location.
Requirements
Installations need mechanisms to centralize operations
Function
NetView offers several forwarding options, packaging options, and session options to enhance the control, monitoring and automation capabilities.
Value
7-54
Instructor Guide
A central controlling focal point system can be used to monitor and control multiple systems.

Unit 7. Netview
7-55
Instructor Guide
Instructor Notes:
7-56
Instructor Guide
Checkpoint
Exercise Unit 7 Checkpoint

1. Which operating system is not used for NETVIEW? a. b. c. d. MVS VM VSE DOS Correct Answer 1. d
TF
2.
NetView allows users to centralize operations so data centers can be managed from a central site. Correct Answer
2.
True

Unit 7. Netview
7-57
Instructor Guide
Figure
Notes:
7-58
Instructor Guide
Instructor Notes:
Purpose Details Additional Information
Refer to the TME 10 NetView for OS/390 Library Reference for general information about the NetView library. The Library Reference includes the master glossary, the bibliography, and instructions for reading syntax diagrams.. You can read more about IBM and NetView on Internet home pages. The Uniform Resource Locations (URLs) are:: Home Page TME 10 NetView for OS/390 IBM Networking IBM Tivoli Systems URLL http://www.networking.ibm.com/nmv/nmvi/ http://www.networking.ibm.comm http://www.ibm.com// http://www.tivoli.com//
The TME 10 NetView for OS/390 home page offers demos of NetView and some related products as well as several free NetView applications you can download.

Unit 7. Netview
7-59
Instructor Guide
7-60
Instructor Guide
Unit 8. Introduction to UNIX

This unit provides an overview of the components of a UNIX system.


Describe the UNIX philosophy. Define the components of a UNIX system. Explain some fundamental functions of a UNIX system. Describe the security features of a UNIX system. List some distributed file system solutions for UNIX.

Accountability:
References
SR28-5193 SR23-7481 SR23-7636 SR28-5870 Unix Unleashed Learning the Unix Operating System Unix in a Nutshell Unix Made Easy
8-1
Instructor Guide
Figure
Notes:
8-2
Instructor Guide
Instructor Notes:
8-3
Instructor Guide
Figure
8-2. OS/390 Overview (ES271801)
Notes:
UNIX Services
8-4
Instructor Guide
Instructor Notes:
8-5
Instructor Guide
8-6
Instructor Guide
8.1 UNIX Introduction

What students will do The students will hear an introduction to UNIX. How students will do it This is a lecture topic with checkpoint questions at the end. What students will learn Students with no UNIX background will gain some insight into a UNIX system. How this will help students on their job This will be a good basis for understanding the OpenEdition MVS concepts.
8-7
Instructor Guide
Figure
8-3. UNIX Introduction (ES271802)
Notes:
8-8
Instructor Guide
Instructor Notes:
Purpose Introduce the contents of this topic. Details The intention of this topic is to give a brief overview of UNIX because Posix and XPG4 are based on UNIX. It will be easier to understand the XPG4 functions and the Shell commands after an introduction to UNIX and the UNIX philosophy. It is not the intention to go into too much detail on the UNIX functions because most of them will be covered in more detail later when the OpenEdition XPG4 functions are explained. Additional Information When preparing for this unit, it can be useful to read some UNIX books that can be found in a public library or in a bookstore. If you dont know anything about UNIX, the instructor notes may not be enough to understand this unit. Transition Statement Lets start with the beginning. Where did UNIX begin?
8-9
Instructor Guide
Figure
8-4. UNIX History/Background (ES271803)
Notes:
The UNIX operating system was pioneered by Ken Thompson and Dennis Ritchie at Bell Laboratories in the late 1960s. Ken Thompson and Dennis Ritchie worked on a project called MULTICS (MULTiplexed Information and Computing System) which was cancelled after several working versions of MULTICS did not perform well. MULTICS had some nice features and Ken took parts of MULTICS and implemented it on a PDP-7 machine. Ken, Dennis and some friends wrote the first command interpreter (called shell) and some simple utilities to manipulate files. The PDP-7 machine supported two users at the same time. Somebody referred to the scaled down version of MULTICS on the PDP-7 as UNICS (UNiplexed Information and Computing System), and later UNICS became UNIX.
8-10
Instructor Guide
Instructor Notes:
Purpose Provide an overview of how UNIX started out in a research and development environment. This environment had a major impact on the UNIX system design and philosophy. Details Bell Laboratories is part of AT&T (American Telephone and Telegraph). PDP processors were developed by DEC. Additional Information Refer to books on UNIX if you want more background information on the UNIX history. Transition Statement Lets look at how UNIX evolved over the next 20 years.
8-11
Instructor Guide
Figure
8-5. Evolution of UNIX (ES271805)
Notes:
In 1970, UNIX was ported to a PDP-11/20 machine. This was not a simple task since the system was written in Assembler language. The Bell Laboratories patent office became the first official users of UNIX. In 1973, UNIX was rewritten in C language. At this time there were approximately 25 UNIX systems. A UNIX systems group was established at Bell Labs for internal support. Several universities contacted Bell Labs to get copies of the UNIX system. The fifth edition of UNIX was officially made available to universities for educational purposes. In 1975, the sixth edition was released and AT&T began offering licenses to commercial and government users. By 1977, the number of UNIX systems grew to about 500. The UNIX system was successfully ported to other platforms. Since UNIX was provided in source form and was easy to modify, in many cases, additional function was added and existing function was extended, resulting in several variants of the basic UNIX operating system.
8-12
Instructor Guide
Instructor Notes:
Purpose Show how UNIX developed over the years. This visual can be used to explain why standards organizations started to create standards for UNIX. Details Its not the intent to explain every UNIX variant that is shown on the visual. The idea is to show that UNIX became very popular and, since it was easy to modify UNIX, this resulted in many different versions of UNIX systems. The two most used systems are the UNIX System V from AT&T and the Berkeley system referred to as BSD. Berkeley is a university outside of San Francisco in California, USA. AT&T consisted of multiple communication companies, among them Bell Telephone Laboratories (Bell Labs) and Western Electric Co. (WECo). The US government had an antitrust lawsuit against AT&T which prohibited AT&T from marketing computer software. Although AT&T did not market UNIX, UNIX became very popular in universities which used UNIX for educational purposes. In 1984, the antitrust case against AT&T was settled, and AT&T was split into multiple companies. After this, AT&T was allowed to participate in the computer business, and AT&T Information Systems became responsible for UNIX. Explanations of some of the acronyms on the visual: PWB Programmers Workbench. A group at Bell Labs which supported a version of UNIX for large software development projects. Tried to provide UNIX services to users who were not necessarily interested in research.
MERT Multi Environment Real Time. A version of UNIX supported in the UNIX Support Group (USG) in Bell Labs. BSD Berkeley Software Distribution. Berkeley University modified UNIX by adding virtual storage concept, networking (DARPA internet) support, and automatic kernel configuration.
A UNIX application written for one UNIX platform would not necessarily run on another UNIX platform. This incompatibility has encouraged the work to standardize UNIX. The following standards have been made or recommended:

ANSI/X3.159-1988 Programming Language C Standard 1984/usr/group Standard AT&T UNIX System V Interface Definition (SVID) IEEE POSIX 1003.1 Standard
Additional Information More about standards in the next topic and more about history on the next page. Transition Statement The next visual takes this history up to today.
8-13
Instructor Guide
Figure
8-6. UNIX Today (ES271807)
Notes:
In December, 1992, AT&T sold UNIX System Laboratories to Novell Inc. UNIX System Laboratories Inc. is a wholly-owned subsidiary of Novell Inc. They continue to enhance and market the SVID System V operating system. In October, 1993, Novell agreed to transfer the rights to the UNIX trademark to the non-profit organization X/Open. In 1994, Sun Microsystems bought a lifetime license for Unix from Novell. In September, 1995, Novell announced the sale of its Unix operating system to Santa Cruz Operations Inc. who will continue to improve it in association with Hewlett Packard. This is viewed as a step toward unifying the UNIX marketplace. X/Open has defined a single UNIX specification in its XPG4.2 definition. They have included the POSIX standard along with their own XPG4 base and added the unique features of several other UNIX-style systems and popular applications in this definition. Since X/Open owns the UNIX trademark, platforms that meet these specifications will be able to use UNIX branding in their features.
8-14
Instructor Guide
Instructor Notes:
Purpose Show how UNIX developed over the years. This visual is a continuation of the time line in the previous one to point out to the students where UNIX is today. Details It is important to understand that no vendor can use the name UNIX today unless they meet the specifications included in the single UNIX definition of XPF4.2.The process used to create this specification included POSIX standards, the XPG4 base, Novell System V Interface Definition, and OSF Application Environment Specification (AES) Full Use Interface. Careful analysis of other leading UNIX applications lead to the inclusion of other unique interfaces and APIs. When the specification was complete they analyzed many other applications to determine if there were any missing functions. Most vendors agreed at that time that they could live within this specification. The goal of Single UNIX specification is to bring portability and interoperability to the UNIX market place. Additional Information Transition Statement This was a short overview of the history of UNIX. Let s look at the relationship between UNIX and the C language.
8-15
Instructor Guide
Figure
8-7. UNIX and the C Language (ES271809)
Notes:
The C language was developed by Dennis Ritchie, AT&T Bell Labs in the early 1970s. In 1973, UNIX was rewritten using the C language which made it easy to port UNIX to other machine platforms. During the 1970s C remained closely associated with the UNIX operating system. In the late 1970s the popularity of C grew and C compilers became available for a large number of processors and operating systems. C can be used both as a low-level language and a high-level language. Many of the constructs within C match the way many computers perform the functions. Because of this, object code generation in C can be very efficient. C is used for writing operating systems, compilers, editors, and general purpose programs. The POSIX standard is defined in terms of C language.
8-16
Instructor Guide
Instructor Notes:
Purpose Show that UNIX and the C language are closely related. Details
Details C was developed to make UNIX independent of hardware architecture. When the UNIX kernel and shell were written in C it made programming and debugging easier.
C was developed by programmers for programmers. C compilers were made available for different UNIX versions. In the 1970s, C remained closely associated with UNIX. In the late 1970s, the popularity of C grew and C compilers became available for a large number of processors and operating systems. ANSI (American National Standards Institute) has defined a C language standard in the document ANSI/X3.159-1988 Programming Language C Standard . C has a rich set of functions that deal with all aspects of data manipulation, I/O, math, and character functions. The ability of C to use more traditional high-level constructs gives the programmer elegance and flexibility, while maintaining the options for raw power. C++ is an object-oriented version of C that has become popular with object-oriented design and programming. Additional Information Transition Statement Lets look at the philosophy of UNIX which may explain some reasons for the design of the operating system and why it has become so popular.
8-17
Instructor Guide
Figure
8-8. UNIX Philosophy (ES271811)
Notes:
In addition to being an operating system, UNIX is a philosophy of programming. This philosophy can be expressed by the following:
10% of work solves 90% of problems. UNIX was not designed to solve all problems. Because of this the UNIX system can be simpler than some proprietary systems, and it can be used to solve the majority of problems. Simple solutions. Usually UNIX programs are simple, and the strength of UNIX lies in the possibility to combine existing programs into new programs. Simple tools are easier to understand and use, and may also be more reliable. Independent of machine architecture. UNIX programs use general program functions which do not depend on special features of the operating system or machine architecture.
8-18
Instructor Guide
Instructor Notes:
Purpose Introduce the philosophy of UNIX which can explain some reasons why the system has become so popular and why it is designed the way it is. Details The PDP-11 processor architecture limited a program to 64 Kb in size. This encouraged developing small programs. The small programs could be linked together to build a larger application. This concept is still a basic element in UNIX programming today. Additional Information Transition Statement Lets look at the different components of UNIX.
8-19
Instructor Guide
Figure
8-9. UNIX System Components (ES271813)
Notes:
A UNIX system is usually represented as a set of circles with functions in layers.
The first layer is the kernel which interfaces directly with the hardware. The kernel is the base operating system which provides services for the other layers. Built on the kernel is the command interface which is often called shell, and the commands and utilities. There are a number of different shells available for UNIX systems. The last layer is the application programs which are built on the application programming interfaces, the shell, and the commands and utilities.
8-20
Instructor Guide
Instructor Notes:
Purpose Give an overview of the system components. The kernel and shell and utilities will be explained in more detail on the following pages. Details A UNIX system consists of the kernel and the shell and utilities layer. Applications are built around the UNIX system and represented by the outer layer on the visual. The visual shows a logical picture, and the shell and utilities are required to run an application. The shell and utilities will be used to develop an application or install an application from a vendor. Additional Information Transition Statement Lets look closer at the UNIX shell.
8-21
Instructor Guide
Figure
8-10. Unix Operating System (kernel) (ES271815)
Notes:
The UNIX kernel is the base operating system. Most of the UNIX kernel is written in C language which makes it easy to port to other processors. A small piece of the kernel code is written in Assembler. These are the routines that are dependent on the machine architecture for functions like memory mapping and interrupt handling. The basic functions of the kernel are:

Process scheduling Memory management Device control File management System call interface Operator interface
8-22
Instructor Guide
Instructor Notes:
Purpose Introduce the UNIX kernel and the functions it provides. Details The kernel provides similar functions to those any operating system provides. However, the way it is done may be a little different than, for example, the MVS operating system. The visual shows that the kernel itself logically consists of layers of system functions. The system call interface provides the connection between user processes and the kernel services. In this way a user process can allocate memory, access a file on DASD, or request other system functions. The system calls are assembled and located in libraries. The number of system calls varies depending on the version of the UNIX system. The AT&T System V has over 75 system calls, Berkeley 4.3 BSD has over 150, and POSIX has defined about 100 system calls. The C library provides function calls which call system calls. The C library calls are easier to use for programmers and can be used in high-level language programming. Additional Information Transition Statement Lets take a look at some of the major UNIX functions which can be invoked by system calls to the kernel.
8-23
Instructor Guide
Figure
8-11. UNIX Command Interface (Shell) (ES271817)
Notes:
The command interface in a UNIX system is called the shell. It serves as a command language interpreter, programming language, and allows foreground and background processing. The shell is written in C language and therefore is easy to modify. The three most common shells for UNIX are:
sh: Bourne shell. Developed by Steven Bourne at Bell Labs. It is the most basic shell and is the default UNIX shell. csh: C shell. Written at Berkeley. It has the functionality of the C language and is preferred by many programmers. ksh: Korn shell. Developed by David Korn at Bell Labs. The Korn shell combines the Bourne shell compatibility with the functionality of the C shell.
Using the shell for programming provides features such as variables, control structures, subroutines, and parameter passing. New tools can easily be created by linking together system commands in what is called a shell script or shell procedure.
8-24
Instructor Guide
Instructor Notes:
Purpose Provide an overview of the functions of the UNIX shell. Details The shell got its name because it is the outermost layer of the UNIX system. When you log on to a UNIX system, you start to communicate with the shell. The shell can be compared to TSO in an MVS system. The shell is a program which allows users to communicate with the operating system. The shell reads commands that are entered and interprets them as requests to execute other programs, access files, or provide output. The shell does not have a user-friendly interface. It is driven by commands which can seem very cryptic, but programmers and system programmers like it because of the power it has. Nowadays, vendors provide solutions for UNIX users to replace the shell interface by a window interface or a menu-driven interface which is easier to use for users who are not familiar with UNIX command syntax. Shell scripts can be compared to CLISTs or REXX execs. Additional Information Transition Statement Lets take a brief look at UNIX commands and utilities.
8-25
Instructor Guide
Figure
8-12. Commands and Utilities (ES271819)
Notes:
The UNIX commands and utilities are distributed with the UNIX system. There are over 100 UNIX commands and utilities. A command is a UNIX program that is executed in the shell. Commands are sometimes referred to as tools. For some commands the shell will call other programs called utilities. For the user there is no difference between a command and a utility. UNIX commands have very short names. This dates back from the time when teletypes were in use. UNIX commands are usually very small programs designed to do one simple task. Commands can be combined together in a shell script which then becomes a new powerful command.
8-26
Instructor Guide
Instructor Notes:
Purpose Introduce the concepts of UNIX commands. Details UNIX is very popular among programmers and system programmers because it is so easy to combine commands together into new commands which can solve any problem they might have. The visual shows examples of some UNIX commands. Some of them are similar to DOS commands. Note that the commands are very short. Some command names are abbreviations of the function they perform while others use, for example, the initials of the people who created the command as a name (for example, AWK from Aho, Weinberger, and Kernighan). Additional Information Transition Statement Lets take a closer look at the UNIX kernel.
8-27
Instructor Guide
8-28
Instructor Guide
8.2 OpenEdition Overview
8-29
Instructor Guide
Figure
8-13. Course Contents (ES271821)
Notes:
8-30
Instructor Guide
Instructor Notes:
Purpose Introduce the contents of this course. Details This is a list of the course topics. Each topic will be briefly introduced on the following pages. Additional Information Transition Statement Lets introduce the concepts of open systems.
8-31
Instructor Guide
Figure
8-14. Open Systems (ES271823)
Notes:
In the world of open systems an enterprise using systems that conform to the standard interfaces can exchange or reuse applications, data, and skills on the conforming operating system of any manufacturer.
8-32
Instructor Guide
Instructor Notes:
Purpose Introduce the concept of open systems. Details The visual shows an example of some companies (IBM, DEC, and Sun) that participate in open systems standards. Note that these are not the only companies that support open systems. Customers want the flexibility to enhance their existing applications or install new ones without being constrained to a single system environment. The open world promises the economies of standards: strategic skills and knowledge investment, portability of applications and data in a multivendor network; the ability of users and applications to interoperate among systems from different manufacturers with a single, common interface; and the ability to compare manufacturers offerings more carefully - to distinguish value-added function from standard function. While IBM participates in and supports the work of many standards organizations this does not imply that IBM will implement every standard in every possible product. Support will be provided if the standard meets the needs of IBMs customers. There will be more details on the standards later in this unit. Additional Information Transition Statement Lets introduce OpenEdition and see what opportunities it brings to OS/390.
8-33
Instructor Guide
Figure
8-15. OpenEdition (ES271825)
Notes:
OpenEdition combines the personal power of the workstation, the flexibility of open systems, and the strengths of MVS. Offering new, open interfaces to applications and interactive users, OpenEdition supports an environment of larger operating systems or servers and of distributed systems and workstations that share common interfaces. OpenEdition supports the set of standards being developed by the X/Open Company Limited and known as X/Open Portability Guides (XPG). This includes the Portable Operating System Interface (POSIX). This support offers:

Program portability across multivendor operating systems. A hierarchical file system. Exchangeability between MVS data sets and the UNIX-style byte stream-oriented file system A UNIX-like user interface. Application threads. New commands and capabilities for interacting with TSO/E.
8-34
Instructor Guide
Instructor Notes:
Purpose Introduce the OpenEdition solution. Details OpenEdition is part of IBMs open and distributed strategy for MVS. OpenEdition brings together the open world and the MVS world. Both worlds can exist side by side independently while sharing the same processing and storage resources. Or, users can use each of the two worlds, getting the best of each: a standard interface and portability from the open part of OpenEdition, and a large array of services from the MVS part of OpenEdition. OpenEdition provides an industry standard application programming interface (XPG4 and Posix standard). Application developers and interactive users using the XPG4 interfaces have the underlying resources and power of the MVS system available without needing to understand the proprietary interface of MVS. In addition, these users can exploit the MVS proprietary interface for capabilities not provided by standard interfaces. The strengths of MVS are what differentiate the OpenEdition offering from other open systems solutions. Some advantages are:
The data management functions in DFSMS/MVS provide automatic backup and archiving of Posix files. Several levels of security are provided by MVS together with RACF (or equivalent security product) to control and audit the hierarchical file system access. The MVS environment provides high performance and large capacity DASD which support applications with a large number of files on a single platform.
Users familiar with the standard interfaces can concentrate their work in the environment where they are most comfortable, and the same for users familiar with MVS. For example, application developers can develop most of their applications at their workstations and then use standard XPG4 and Posix interfaces to compile, test and debug their programs at the MVS system. Current MVS applications run as usual. Current users continue to have all the services of MVS available. With OpenEdition the existing investment in MVS applications and data is protected. New applications will have access to existing data. Additional Information Transition Statement What is the definition of open systems?
8-35
Instructor Guide
Figure
8-16. Open Infrastructure Requirements (ES271827)
Notes:
Based on requirements from customers the characteristics of an open systems environment can be expressed by the following:
Portability: Ability to relocate system resources such as applications, data, and people between processing environments of differing design and architecture. Interoperability: Ability to interconnect systems from different vendors, and have them work together to solve a business problem. Investment Protection: Ability to choose components from offerings of many vendors, protocols, and architectures, with the confidence that they will work together.
8-36
Instructor Guide
Instructor Notes:
Purpose Emphasize the basic elements that serve as a foundation for an open system environment. Details Introduce the basic elements in an open system infrastructure. Additional Information Transition Statement How do portability and interoperability define the world of open systems?
8-37
Instructor Guide
Figure
8-17. Open Systems Concept (ES271829)
Notes:
In an open systems environment a set of standards can provide the ability to interoperate and port applications, data, and people on different operating platforms. There are two types of standards, de facto standards and de jure standards. De facto standards are established by broad industry usage of a technology. De jure standards are established and accepted by recognized standards bodies through a formal voting process.
8-38
Instructor Guide
Instructor Notes:
Purpose Provide a summary of the basic elements which make a foundation for an open system, and emphasize the role of standards in this type of environment. Details Use this visual to show that a set of standards can provide portability and interoperability between different systems from different vendors. The vendors on the visual are selected randomly. There are many others that will participate in this picture. Additional Information Transition Statement Lets look more into organizations which work on standards for open systems.
8-39
Instructor Guide
Figure
8-18. Standards Organizations (ES271831)
Notes:
Some standards organizations involved in standards for open systems are:
ISO - International Standards Organization is based on the voluntary activities of national standards organizations in 90 countries and publishes standards for anything that can be manufactured. IEEE - Institute of Electrical and Electronic Engineers develops the Portable Operating Systems Interface (Posix) standard on a request from ISO. OSF - Open Software Foundation is a non-profit research and development organization whose goal is to provide a software solution for an open systems computing environment. Products from OSF include Distributed Computing Environment (DCE), OSF/Motif, and OSF/1. In March 1994, OSF and Unix International (UI) joined forces and now strive to develop portable, interoperable, and scalable technologies. X/Open - an association of vendors devoted to promoting the practical implementation of open systems. Contributions are the X/Open Portability Guide (XPG) which describes a Common Application Environment (CAE) and a branding process, the Federated Naming Service (XFN), and the Common
8-40
Instructor Guide
Operating System API which is also referred to as the Single Unix Specification.
X/Open and OSF merged in 1996 to form the Open Group. The two groups worked closely before the merger to join their two developing standards together.
8-41
Instructor Guide
Instructor Notes:
Purpose Introduce some organizations which participate in developing standards for open systems. Details No one vendor or technology controls the work to create standards. The organizations selected and presented here are the organizations which have defined standards that OpenEdition follows or plans to support in future releases.
ISO - International Standards Organization establishes international standards by convening meetings of delegates from national standards organizations. IEEE - Institute of Electrical and Electronic Engineers. A professional society mainly active in the USA. The computing side of IEEE is active in defining the Posix (Portable Operating System Interface) standards. The Posix work is done under charter from ANSI (American National Standards Institute) on behalf of a request from ISO. The mission is to create a vendor neutral open system. X/Open - an association of vendors devoted to promoting the practical implementation of open systems. IBM is a member as are most major computer manufacturers. X/Open was established in England in 1984 and is quite influential in Europe. X/Opens key contribution to open standards implementations is a portability guide (XPG; usually written as XPG3 or XPG4) which documents a total application platform with a goal of assuring application portability (CAE), and a branding process that certifies that a particular vendors implementation meets the XPG interfaces and protocols. X/Open has announced the XFN and Specification 1170. The XFN specification will allow interoperability among different distributed computing environments such as DCE and ONC+ (Open Network Computing from SunSoft). X/Open Specification 1170 is a draft that defines a single definition of UNIX. It is called Spec 1170 because it contains 1170 specifications.
OSF - Open Software Foundation. A consortium of multiple vendors which deliver open systems products to the market. Established in 1988. IBM is one of the seven original sponsors of OSF. Today there are several hundred members. OSF uses an innovative open process, soliciting technologies from the computer industry. It then selects the best of these, integrates and packages them, and delivers this technology to the industry in source code form. They produced OSF1, OSF/MOTIF, and DCE in this way. OSF/1 is a UNIX operating system. AIX/ESA is based on OSF/1. OSF/Motif is a graphical user interface based on X Windows. On March 23, 1994, OSF and UI merged. Two important members of UI were AT&T and Sun. With the new organization, all major vendors in the computer industry are working together. In 1996, OSF merged with X/Open to form the Open Group. As part of this organization it will no longer produce code, but will manage specific projects as vendors produce products to their specifications. OSF will then license the resulting product.
8-42
Instructor Guide
Additional Information Transition Statement We have mentioned some standards. Lets look more into the Posix standard on which OpenEdition is based.
8-43
Instructor Guide
Figure
8-19. Posix Standards (ES271833)
Notes:
The work on Portable Operating Systems Interface (Posix) started out as an effort to standardize UNIX and was performed by a work group under IEEE (Institute of Electrical and Electronic Engineers). What they defined was an application programming interface which could be applied not only to UNIX systems but to other operating systems, like MVS. Posix is now a set of standards that define common interfaces across operating systems. Most of the interfaces are defined in terms of C language. The Posix standard is sponsored by ISO (International Standards Organization) and is incorporated into the X/Open Portability Guides. Each element of the standard is defined by a 1003.* number. The OpenEdition supports:

Posix Posix Posix Posix
1003.1 - System Application Program Interface (API) 1003.1a - System API Extensions 1003.1c - Threads Extensions (previously called 1003.4a) 1003.2 - Shell and Utilities
8-44
Instructor Guide
Instructor Notes:
Purpose Give an overview of what Posix is. Details It is not the intention to go through the list of the Posix standards here. The list is shown to demonstrate that Posix is a set of standards and some of them will be included in OpenEdition which was announced in February, 1993. In the future more of these standards may be included in MVS. Only some of the Posix standards are approved by ISO up to now. The others are in the working groups and the list of Posix standards is growing. To many people open means UNIX. Although Posix evolved from UNIX, it is not the same as UNIX. Posix defines the interfaces and not the solution or implementation. In this way Posix can be supported by any operating system. Implementation of Posix can be different in areas such as performance, availability, recoverability, etc. All Posix-compliant systems are not the same although they all support the same core interface. The support for open systems in MVS is based on the Posix standard. Posix is actually a part or a subset of the XPG standard defined by X/Open. Additional Information Transition Statement We have defined Posix and mentioned XPG. Lets look at XPG on the next visual.
8-45
Instructor Guide
Figure
8-20. X/Open Portability Guide (XPG) (ES271835)
Notes:
X/Open is dedicated to developing an open, multivendor Common Applications Environment (CAE). Specification of the CAE is published in the X/Open Portability Guide (XPG) whose latest versions are referred to as XPG4 and XPG4.2. The CAE is an open systems environment specification based upon both formal and de facto standards. The intent is to provide application portability and interoperability while allowing movement of users between systems without re-training. The foundation of CAE lies in the specification of the C language, in the Posix (1003.1 and 1003.2) standard, and AT&T System V Interface Definition (SVID). The X/Open Specification 1170 (single UNIX specification) will enable development of different implementations of the operating system conforming to the single UNIX specification. Specification 1170 contains two types of interfaces. The first is those interfaces is included for historical reasons. The second category includes strategically important functional extensions. Part of this category are extensions to three existing X/Open specifications: Commands and Utilities, System Interfaces and Headers, and System Interface Definitions. Some
8-46
Instructor Guide
new interfaces being developed are the Sockets networking Application Programming Interfaces (XSOCKETS), and Internationalized Terminal Interfaces (XCURSES).
8-47
Instructor Guide
Instructor Notes:
Purpose Provide an overview of X/Opens contributions to open system standards. The intention is to show the elements that are part of CAE, but not to go into detail on each element. Details The visual shows the X/Open CAE with its different components. XPG4 describes the interfaces between the components of CAE. Each of the components is broken down into further detail until at the lowest level there is some standard or specification that is required to provide the function. CAE builds on existing standards, for example Posix 1003.1. The foundation of CAE is a standard Base Computing Platform defined by XPG4 internationalized system calls and libraries, commands and utilities, and the C language. The portability guide documents a total application platform with a goal of assuring application portability. It also describes a branding process that certifies that a particular vendors implementation meets the XPG interfaces and protocols. The CAE defines interfaces within a single system. The new Spec 1170 can be looked upon as an extension to what is defined in XPG4 and provides interface definitions for communication between systems (XSOCKETS and XCURSES). By also maintaining interfaces for historical reasons (will be supported for a least five years), Spec 1170 provides a bridge between past versions of UNIX and future ones, and also compatibility with existing applications. The Posix standard was based on UNIX systems; the Spec 1170 was developed by analyzing the interfaces and behavior of the most commonly used UNIX applications. It is anticipated that Spec 1170 will become accepted industry standards by 3Q94. Check the XOPEN forum on the IBMUNIX disk for news about XPG4 and Spec 1170. In Europe, the trend seems to be that EU (European Union) will support XPG as the standard for an open system. Also some US companies require systems to be XPG-compliant. OS/390 was fully branded as XPG4.2-compliant in 1996. Additional Information Transition Statement MVS supports both the POSIX and X/Open standards. Lets see how they relate to one another.
8-48
Instructor Guide
8-49
Instructor Guide
Figure
8-21. UNIX Application Interfaces in OS/390 (ES271837)
Notes:
OpenEdition as implemented originally in MVS/ESA SP V4.3 supported the POSIX standards (1003.1, 1003.1a, 1003.1c, and 1003.2) with approximately 300 functions. Many additional functions were added in MVS/ESA SP V5.2.2 to meet the XPG4 requirements. In MVS/ESA SP 5.2.2 the number of functions included in the OpenEdition implementation is now more than 1100. This now incorporates the full X/Open Portability Guide issue 4 (XPG4) and over 90% of the Single UNIX Specification as defined in XPG4.2. The remaining functions will be added in a subsequent release and OpenEdition will be branded as a UNIX system. OS/390 was awarded full UNIX 95 branding by the X/Open Group in 1996.
8-50
Instructor Guide
Instructor Notes:
Purpose Show the relationship between the major open standards and how OpenEdition supports them. Details Over the last five years, multiple standards organizations have been involved in tasks to standardize UNIX and provide a set of open systems interface specifications. Many of these organizations now cooperate and many vendors fully support their efforts to create a common UNIX-based set of application programming interfaces. MVS started out to be a POSIX-compliant system. This support has been extended to support the X/Open definitions of XPG4 and XPG4.2. The advantage of this goal is the portability of programs developed to these standards and the sharing of development skills across heterogeneous platforms. Also included in the XPG4.2 package are the protocols and methods for communicating between programs on different platforms. This then addresses both the issues of portability and interoperability which we defined earlier in this topic as the requirements of open systems. The XPG4.2 support includes all commands and utilities, most of the additional C services defined in the standard, and curses which were included in the specification 1170 but not in the XPG4.2 spec. Curses is the UNIX multicolor, multilanguage screen control package which comes from the NOVELL SVID Edition 3 package. The following items have been added in OS/390: STREAMS, X/Open Transport Interface(XTI), XPG4.2 regular expressions, XPG 4.2 context switching, and XPG4.2 behavior specific to sockets. Full UNIX branding was received in 1996. Additional Information Transition Statement DCE is supported in these standards so lets take a brief look at it.
8-51
Instructor Guide
Figure
8-22. DCE Architecture (ES271839)
Notes:
OSFs Distributed Computing Environment (DCE) is a comprehensive, integrated set of services and technologies that support the development, use and maintenance of distributed applications. OSF/DCE offerings are organized in the following categories:
Fundamental Distributed Services: Remote Procedure Call Directory Service Time Service Security Service Threads Service
Data Sharing Services: Distributed File Service Diskless Support Service
The management block is not a single component, but a cross section of the other components. Each DCE service contains an administrative component so it can be managed over the network.
8-52
Instructor Guide
Instructor Notes:
Purpose Introduce OSF/DCE. Details General overview of OSF/DCE. OSFs DCE is one of the industry solutions for distributed computing in a heterogeneous network. The support for DCE on MVS is called OpenEdition DCE. Fundamental Distributed Services provides tools for software developers to create the end-user services needed for distributed computing. Data Sharing Services provide end users with capabilities built on the fundamental distributed services. These services require no programming on the part of the end user and facilitate better use of information. OSF has dropped diskless support. The local file systems of the diskless client have to be accessed in the traditional way, via NFS. Once the client has booted properly, It can run as a normal client. The new OSF organization has announced that it will continue to support DCE as today through the next release, which for DCE is 1.2. After that, the OSF technologies will transition to a new PST (Pre-Selected Technology) process where project sponsors take the initiative in proposing new technologies and enhancements to existing technologies. A similar solution to DCE is ONC+ from SunSoft. With the new Federated naming Service (XFN) standard proposed by X/Open and funded by major vendors, interoperability between DCE and ONC+ will be provided. Some of the sponsors of XFN are DEC, HP, IBM, OSF, and Sun Microsystems. The RPC used in ONC+ and the RPC used in OSF are not compatible. XFN will provide the interoperability between the different naming systems used in the two solutions. Additional Information Transition Statement We have looked at requirements for open systems, and some of the open systems standards organizations and their contributions to standards. Lets now see what we can do with OpenEdition as it implements these standards.
8-53
Instructor Guide
Figure
8-23. Port Applications to MVS/ESA (ES271841)
Notes:
With OpenEdition, UNIX-based applications which conform to the Posix and XPG4 standards, can be ported to MVS/ESA. These can be applications provided by vendors or developed in house at workstations. Some of the advantages of porting an application to MVS/ESA are:
Access to a larger number of users than traditionally on a local area network (LAN). Shared applications. Large data storage capabilities. Access to high-speed printers High reliability Large batch jobs. Applications can take advantage of MVS/ESA services.
8-54
Instructor Guide
Instructor Notes:
Purpose Show that one possible way to use OpenEdition is to port UNIX-like applications to MVS/ESA. Details With OpenEdition, the role of an MVS/ESA system changes from being a proprietary system to be a system which can participate in an open environment. This opens up for new opportunities for MVS/ESA. A workstation in this context is a workstation with a UNIX-like operating system using UNIX applications. The visual shows that UNIX applications which follow the Posix or XPG4 standards can be ported to MVS/ESA from vendor applications or from in-house applications developed on a workstation to take advantage of the strengths of MVS/ESA. To be realistic, this does not mean that all UNIX-like applications are suitable for porting to MVS/ESA. Applications which would benefit from the services that MVS/ESA can provide are the best candidates. The list of MVS/ESA capabilities that can be an advantage for UNIX applications is included in the student notes. If a UNIX application is modified to take advantage of MVS/ESA functions, for example access MVS/ESA data bases, or use a data space for temporary storage and manipulation of data, this application will not be portable to other Posix/XPG conforming platforms. Depending on the needs, the advantages of the additional services may outweigh the reduced portability of the application. Without OpenEdition, UNIX-like applications are somewhat portable to MVS/ESA because MVS supports standard application interfaces such as ANSI C, TCP/IP (including X Windows and Motif), and SQL (Structured Query Language). With the support for the Posix, XPG4 and XPG4.2 standards, OpenEdition makes porting of existing UNIX applications easier and more cost-effective. The MVS/ESA Software Product Directory provides a list of independent vendors which intend to provide applications that support OpenEdition. Additional Information Transition Statement Lets see how workstation users can get access to MVS/ESA applications and data.
8-55
Instructor Guide
Figure
8-24. Access to Applications and Data (ES271843)
Notes:
With OpenEdition, workstation users can get access to traditional MVS applications and data as well as to the Posix and XPG4/4.2 conforming applications and data on MVS/ESA. Users connected through TCP/IP with X Windows installed can interact with traditional MVS applications and XPG applications using the Motif graphical user interface. The application on the workstation must be written or modified to provide X Windows server request function.
8-56
Instructor Guide
Instructor Notes:
Purpose Show that MVS applications and data can be made available to workstation users. Details The visual shows that a workstation application using Motif and X Windows can access data on an MVS/ESA system. This visual is very simplified and provides a conceptual overview of the solution. The investment in MVS/ESA applications and data is protected by providing access to them from new users on UNIX workstations. X windows is one of the most widely-used Graphical User Interfaces (GUI), or window-based display systems. It is supported by all major workstation vendors. X Windows is a TCP/IP application and comes as part of the TCP/IP product for MVS. MVS/ESA applications can only be X Windows clients, a workstation can be an X Windows server or a client. IBM workstations that can be X Windows servers are:

AIX/PS2 AIX/6000 V3 OS/2
X Windows provides a very basic graphical support, and the application programming interface is a very low-level interface. OSF/Motif is a GUI interface which provides a common interface for any application that wants to provide graphical displays. Motif is an application which runs on top of an X Windows server. The advantage of using Motif is that this interface is easier to use and it is a macro level above X Windows. AIX/PS2 and AIX/6000 supports Motif; OS/2 does not support Motif. To use X Windows and Motif, the applications on MVS/ESA must be modified to use the X Windows client code. An exception is if the MVS application uses GDDM to create graphical displays on 3270-type terminals. In this case, the IBM-supplied feature to TCP/IP called GDDMXD can be used to transfer the GDDM output to an X Windows server without any modifications in the application. Workstations connected to the server can display the graphics using X Windows or Motif. The box on the visual that contains the X Windows client, symbolizes the X Windows API on MVS. The X Windows clients are really each of the applications using X Windows. The client code is compiled together with the application program. Additional Information Transition Statement Lets see how high-speed storage devices on MVS/ESA can be useful for workstations.
8-57
Instructor Guide
Figure
8-25. High-Speed Storage Device Access (ES271845)
Notes:
Using OpenEdition, Posix and XPG4-conforming applications can access large databases on high-speed and high-capacity DASD or tape devices. Although the data is in the form of MVS data sets, an application can use the ANSI C standard functions fopen(), fclose(), fread(), and fwrite() to access the data. Suitable applications are data-intensive applications, for example, scientific and financial analysis. Such an application on a workstation might be a candidate for porting to MVS/ESA. Data stored in UNIX-style format can be exchanged between MVS/ESA and other UNIX systems using utilities commonly used in those systems to archive data.
8-58
Instructor Guide
Instructor Notes:
Purpose Show that a data-intensive workstation application may be a candidate for being ported to MVS/ESA. Details One of the strengths of MVS/ESA is the access to high-speed and high-capacity DASD and tape devices. Data-intensive applications like seismic analysis, weather information analysis, demographic information analysis and prediction, and financial business analysis can benefit from these high-speed I/O devices. The visual shows that a data-intensive application on a workstation can be a good candidate for porting to an MVS/ESA system with OpenEdition. OpenEdition provides utilities generally used in a UNIX environment for archiving data. This makes it easy to exchange data between standards-conforming systems. The file system unit will have more information about these utilities. Additional Information Transition Statement Lets see what data management facilities an MVS/ESA system can provide.
8-59
Instructor Guide
Figure
8-26. Data Administration (ES271847)
Notes:
MVS/ESA and DFSMS/MVS provides automatic backup and archiving of UNIX-style file systems stored on the MVS/ESA system. A file system can easily be restored from the backup or archive. A workstation application might be considered to be moved to MVS/ESA if backup is critical. An alternative solution is to use the ADSTAR Distributed Storage Management product on MVS/ESA which can periodically upload data on the workstation and archive it on the host.
8-60
Instructor Guide
Instructor Notes:
Purpose Show how the data management facilities of MVS/ESA can be an advantage for workstation users. Details The DFSMS/MVS product on MVS/ESA provides data administration functions like backup and archiving of data on an MVS/ESA system. With OpenEdition, DFSMS/MVS can be used to back up and archive the hierarchical file system. Note that the initial support only provides backup and archiving of entire file systems, not individual files. There will be more explanation on this in the file system unit. An alternative to moving a backup critical application from a workstation to MVS/ESA, is to use ADSTAR Distributed Storage Manager to upload files from a workstation to MVS/ESA and archive them on MVS/ESA. This is now supported by the new ADSTAR Distributed Storage Manager OpenEdition client for users attached directly to the MVS system and using the OpenEdition services. Additional Information Transition Statement Lets see how MVS can be used a server for batch applications.
8-61
Instructor Guide
Figure
8-27. Server for Batch Applications (ES271849)
Notes:
With OpenEdition, Posix and XPG4, applications and workstation users can have access to a large processor capacity for running batch jobs, and to high-speed printers. Large batch applications running on a workstation can be moved to MVS/ESA to improve turn around time and to have access to high-speed printers. OpenEdition shell scripts can run as an MVS batch job as well as in the foreground. If Network Queueing Service/MVS (NQS/MVS) is installed, workstation users can have a familiar NQS user interface to MVS batch services.
8-62
Instructor Guide
Instructor Notes:
Purpose Show how MVS can be used as a server for batch applications. Details MVS/ESA is very well suited to be a server for batch applications because of its large processing capacity, high-speed printers, and high reliability and availability. Large batch applications can be moved from a workstation to MVS/ESA, or the workstation can use NQS/MVS to submit a batch job that will run on the MVS/ESA system. NQS/MVS is already available on MVS, and it provides users connected through TCP/IP a way to send batch requests to MVS/ESA. NQS/MVS acts as a mediator between the NQS protocol and MVS/ESA JES2 services. The NQS protocol is a popular method in a UNIX environment for submitting batch requests from a workstation to a remote UNIX system over a TCP/IP network. The NQS protocol is the basis for the proposed Posix standard for batch system administration. A workstation user which has TCP/IP and a 3270 emulator connection to OpenEdition, can have both the advantages of using a familiar NQS interface through TCP/IP, or log on to MVS/ESA and have access to MVS services, for example SDSF (Syslog Display and Search Facility). With SDSF, the user can check the status of the batch job. OpenEdition shell scripts which are similar to REXX execs can run in the shell session, or they can be submitted as an MVS batch job. More details on shell scripts in the shell and utilities unit. Additional Information Transition Statement We have reviewed some of the opportunities and some of the new ways to use MVS/ESA with OpenEdition. Lets look at two exploiters of these facilities.
8-63
Instructor Guide
Figure
8-28. OS/390 Internet Gateway (ES271851)
Notes:
The Internet Connection Server and the Internet Connection Secure Server along with the OS/390 Bonus Pack provide a WebServer environment for OS/390. This server is a standard compliant product which requires OpenEdition and its file system. It uses the POSIX threading standard enabling one server to handle multiple client requests. The home pages that you store on OS/390 reside in the hierarchical file system. There are also services and samples provided to show access from a Web Browser through the ICS or ICSS to CICS and DB2 data. This is a way to bring your older transaction processing applications to new users through the Internet.
8-64
Instructor Guide
Instructor Notes:
Purpose Show an example of new users of these facilities. Details It is not intended that you teach all about the ICS or ICSS--only to show it as an exploiter or product that requires OpenEdition services. You will probably have students who know about this, have implemented this already, or are very curious as this will be their first application. Do not let them get you off track here. This is not a class in the ICS. Additional Information Transition Statement DCE is another package of services that depends on the open standards and OpenEdition.
8-65
Instructor Guide
Figure
8-29. Distributed Computing Environment (ES271853)
Notes:
The Distributed Computing Environment (DCE) is a package of services to simplify the development and execution of applications distributed over many heterogeneous platforms. In a distributed computing environment users do not see or know that they are accessing multiple systems, nor do they need to know addressing information about the resources they use. The users see only a single interface, whether the function is running locally or remote. The services consist of the Remote Procedure Call support to link applications together, and the distributed services of directory, security, time, and a distributed file system. The distributed file system allows hierarchical data resident on any of the platforms to be viewed by the user as one large file system. Services to distribute the data, replicate the data, and back up the data are also included. DCE is a package you would install on all platforms that need to communicate and share data. The applications would be written using DCE services. Then you
8-66
Instructor Guide
can decide which platform to run any piece of the application at a later time and can move the pieces around as requirements change. OS/390 with release 4 will support all of the DCE services except the global directory server. Another machine in the DCE environment can provide the gateway service to either Domain Name Services or X.500 global directory of OSI. This package requires that OpenEdition services be active on the OS/390 platform as it was written using the POSIX and XPG standards. The combination of OpenEdition services and DCE support will allow an OS/390 system to provide an extensive set of services for client/server applications.
8-67
Instructor Guide
Instructor Notes:
Purpose Show DCE as an exploiter of the standards and OpenEdition s implementation of them. Details Dont get too involved in the details of DCE. This is not to be covered in this class. It is included here only as an example of an exploiter of these services. You might ask the students what products they are interested in using that need OpenEdition services. OpenEdition DCE was announced together with MVS/ESA 5.1 in April 1994. The distributed file system on MVS was announced in September, 1995. X/Open and OSF have announced a joint project to integrate the OSF DCE specifications into X/Opens common application environment. The DCE services also play a major role in IBMs Open Blueprint providing the distributed services. The visual shows a conceptual overview of what DCE will look like on an MVS/ESA system. There is the basic MVS/ESA operating system with the OpenEdition services. On top of that is the distributed computing environment, which provides a set of programming interfaces including RPC, directory, timer, and security services. On top of this are the applications which do the work of providing services to distributed clients. Although the visual shows a workstation as a client, the client could also be another MVS/ESA system. Since RPC is quite essential in the DCE solution, here is a RPC. RPC is a request from a local calling program to use in a separate program located anywhere in the network. A remote procedures and calls in a manner similar to coding calls. Typical RPC applications include:

general description of a procedure located programmer codes local procedures and
Accessing files stored on a centralized server. Requesting data from and writing data to a centralized database server. Requesting one or more remote processors to process data, and to provide the results for display at a workstation.
Additional Information Transition Statement Now lets talk about the OpenEdition services themselves.
8-68
Instructor Guide
8-69
Instructor Guide
Figure
8-30. OpenEdition Components (ES271855)
Notes:
OpenEdition consists of:
A system Application Programming Interface (API) The system API is a set of C language function calls as well as the operating system interfaces to support them. Some services are also accessible through Assembler language.
Shell and Utilities This is the interactive interface to OpenEdition services.
A hierarchical file system The hierarchical file system will be supplied by DFSMS/MVS. This is a byte-oriented file system familiar to UNIX programmers.
A dbx debugger The OpenEdition dbx debugger is an interactive tool for debugging C language applications that use OpenEdition services.
8-70
Instructor Guide
Instructor Notes:
Purpose Use this visual to introduce the OpenEdition components. Details The intention is to use this as a high-level overview. There will be more details on each component later in this course. The OpenEdition offering consists of the following pieces:

OpenEdition support feature and the application services feature (unpriced) OpenEdition Shell and Utilities feature (priced) OpenEdition Debugger feature (priced)
OpenEdition requires MVS/ESA SP 4.3 or higher. The hierarchical file system is shipped as part of DFSMS/MVS. There are more details on product requisites in the planning for installation unit. The Posix and XPG4 standards introduce a completely new terminology in the MVS environment. A typical UNIX operating system consists of a kernel which interfaces directly with the hardware. Built on the kernel is the shells and utilities layer that defines a command interface. Then there are application programs built on the shells and utilities. The OpenEdition API conforms to the Posix and XPG4/4.2 standard. To support the API, the MVS system must provide some system services which are included in the kernel, the file system, and communication services. The C/MVS compiler and LE/MVS (Language Environment for MVS) library are changed and extended to allow the use of kernel services through the C programming language. The LE/MVS product provides a common run-time environment and language specific run-time services for compiled programs. The Shell and Utilities component can be compared to the TSO function in MVS. The dbx debugger is not part of the Posix standard. It is based on the dbx debugger that is well known in many UNIX environments. Additional Information Transition Statement Lets introduce the Posix standard which is supported by OpenEdition.
8-71
Instructor Guide
Figure
8-31. XPG4/XPG4.2 Functions in OpenEdition (ES271857)
Notes:
The work on Portable Operating Systems Interface (Posix) started out as an effort to standardize UNIX and was performed by a work group under IEEE (Institute of Electrical and Electronic Engineers). What they defined was an application programming interface which could be applied not only to UNIX systems but to other operating systems, like MVS. Posix is now a set of standards that define common interfaces across operating systems. Most of the interfaces are defined in terms of the C language. The Posix standard is sponsored by ISO (International Standards Organization). The Posix standards have been included in a larger definition of a computing platform defined by the X/Open Company and called X/Open Portability Guide, issue 4 (XPG4). The XPG4.2 level specification is an effort to bring the fractured UNIX system marketplace together into one standard UNIX definition. This is often referred to as Universal UNIX or Single UNIX specification.
8-72
Instructor Guide
Instructor Notes:
Purpose Introduce the Posix standard. Details Posix is a set of standards. A subset of them will be included in OpenEdition, which was announced in February,1993. Only some of the Posix standards are approved by ISO until now. The others are in the working groups and the list of Posix standards is growing. To many people open means UNIX. Although Posix evolved from UNIX, it is not the same as UNIX. As in UNIX, many of the Posix functions have colorful names like fork and kill which are very descriptive for the functions they perform. The visual lists some of the functions that will be described in the OE functions topic. X/Opens definition of XPG4 as a base computing platform is made up of internationalized system calls and libraries, internationalized commands and utilities, and the C-language. These specifications incorporate the POSIX standards. The next issue of X/Open Portability Guides (XPG4.2) takes XPG4 as a base and adds many additional functions used by the commonly accepted UNIX platforms and major UNIX applications. This is often called Spec 1170 or Single Unix specification.Since X/Open owns the UNIX brand, systems that meet the XPG4.2 specifications will be certified as UNIX branded systems. OS/390 R2 was branded in 1996. Additional Information Transition Statement We have mentioned the Posix file system already. Let s look at an overview of the file system.
8-73
Instructor Guide
Figure
8-32. Hierarchical File System (ES271859)
Notes:
The XPG4 file system is hierarchical and byte oriented. Finding a file in this file system is done by searching a directory or a series of directories. There is no concept of an MVS catalog that points directly to a file. A path name identifies a file and consists of directory names and a file name. A fully-qualified file name which consists of the name of each directory in the path to a file plus the file name itself, can be up to 1023 bytes long. The hierarchical file system allows for file names in mixed case. The Hierarchical File System (HFS) data set which contains the hierarchical file system is a new MVS data set type. An HFS data set is allocated as any other MVS data set and it must be managed by DFSMS.
8-74
Instructor Guide
Instructor Notes:
Purpose Use this visual to introduce the hierarchical file system. It is very similar to hierarchical file systems on UNIX, DOS, and OS/2. The visual shows an example of a hierarchical file structure. Details The files in the hierarchical file system are sequential files, and they are accessed as byte streams. A record concept does not exist with these files other than the structure defined by an application. The path name is constructed of individual directory names and a file name separated by the forward-slash character. For example, /dir1/dir2/dir3/myfile. Like UNIX, OpenEdition is case sensitive to file and directory names. For example, in the same directory the file MYFILE is a different file than myfile. HFS datasets and MVS data sets can reside on the same SMS-managed DASD volume. One HFS data set can be connected to another HFS data set by use of an authorized command. This capability allows the file system to grow. This is also an advantage of OpenEdition because it provides access to high-speed, large volume DASD. Data can be copied from hierarchical files to MVS data sets and the other way around in an OpenEdition environment. The integration of the HFS file system with existing MVS file system management services provides automated file system management capabilities which may not be available on other Posix platforms. This allows file owners to spend less time on tasks such as backup and restore of entire file systems. Additional Information Transition Statement Lets introduce the interactive interface to OpenEdition, which is called the OpenEdition shell.
8-75
Instructor Guide
Figure
8-33. Shell and Utilities (ES271861)
Notes:
The OpenEdition Shell and Utilities is the interactive interface for end users. It provides a command interface to the OpenEdition environment. A user gets access to the shell by either logging on to TSO/E or by using the remote login facilities of TCP/IP (rlogin). If they use TSO/E then a new command called OMVS will create a shell for the user. The user then works within the shell environment until exiting or temporarily switching back to the TSO/E environment. If they enter MVS through the rlogin capabilities of TCP/IP then a shell environment will automatically be created for them and they will have limited access to TSO services. The shell is a command interpreter which accepts commands defined in the XPG4 standard. Some commands will call programs, called utilities. The shell user can create named lists of shell commands, called a shell script, which becomes a powerful new command. The shell provides support to invoke the ISPF/PDF editor to edit and browse HFS files for the TSO/E user. For the non-TSO user the vi editor is supported.
8-76
Instructor Guide
Instructor Notes:
Purpose This is an overview of the interactive interface to the OpenEdition environment. Details IBM has licensed Mortice Kern Systems InterOpen XPG4 shell and utilities source code to bring MVS/ESA into conformance with the XPG4 standards. The shell and utilities are included in the Application Services base element of OS/390. The visual shows that a user that wants to access the shell may first log on to TSO/E and issue the OMVS command. Users can access TSO/E from real and emulated 3270 terminals through the SNA network, or from UNIX systems or other workstations which in a TCP/IP network support the TELNET3270 (TN3270) client function. TCP/IP has an interface to ACF/VTAM because TSO/E only supports access through ACF/VTAM. TCP/IP as shown on the visual is not required; it is an option for users attached to a TCP/IP network. Non-TSO/E users can access MVS through the rlogin capabilities of TCP/IP. These users have no direct TSO access, but will access the shell directly from the rlogin command. This will avoid the overhead of the telnet server accessing VTAM and then TSO. These terminals are character mode terminals. Therefore their input must be translated from ASCII to EBCDIC and buffered to form line input as expected by the OE shell. This can add a sizeable amount of overhead, so MVS/ESA SP5.2.2 introduces the Outboard Communication Server (an RS/6000) to move this overhead out of MVS. The shell and utilities topic will cover this in more detail. Note that the shell commands (examples on visual) are very short. This is typical in a UNIX environment. The XPG4 standard distinguishes between a command (a directive to the shell to perform a specific task) and a utility (the name of a program callable from a shell). It does not make a difference for the user since they both will look like commands for the end user. A useful facility of the shell when accessing it through TSO/E is the ability to jump into TSO/E, run a TSO command, and return to the shell. While jumping back and forth between TSO/E and the shell, the user remains logged on to the OpenEdition environment and to TSO/E. A PF key is used to jump between the shell and TSO/E. For TCP/IP-attached users there is a new shell command, tso, to allow them to request a subset of TSO services from the shell. Additional Information Transition Statement Lets take a look at the services for application programs in an OpenEdition environment.
8-77
Instructor Guide
Figure
8-34. Application Services (ES271863)
Notes:
With the OpenEdition application programming interfaces (API), it is possible to develop XPG4-compliant applications on any supporting platform, that will execute on OS/390 and access OpenEdition services and data. Many of the XPG4 function calls are available as callable services in OS/390. With this support, it is possible to develop mixed MVS applications which can invoke existing MVS services and call OpenEdition services in the same application. The OpenEdition support in OS/390 does not affect existing MVS applications using existing MVS services.
8-78
Instructor Guide
Instructor Notes:
Purpose Introduction to the application programming facilities in the OpenEdition environment. Details Use this visual to summarize the new opportunities the OpenEdition services provide for application programmers. The way OpenEdition is implemented in MVS/ESA does not affect any existing MVS applications (referred to as non-XPG programs on the visual). The OpenEdition services provide the capability to run XPG4 applications in an MVS/ESA system. The XPG4 application can be developed on any XPG4 platform because it is independent of any MVS specifics. OpenEdition also provides the opportunity to create mixed applications, that is MVS applications which use standard MVS services to utilize MVS functions as well as the OpenEdition callable services to invoke XPG4 functions. This is especially useful for access to the HFS files. Note that a mixed application will not be portable because it will use callable services unique to OS/390. Additional Information Transition Statement Now lets summarize the course topics.
8-79
Instructor Guide
Figure
Notes:
8-80
Instructor Guide
Instructor Notes:
Purpose To summarize the overview topic. Details Go quickly through the list which highlights the contents of this unit. The students should now be aware of what information this course will provide for them. Additional Information Transition Statement Lets look at an overview of the features of a UNIX system, and the concept of open systems.
8-81
Instructor Guide
8-82
Instructor Guide
Appendix A. Enterprise Systems Connection (ESCON) Overview (Optional topic)

This unit describes the functions and capabilities of the ESCON architecture.


Determine the components that comprise the ESCON world. Understand the purpose and operation of the ESCON directors. Recognize the functions provided by ESCON Multiple Image Facility (EMIF).

Accountability:
Appendix A. ESCON Overview
A-1
Instructor Guide
Figure
A-1. Objectives (ES271A00)
Notes:
A-2
Instructor Guide
ESCON, Directors and EMIF Overview
A-3
Instructor Guide
Figure
A-2. Enterprise Systems Connection Architecture (ES271A01)
Notes:
A-4
Instructor Guide
Instructor Notes:
A-5
Instructor Guide
Figure
A-3. Spectrum of ESCON Products (ES271A03)
Notes:
A-6
Instructor Guide
Instructor Notes:
A-7
Instructor Guide
Figure
A-4. ESCON Channel Types (ES271A05)
Notes:
A-8
Instructor Guide
Instructor Notes:
A-9
Instructor Guide
Figure
A-5. Role of the ESCON Director (ES271A07)
Notes:
A-10
Instructor Guide
Instructor Notes:
A-11
Instructor Guide
Figure
A-6. Director Connections (ES271A09)
Notes:
A-12
Instructor Guide
Instructor Notes:
A-13
Instructor Guide
Figure
A-7. ESCON Distances (ES271A11)
Notes:
A-14
Instructor Guide
Instructor Notes:
A-15
Instructor Guide
Figure
A-8. CHPID Usage (ES271A13)
Notes:
A-16
Instructor Guide
Instructor Notes:
A-17
Instructor Guide
Figure
A-9. ESCON Director 9032 Model 3 (ES271A15)
Notes:
A-18
Instructor Guide
Instructor Notes:
A-19
Instructor Guide
Figure
A-10. 9033 Model 4 ESCON Director (ES271A17)
Notes:
A-20
Instructor Guide
Instructor Notes:
A-21
Instructor Guide
Figure
A-11. 9032 Model 3 and 9033 Model 4 Summary (ES271A19)
Notes:
A-22
Instructor Guide
Instructor Notes:
A-23
Instructor Guide
Figure
A-12. ESCON Multiple Image Facility (ES271A21)
Notes:
A-24
Instructor Guide
Instructor Notes:
A-25
Instructor Guide
Figure
A-13. S u m m a r y (ES271A99)
Notes:
A-26
Instructor Guide
Instructor Notes:
A-27
Instructor Guide
A-28
Instructor Guide
Appendix B. Checkpoint Solutions

Unit 1 - Review of S/390 and OS/390
1. 2. 3. 4. 5. True d False True d
Unit 2 - Overview JES, TSO

1. 2. 3. 4. True e False True
Unit 3 - MVS/ESA or OS/390 IPL Flow

1. 2. 3. 4. 5. True b a, b, c, d 1, 2, 4, 3 4, 2, 3, 1, 5
Unit 4 - MVS/ESA or OS/390 Consoles Operation

1. false
Unit 5 - OS/390 MVS Commands

1. 2. 3. False c d, a, b, c
Appendix B. Checkpoint Solutions
B-1
Instructor Guide
4.
DS P,dddd D M=DEV(dddd)
Unit 6 - OS/390 Communication Server

1. 2. 3. 4. 5. False True True True False
Unit 7 - Netview
1. 2. d True
B-2
Instructor Guide
Bibliography
GC26-4900
GC28-1725 GC28-1727 GC28-1757 GC28-1794 GC28-1808 GC28-1860
GC28-1869 GC28-1964 GC28-1967 GC28-1969 GC35-0033
DFSMS/MVS Version 1 Release 3: General Information An Introduction to OS/390 Information Roadmap OS/390 MVS JCL Reference OS/390: JES2 Introduction OS/390: JES3 Introduction Parallel Sysplex Overview: Introducing Data Sharing and Parallelism in a Sysplex TSO Extensions Version 2: General Information OS/390 TSO/E General Information OS/390 TSO/E Primer OS/390 TSO/E Command Reference Device Support Facilities: User s Guide and Reference
SA22-7201 SC23-0408
SC26-4564 SC26-4914 SC26-4916 SC26-4926 SC26-4922 SC34-4440
SC28-1239 SC28-1294 SC28-1312
ESA/390 : Principles of Operation System Display and Search Facility Guide and Reference MVS/DFP 3.3: Linkage Editor and Loader DFSMS/MVS V1R3 Managing Catalogs DFSMS/MVS V1R3 Program Management DFSMS/MVS Utilities DFSMS/MVS V1R3 Using Data Sets Interactive System Productivity Facility: Getting Started OS/390 ISPF User s Guide OS/390 ISPF Getting Started OS/390 ISPF Edit and Edit Macros

Bibliography
X-1
IBML

ZOS System Operations Students Handbook ES271

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

ZOS System Operations Students Handbook ES271

Încărcat de

Drepturi de autor:

Formate disponibile

Instructor Guide

Copyright IBM Corp. 1997, 1998

OS/390 System Operations

Copyright IBM Corp. 1997, 1998

Unit 4. MVS/ESA or OS/390 Consoles Operation Objectives . . . . . . . . . . . . . . . . . . . . . . . OS/390 Overview . . . . . . . . . . . . . . . . . .

Copyright IBM Corp. 1997, 1998

4-38 4-41 4-42 5-1 5-2 5-4

Copyright IBM Corp. 1997, 1998

Copyright IBM Corp. 1997, 1998

A-1 A-3 B-1 X-1

OS/390 System Operations

Copyright IBM Corp. 1997, 1998

Instructor Course Overview

Copyright IBM Corp. 1997, 1998

Instructor Course Overview

OS/390 System Operations

Copyright IBM Corp. 1997, 1998

OS/390 System Operations Duration : 2.5 days Purpose

Copyright IBM Corp. 1997, 1998

OS/390 System Operations

Copyright IBM Corp. 1997, 1998

Copyright IBM Corp. 1997, 1998

OS/390 System Operations

Copyright IBM Corp. 1997, 1998

Unit 1. Review of S/390 and OS/390

What This Unit Is About

What You Should Be Able to Do

How You Will Check Your Progress

Copyright IBM Corp. 1997, 1998

Unit 1. Review of S/390 and OS/390

1-1. Objectives (ES271100)

OS/390 System Operations

Copyright IBM Corp. 1997, 1998

Copyright IBM Corp. 1997, 1998

Unit 1. Review of S/390 and OS/390

OS/390 System Operations

Copyright IBM Corp. 1997, 1998

1.1 System/390 Overview

Copyright IBM Corp. 1997, 1998

Unit 1. Review of S/390 and OS/390

1-2. System/390 Overview (ES271101)

OS/390 System Operations

Copyright IBM Corp. 1997, 1998

Copyright IBM Corp. 1997, 1998

Unit 1. Review of S/390 and OS/390

1-3. Processor Types (ES271103)

OS/390 System Operations

Copyright IBM Corp. 1997, 1998

Copyright IBM Corp. 1997, 1998

Unit 1. Review of S/390 and OS/390

1-4. Modes of Operation (ES271105)

OS/390 System Operations

Copyright IBM Corp. 1997, 1998

Copyright IBM Corp. 1997, 1998

Unit 1. Review of S/390 and OS/390

1-5. Logical Partitioning / Partitioning with VM (ES271107)

processors storage (central/expanded) channel paths

Processors can be shared among logical partitions or dedicated to a specific LPAR.

OS/390 System Operations

Copyright IBM Corp. 1997, 1998

Copyright IBM Corp. 1997, 1998

Unit 1. Review of S/390 and OS/390

OS/390 System Operations