VM/XA SYSTEM PRODUCT GUIDI
GG24-3173-0 VM/XA SYSTEM PRODUCT GUIDE
Document Number GG24-3173
August 1987
IBM World Trade Corporation International Technical Support Center SYSTEM PRODUCT Poughkeepsie, New York, USA This document provides a general description of the new capabilities of the VM/XA System Product. It is intended to provide planning information for IBM System Engineers, to help them advise and I prepare customers for the new VM/XA environment.
It is assumed that the reader has previous experience with VM and its CP and CMS components.
This document was written based on early information about VM/XA SR. Therefore, it may be incom plete or not up to date.
VMSYS 98 pages
First Edition (August 1987) This edition applies to the Virtual Machine/Extended Architecture System Product Release 1 (VM/XA Sys tem Product) Program Product 5664-308. The VM/XA System Product replaces the Virtual Machine/Extended Architecture Systems Facility (VM/XA Systems Facility) The information contained in this document has not been submitted to any formal IBM test and is distrib uted 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 customer's ability to evaluate and integrate them into the customer's 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 be obtained elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk. References in this publication to IBM products, programs, or services do not imply that IBM intends to make these available in all countries in which IBM operates. Any reference to an IBM program product in this publication is not intended to implythat only IBM's program product may be used. Any functionally equivalent program may be used instead. Publications are not stocked at the address given below. Requests for IBM publications should be made to your IBM representative or to the IBM branch office serving your locality. A form for readers' comments is provided at the back of this publication. Ifthe form has been removed, comments may be addressed to IBM World Trade Corporation, International Technical Support Center, Department H52, Building 930, PO Box 390, Poughkeepsie, NY. USA 12602. IBM may use or distribute whatever information you supply in any way it believes appropriate without incurring any obligation to you.
© Copyright international Business Machines Corporation 1987
II VM/XA SP Guide Preface
This document Is intended to provide advanced planning information for the VM/XA System Product. It has been structured in two parts: Part 1 is an overview of VM/XA BP that provides the reader with a general understanding of the function and benefits of the product. Part 1 should be read by anyone requiring an understanding of VM/XA BP.
Part 2 is a more detailed, technical look at the line items included in this release. This part will be of more interest to systems programmers and systems engineers.
Related Documentation
The manuals listed in this section contain information specific to VM/XA BP Release 1.
Evaluation
• VM/XA SP General Information, GC23-0362 • VM at a Glance: Large System, SC23-0360
Migration and Conversion
• VM/XA SP Conversion Notebook, BC23-0357 VM/XA SP Application Conversion Guide for CMS, BC23-0403
Planning
VM/XA SP Planning Guide, SC23-0378
Installation and Service
• VM/XA SP Installation and Service, BC23-0364 VM/XA SP Licensed Program and Subsystem Reference Card, BX23-0392 VM/XA SP Licensed Program Specifications, GC23-0366
Administration
• VM/XA SP Administration, SC23-0353
Preface ill Operation
VM/XA SP Real System Operation, SC23-0371 VM/XA SP Virtual Machine Operation, SC23-0377
Application Programming
VM/XA SP Application Developement Guide for Fortran and Cobol, SC23-0369 VM/XA SP Application Conversion Guide for CMS, SC23-0403 VM/XA SP Application Development Guide for CMS, SC23-0355 VM/XA SP Application Development Reference for CMS, SC23-0402 VM/XA SP CP Services, SC23-0370
End Use
VM/XA SP CMS Primer, SC23-0368 VM/XA SP CMS User's Guide, SC23-0356 VM/XA SP Introduction, GC23-0365 VM/XA SP System Product Interpreter User's Guide, SC23-0375 VM/XA SP System Product Editor User's Guide, SC23-0373
Diagnosis
VM/XA SP CMS Data Areas and Control Blocks, LY27-8051 VM/XA SP CMS Diagnosis Reference, LY27-8052 VM/XA SP CP Data Areas and Control Blocks, LY27-8053 VM/XA SP CP Diagnosis Guide, LY27-8056 VM/XA SP CP Diagnosis Reference Volume 1, LY27-8054 VM/XA SP CP Diagnosis Reference Volume 2, LY27-8055 VM/XA SP Dump Viewing Facility Operation Guide and Reference, SC23-0359 VM/XA SP Problem Determination Reference Booklet, SX23-0390
Cross-task References
VM/XA SP CMS Command Reference, SC23-0354 VM/XA SP CP Command Reference, SC23-0358 VM/XA SP CP Programming Services, SC23-0370 VM/XA SP EXEC 2 Reference, SC23-0361 VM/XA SP Quick Reference, SX23-0391 VM/XA SP System Product Interpreter Reference, SC23-0374 VM/XA SP System Messages and Codes, SC23-0376 VM/XA SP System Product Editor Command and Macro Reference, SC23-0372 VM/XA SP Features Summary, LY27-8058
Library Support
• VM/XA SP Library Guide, Glossary and Master Index, .GC23-0367
Extended Architecture IBM System/370 Extended Architecture Principles of Operation, SA22-7085 IBM System/370 Extended Architecture Interpretive Execution, SA22-7095 IBM System/370 Vector Operations, SA22-7125 7^
VM/XA SP Guide Tape and DASD
IBM 3880 Storage Control Models 1, 2, 3, and 4, GA26-1661 IBM 3880 Storage Control Model 23, GA32-0083 IBM 3480 Magnetic Tape Subsystem Reference, GA32-0042 DASD Availability Topics, GG66-0202
Other Planning Information
VM/XA Systems Facility Planning Guide, GG24-1709 Bimodal CMS for VM/XA Systems, GG24-3174
Preface vi VM/XA SP Guide Table of Contents
PART 1 - GENERAL USER GUIDE 1
Purpose of VM/XA SP Release 1 3 Overview 3 CMS Extensions 4 CP Extensions 5 VM/SP HPO and VM/XA SP Release 1 Comparison 6 Preferred Guests in VM/SP HPO and VM/XA SP Release 1 6 ^ ^ Available Program Products 7 PROFS 7 RACF 8 SQL/DS 8 Program Products in System/370 Mode 8 Program Products in System/370 Mode and 370-XA Mode 9 When to Install VM/XA SP Release 1 10 Function 11 Performance 12
Summary of New Features in VM/XA SP Release 1 13
Summary of New Features In VM/XA SP Release 2 IS Overview 15 Compatibility 15 Licensed Programs supported: 15
PART 2 - TECHNICAL GUIDE 17
Elimination of Growth Constraints 19 Architectural Constraint Relief 19 Spool File Limit Relief 19
Functional Compatibility and Hardware Enhancements 21 Functional Compatibility 21 User Class Restructure 21 Privilege Classes 22 Changing Classes 22 Directory 23 Commands a User May Issue 23 Command and Message Compatibility 23 DIAGNOSE Code Compatibility 24 SQL/DS 24 DASD Block I/O System Service 25 Protected Application 25 System Profile (SYSPROF EXEC) 26 Default Functions 26 Building a Protected Application Environment 27 Examples of Initialization Functions 27 Programmable Operator Facility 27
Table of Contents vii Use in a Single System 27 Use in Distributed VM/XA SP Release 1 Systems 28 _ Single Console Image Facility 28 Hardware Enhancements 29 Display Support Improvements 29 3290 Information Panel 29 3278 Model 5 Display Station 30 APL and Text 30 Output Batching 30 System Generation for Displays 30 Virtual Console Display 31 Printer Enhancements 31
Perfornnance Enhancements 33 Performance Characteristics 33 Scheduler 34 Overall Design 36 Dormant List 36 Eligible List 37 Dispatch List 37 Control of the Resources by the Scheduler 38 Impact of Scheduler Changes 40
Multiple Preferred Guests 43 Overview 43 V=F and V=R Similarities 43 V = F and V=V Similarities 43 Real Processor Management 44 Overview 44 System Management 44 CPU directory statement 44 OPTION Directory Statement 44 Real System Operation 46 DEDICATE Command 46 UNDEDICATE Command 46 Support Use Information 47 Directory Changes 47 DEDICATE/UNDEDICATE Commands for V = R 47 V=V Dedication 47 Vector Facilities and Dedicated Processors 48 Expanded Storage Management 48 Overview 48 Real System Operation 48 ATTACH XSTORE Command 48 DETACH XSTORE Command 49 QUERY XSTORE Command 49 Real Storage Management 51 Overview 51 Real System Operation 52 QUERYV= R Command 52 Support use information 53 Allocating sufficient V= R storage 53 Logging on V= R and V= F users 54 Handling the V= R region following a software re-IPL 54 Recovery 54 Migration 54 Migrating from VM/XA SF Release 2 55 Migrating from VM/SP HPO Release 5 55
Monitor Facility 57
vili VM/XA SP Guide Monitor Data Collection 57 Monitor Data Domain Architecture 58 Monitor Control Mechanisms 59 The Monitor Discontiguous Saved Segment 60 MONITOR lUCV Communication 60 Service Virtual Machine Wait 61 Service Virtual Machine Statistics 61 Monitor Writer 61
RAS and Usability Enhancements 63 Control Block Identifier 63 CCW Translation Redesign 63 PL/AS 64 Logged-on user limit enhancements 64 Terminal availability enhancements 64
Migration Considerations 67 System Evaluation 67 Migration from VM/SP or VM/SP HPO Release 5 to VM/XA SP Release 1 ... 67 Advantages 67 Disadvantages 68 Migration from .VM/XA SF to VM/XA SP Release 1 68 Advantages 68 Disadvantages 69 Migration Information 69 Migration Planning 69 VM/SP Release 5 and VM/SP HPO Release 5 70 VM/VSE 72 MVS 72 VM/XA SF 72 Installation and Service 73 VM/SP Release 5 and VM/SP HPO Release 5 73 VM/XA SF 74 System Management 75 VM/SP Release 5 and VM/SP HPO Release 5 75 VM/XA SF 75 Real System Operation 75 VM/SP Release 5 and VM/SP HPO Release 5 75 VM/XA SF 76 Virtual Machine Operation 77 VM/SP Release 5 and VM/SP HPO Release 5 77 VM/XA SF 77 Application Program Development and Debugging 78 VM/SP Release 5 and VM/SP HPO Release 5 78 VM/XA SF 79 DIAGNOSE Codes 79
Appendix A. Summary of Changes from Prior Releases 81
Appendix B. DIAGNOSE Codes 83 Compatible DIAGNOSE Codes 83 Upward Compatible DIAGNOSE Codes 83 Incompatible DIAGNOSE Codes 84 VM/SP HPO Only DIAGNOSE Codes 85 VM/XA SP Release 1 Only DIAGNOSE Codes 85
Appendix C. Installation and Service EXEC Procedure 87 Installation EXEC 87 ITASK EXEC 88 SPLOADEXEC 89
Table of Contents ix SPLOAD PROFILE 89 SPGENEXEC 90 SPGEN PROFILE 91 UTILITY EXEC 92 Installation Steps 92
Appendix D. National Language Support (NLS) 95 Enabling 95 Making Other Languages Available 95
Index 97
VM/XA SP Guide List of illustrations
Figure VM Operating Systems and their Processor Support 4 Figure Simplified Decision Flowchart 11 Figure Single Console Image Facility 29 Figure Use of Queues by the Scheduler 36 Figure Use of Eligible List by Scheduler 37 Figure Use of Dispatch List by Scheduler 38 Figure Storage Buffer Allocation 39 Figure CPU Directory Statement Changes 44 Figure Option Directory Statement Changes 45 Figure 10. DEDICATE Command Change 46 Figure 11. UNDEDICATE Command Change 46 Figure 12. DETACH XSTORE Command Format 49 Figure 13. QUERY XSTORE Command Format {class B) 49 Figure 14. Real storage layout 52 Figure 15. QUERY V = R Command Format 52 Figure 16. Monitor Facility Information Flow 60 Figure 17. Writer Communication with "MONITOR 62 Figure 18. Data Reduction Communicating with "MONITOR 62 Figure 19. ITASK Command Format 88 Figure 20. SPLOAD Command Format 89 Figure 21. SPLOAD PROFILE Format 89 Figure 22. SPGEN Command Format 90 Figure 23. SPGEN PROFILE Format 92
List of Illustrations xl xii VM/XA SP Guide Part 1 - General User Guide
This part provides an overview of VM/XA System Product. It includes discussions on the main functions of VM/XA BP Release 1 and VM/XA BP Release 2, the line items that are new in comparison with VM/XA Systems Facility, and the performance profile of the system.
Part 1 • General User Guide 2 VM/XA SP Guide Purpose of VM/XA SP Release 1
VM/XA SP Release 1 is the VM product that supports the IBM 370-XA processors. The main purposes of VM/XA SP Release 1 are: • To provide virtual machine environments where several independent operating systems can be run concurrently on a single processor, or on a processor complex. This allows:
• Different concurrent production environments, such as MVS/XA and VSE. • Migration environments, such as MVS/SP running with MVS/XA. • Testing environments, such as MVS/XA (production) and separate MVS/XA test systems. • To provide centralized, personal computing facilities for a large number of users. This allows:
CMS based end-user facilities Electronic mail Text processing Language processors Program creation under Bimodal CMS Office system
Overview
There are currently four major VM operating system offerings: VM/SP, VM/SP HPO, VM/XA SF, and VM/XA SP Release 1 (Refer to Figure 1). VM/XA SP Release 1 should be regarded as the successor to VM/XA SF, and IBM's strategic VM offering for Extended Architecture.
Purpose of VM/XA SP Release 1 Partitioie^ IMi
Partitlaii^ yedi
43SI 9379 FC/F 370 VM/HPO
Figure 1. VM Operating Systems and their Processor Support
VM/PC Is inciuded in the diagram purely for completeness, and will not be discussed further in this document. VM/SP is the VM system for the small and intermediate processors in System/370 mode. It runs only on processors with 2K storage protect keys (for example. 9370s, 4361s, and 4381s), with a maximum of 16 Mb of main storage.
VM/SP HPO and VM/XA SP Release 1 are both aimed at the high-end processors. VM/SP HPO supports processors up to the 3090 Model 200E, or the 3090 Model 400E {in partitioned mode only), while they are running in System/370 mode. It provides improved performance over VM/SP for a CMS intensive environment, and for a V= R MVS/SP guest (refer to "Preferred Guests in VM/SP HPO and VM/XA SP Release 1" on page 6). In contrast, VM/XA SP Release 1 is the strategic VM offering for the IBM 370-XA processor family. It runs on all Extended Architecture processors, from the 4381 upwards to IBM's largest N-way processor. A single image of the multiple instruction processors is provided by VM/XA SP Release 1. VM/XA SP Release 1 provides a growth path for all VM/XA SF customers and some large VM/SP HPO customers, with increased capabilities and exploitation of the 370-XA archi tecture. The increased capabilities are provided in both the CMS component of VM and the VM Control Program itself.
VM/IS is not Included in our comments as it is a packaging of VM/SP with other program products.
CMS Extensions
VM/XA SP Release 1 provides the ability to run CMS intensive workloads on 370-XA processors. The increased storage, I/O, and processing capacity of the 370-XA processors can be used to support a large number of CMS users.
VM/XA SP Guide The CMS component of VM/XA SP Release 1 is based on the CMS contained in VM/SP Release 5 but has been enhanced to support 370-XA architecture. That is, bimodal CMS can now operate in an XA-mode virtual machine, and architecturally could use up to 2 Gb of virtual storage. However, a virtual machine is limited to 999 Mb of virtual storage by the current release of VM/XA SP Release 1.
VM/XA SP Release 1 offers a bimodal CMS designed to extend 370-XA advantages to CMS users. This CMS can operate in either System/370 mode with 24-bit addressing or in 370-XA mode with 24- or 31-bit addressing. This addressing removes the current System/370 architectural limitation of 16 Mb of virtual storage for a single user. Pro grams can be generated to run in 24-bit, 31-bit, or either mode. In addition, a program interface has been included to allow application portability between System/370 and 370-XA environments.
Other aspects of bimodal CMS operation with Extended Architecture include:
Some I/O routines have been rewritten to take advantage of Extended Architecture.
Storage management routines have been rewritten to exploit the larger address space now available.
Modules generated as relocatable may be loaded anywhere in the CMS address space.
MVS/XA macros and simulation routines are available in CMS, replacing the older OS macros currently in macro libraries.
Discontiguous saved segments may now be loaded inside a virtual machine address space. An area may be set aside for segments to prevent programs from being loaded into it.
Bimodal CMS is further described in a companion publication, Bimoda! CMS for VM/XA Systems.
CP Extensions
In addition to the enhanced CMS functions, VM/XA SP Release 1 offers more of the functions available today in VM/SP HPO. These additions allow increased compatibility with VM/SP HPO, and thereby allow easier migration to VM/XA SP Release 1. However, due to differences between System/370 and 370-XA architectures, some command syn tax, responses, and messages are not compatible. In addition, some incompatibilities have remained where the VM/XA SP Release 1 function has enhanced usability over the equivalent VM/SP HPO function. For example, the QUERY VIRTUAL device command in VM/XA SP Release 1 returns additional information over and above that returned under VM/SP HPO.
Additional function has also been included. In particular, commands have been added that enhance the tuning and debugging information available to the system programmer.
To improve compatibility with VM/SP HPO, some incompatibilities with VM/XA SF were introduced. However, commands are similar to those provided by VM/XA SF Release 2.
Significant enhancements have been made in VM/XA SP Release 1 over the functions that were provided in VM/XA SF. Some of these improvements are:
• Collection of monitoring information
• Enhanced processor and device support
• Larger selection of program products
Purpose of VM/XA SP Release 1 VM/SP HPO and VM/XA SP Release 1 Comparison
There are several advantages that VM/XA SP Release 1 has over VM/SP HPO:
• VM/XA SP Release 1 guest virtual machines may be either System/370 or 370-XA architecture. VM/SP HPO allows only System/370 guest machines.
• VM/XA SP Release 1 guest virtual machines may have up to 64 virtual processors. This allows you to thoroughly test guests generated to run on multiple instruction processors. Under VM/SP HPO, only an MVS Preferred Guest can have more than one virtual processor (it can have up to two, when running on a dual or dyadic processor). in this environment, it is limited to using one dedicated processor, and part of the second processor in the complex. This is known as "single processor mode".
• VM/XA SP Release 1 permits use of N-way processor complexes, and provides a single software image of the entire complex. VM/SP HPO allows only one or two real instruction processors.
• VM/XA SP Release 1 uses the Extended Architecture channel subsystem. Extended Architecture moves the management of I/O from the processor and operating sys tem into the channels themselves. Devices are driven down any path available, and the I/O does not always have to return on the same path from which it was started. This gives you improved performance and RAS characteristics over that available when using the System/370 channel subsystem. More I/O devices can be attached to a processor complex, and bottlenecks are less likely to occur. • In VM/XA SP Release 1. data to be used in an I/O operation can be anywhere in real storage, either above or below the 16 Mb line. In VM/SP HPO, some data had to be moved below the 16 Mb line before it could be used in an I/O operation, and this implies more CP overhead. • In VM/XA SP Release 1, control blocks may be kept anywhere in real storage. In VM/SP HPO systems with a large CMS population, or systems with large MVS/SP preferred guests, space below the 16 Mb line is at a premium. Many of the control blocks required by CP in VM/SP HPO have to be kept in the bottom 16 Mb of real storage. This increases again the virtual storage constraints and leads to poor performance. • VM/XA SP Release 1 allows you to have up to the maximum real storage provided on IBM processors. VM/SP HPO has a maximum real storage size of 64 Mb. • VM/XA SP Release 1 allows the expanded storage to be partitioned between CP and a single guest virtual machine. VM/SP HPO allows use of expanded storage only as a paging and swapping pool for use by CP.
However, VM/SP HPO has several functions not available to VM/XA SP Release 1 users: • The set of program products supported by VM/SP HPO is larger than that supported by VM/XA SP Release 1. • VM/SP HPO works with a wider range of I/O devices than VM/XA SP Release 1. Refer to on "Migration Considerations" on page 67 for a more complete list of differences between VM/XA SP Release 1 and VM/SP HPO.
Preferred Guests in VM/SP HPO and VM/XA SP Release 1
Under VM/SP HPO, an MVS/SP or VSE guest can be run as a "V = R" guest; that is, it can be given a quantity of real storage for its sole use. In addition, a microcode assist. Pre ferred Machine Assist (PMA), can be used by an MVS/SP or VSE/SP 3.1 V= R guest un-
6 VM/XA SP Guide der VM/SP HPO if It is available on the processor. This machine is then known as a "Preferred" guest.
The PMA microcode allows efficient execution of MVS/SP or VSE/SP 3.1 under VM/SP HPO. PMA allows a preferred guest to run with separate channels directly controlled by the Preferred guest. It also allows Preferred Machine Recovery to take place, that is the ability for an guest to continue to run after a CP abend. Although VM/XA BP Release 1 also provides a "preferred guest", its implementation is very different from that in VM/SP HPO. A major difference is that the VM/XA SP Release 1 preferred guest can be either a System/370 or an 370-XA operating system. The pre ferred guest can have as many as n-1 instruction processors (in an N-way processor) dedicated to its sole use.
Another major difference is in the area of microcode assists. A facility known as "Interpretive Execution" is invoked by the instruction, START INTER PRETIVE EXECUTION. The SIE instruction is used by VM/XA SF and VM/XA SP Release 1 to dispatch a virtual machine; the execution of the virtual machine is then controlled by the microcode. A microcode assist, known as SIE Assist, allows the preferred guest to achieve high performance under VM/XA SF or VM/XA SP Release 1. These benefits are derived mostly from the improved performance of preferred guest I/O. Any SCP as a preferred guest with dedicated devices issues its I/O with minimum intervention by CP. Thus, the I/O devices are simpler to configure than in VM/SP HPO, where devices have to be on a separate channel to gain a similar benefit. SIE Assist is available on 370-XA mode processors. Using this assist, you can get as a preferred guest performance similar to that obtained using PMA. For further information, please refer to the VM/XA Systems Facility Planning Guide.
Available Program Products
VM/XA SP Release 1 provides an extensive list of program products to be available un der CMS. We should emphasize two program products of this list:
• PROFS • RACF • SQL/DS Some of the products of this list can run only under System/370 mode and some can run either in System/370 mode or in 370-XA mode.
PROFS
Professional Office System (PROFS) is a program product designed to provide a com prehensive and easy-to-use set of office system and functions for non-DP and DP users. Operating as a VM/XA CMS application program, PROFS offers a wide range of auto mated office functions for executives, professionals, and secretaries. The functions in clude calendar and scheduling facilities, notes and messages, reminders, as well as the electronic preparation, storage, retrieval, and dissemination of office correspondence within a single system or across multiple VM systems. PROFS offers a broad range of office and personal services functions. Selection and invocation of these functions are simplified through a set of menus and information entry/display screens, and the Help facility. The screens are designed to guide the in experienced user through PROFS while providing commands for fast access to many of the desired functions for the more advanced user.
Purpose of VM/XA SP Release 1 7 Menus are used to present a list of choices for user selection. For example, the first screen in PROFS shows a selection list of major functions.
RACF
VM/XA SP Release 1 provides customers with the data security functions provided in VM/SP HPO to ensure compatibility for those customers who have implemented RACF on their current VM/SP systems. RACF is a strategic program product for large operating systems that provides security capabilities. RACF controls user access to the system, checks authorization for use of system resources, and audits the use of system resources.
SQUDS
SQLVDS Version 2 is a complete, full-function, relational data base management system (RDBMS) with integrated query and report writing facilities. SQL/DS Version 2 Release 1 includes the capabilities of SQL/DS Version 1 and provides additional productivity and usability enhancements for application programmers and end users, through the addi tion of new data types, enhanced programming language support, and other extensions to the Structured Query Language (SQL), as well as operating system support, specific performance, and RAS enhancements.
Program Products in System/370 Mode
This section lists the program products that may be used in System/370 mode in VM/XA SP Release 1 and beyond. Later versions, releases, and modifications of the listed li censed programs are also supported unless noted. VM/XA Migration Aid Remote 3270 Display Option (RDO) (5664-183) RSCS Networking Version 1 Release 3 (5748-XP1) Note: Version 2 is not supported
VM/Pass-Through Facility Release 2 (5748-RC1)
VM/Pass-Through Facility Release 3 (5748-RC1)
VSE/VSAM Release 3 (5746-AM2)
Resource Access Control Facility (RACF) Version 1 Release 8 (5740-XXH)
IBM FORTRAN Language Conversion Program (5668-864) (2Q88)
3090 Vector Facility Simulator (5798-DWF) (2Q88) Elementary Math Library (EML) (5799-BTB) (2Q88)
VM/Data Collector (5798-DZF)
Graphical Data Display Manager (GDDM) Release 4 (5748-XXH)
Graphical Data Display Manager Version 2 which includes:
- GDDM/VM Version 2 Release 1.1 (5664-200) • GDDM Presentation Graphics Facility Version 2 Release 1 (GDDM-PGF) (5668-812) • GDDM Interactive Map Definition Version 2 Release 1 (GDDM-IMD) (5668-801) - GDDM Image View Utility (GDDM-IVU) (5668-723) - GDDM Graphical Kernel System (GDDM-GKS) (5668-802)
VM/XA SP Guide • GDDM Restructured Extended Executor (GDDM-REXX) (5664-336) • IBM Professional Office System (PROFS) Version 2 Release 2 (5664-309) including support for the PROFS Application Support Feature and the PROFS Personal Com puter Support Feature at the required service level. Application System (AS) and DisplayWrite/370 (DW/370), co-requisite products of PROFS, are not announced at this time. Availability is planned for 2Q88.
• SQLVDS Version 2 Release 1 (5688-004) Note: VM/XA SP Release 1 will not support the database switching functions, that require TSAF, recently announced by SQL/DS Version 2 for either local or remote databases. • Query Management Facility (5668-972) Version 2 Release 2 (2Q88) • 3270 PC File Transfer Program (5664-281) • High-Accuracy Arithmetic (ACRITH) Subroutine Library Release 3 for VM/SP (5664-185) (2Q88) _ • Graphics Access Method/SP (GAM/SP) Release 2 (5668-978) at the required service level • Graphical Data Display Manager/graPHIGS (TM) (GDDM/graPHIGS) (5668-792) at the then current release • scientific ENgineering Application Director (SCENAD) (5668-882) (2Q88) Note: VM/lnteractive Productivity Facility (VM/IPF) Version 2 Release 1 is a prereq uisite for SCENAD in the VM environment. Only the BROWSE and SADT (stacks in formation from the access device table) functions are supported in VM/XA SP Release 1 and are the only IPF functions required by SCENAD. Advanced Communication Function/System Support Program Version 3 Release 2 for VM (5664-289) at the required service level
Emulation Program Release 4 for the IBM Communications Controllers for use on 3720/3725 (5735-XXB) Emulation Program for the IBM 3705 Communication Controller (5735-XXB) VM Batch Facility (5664-364) (2Q88)
OS PL/I Release 5.1 • Optimizing Compiler and Libraries (5734-PL3) r ^ • optimizing Compiler (5734-PL1) • Resident Library (5734-LM4) • Transient Library (5734-LM5)
♦ IBM Transmission Control Protocol/Internet Protocol (TCP/IP) for VM (5798-FAL) • Document Composition Facility (DCF) Release 3.1 (5748-XX9) at the required service level Note: EDAC - The bimodal CMS in VM/XA SP Release 1 removes the requirement for the Extended Data Array Capability (EDAC) program offering (5799-DWA) and therefore EDAC will not be supported.
Program Products in System/370 Mode and 370-XA Mode
This section lists program products that may be used in both System /370 mode and 370-XA mode. Later versions, releases, and modifications of the listed programs are also supported unless noted.
Purpose of VM/XA SP Release 1 9 • Assembler H Version 2 (5668-962)
• Engineering and Scientific Subroutine Library (ESSL) Release 1 (5668-863) (2Q88) • Interactive System Productivity Facility (ISPF) Version 2 (5664-282) at the then current release. Planned availability is 2Q88. • ISPF/Program Development Facility (PDF) Version 2 (5664-285) at the then current release. Planned availability is 2Q88. NOTE - additional ISPF information will be provided prior to VM/XA SP general availability.
• VS FORTRAN Version 2 at the then current release. Planned availability is 2Q88.
• Compiler, Library and Interactive Debug (5668-806) • Library (5668-805)
• OS PL/I Version 2 (2Q88) • Compiler, Library, and Interactive Test Facility (5668-909) • Compiler and Library (5668-910) • Library (5668-911) • IBM Virtual Storage COBOL II at the then current release (4Q88) • Compiler and Library (5668-958) • Library (5668-940)
When to Install VMIXA SP Release 1
There are several situations in which you should consider installing VM/XA SP Release 1:
• You currently have VM/XA SF installed. • You currently have VM/SP HPO installed for CMS usage (and maybe some guest virtual machines), and are constrained by:
Real storage. Insufficient free storage below the 16 Mb line for control blocks. I/O capabilities in your fully configured System/370 machine. Processor cycles on your machine; you would like to use a single image 3090 Model 400 or 3090 Model 600.
Virtual storage for your CMS users; you require 31-bit CMS address spaces. • You currently don't have VM/XA SF installed, and you require a hypervisor to enable you to run multiple guest machines for production, migration, or test; and at least one of the guests is a 370^XA operating system. Once you have decided that VM/XA SP Release 1 may apply to your situation, you need to review the details of your installation to clarify whether it is appropriate. Please refer to Figure 2 for a simplified decision flowchart.
10 VM/XA SP Guide CVM/XA SP \ Considerotiony
Not OK Consider Your I/O
OK
hlXInstol Iinq JVS/XA?
No/VU/XA SP Do No XA CMS Supports PP nsto Requi red? Function? yy/XA SP
nstfl VU/XA SP
Figure 2. Simplified Decision Flowchart
If you currently do not have VM/XA SF or VM/SP HPO installed, refer to the VM/XA Sys tems Facility Planning Guide for planning and installation considerations. The choice between migrating to VM/XA SP Release 1 or remaining on VM/XA SF or VM/SP HPO should be based on function and performance.
Function
The CMS functions previously available in VM/XA SF focused primarily on Engineering/Scientific use, including support of the 3090 vector facility, and support of CMS use for Engineering/Scientific application programming and execution. VM/XA SP Release 1 has additional functions and permits use of more program products, thereby providing for a wider variety of uses. However, as the set of program products that work in this environment is more limited than those available under VM/SP HPO, one should check that CP supports the products that you are planning to run before de ciding whether is it feasible to migrate to VM/XA SP Release 1. Some functions available in VM/SP HPO are not included in VM/XA SP Release 1. Ifyour operation depends on the use of VM/SP's GCS for native SNA support, you will not be able to migrate to VM/XA SP Release 1. Some enhancements introduced in VM/SP Re lease 5, such as the Transparent Services Access Facility (TSAF), are also not available in VM/XA SP Release 1.
You should also consider I/O device requirements in your installation. All devices used by VM/XA SF have an equivalent or higher degree of function in VM/XA SP Release 1. However, if you are a VM/SP HPO user, you should check that all devices you have in your system will continue to function in the new environment.
Purpose of VM/XA SP Release 1 11 Ifyou are currently running VM/XA SF with multiple guest operating systems, with little or no CMS usage, the considerations on moving to VM/XA SP Release 1 are the same as those for moving to a new release of a product. For a more detailed discussion of migration please refer to "Migration Considerations" on page 67.
Performance
A number of enhancements have been made to VM/XA SP Release 1, including:
• Changes to the scheduler • Re-structuring of some code As a result, the performance characteristics of VM/XA SP Release 1 have been improved when you compare it to VM/XA SF. In the past, VM/SP HPO was the recommended way to provide a "CMS intensive" workload. With the performance changes, it is now possible to provide comparable performance under VM/XA SP Release 1.
12 VM/XA SP Guide Summary of New Features in VM/XA SP Release 1
This section summarizes the major functional characteristics of VM/XA SP Release 1. These characteristics are:
Spool File Limit Relief - allows each user up to 9999 spool files. The previous limit was 9999 in the entire system with VM/XA SF.
• SQL/DS - CP provides the Structured Query Language/ Data Systems (SQL/DS) Program Product with the services it needs to operate. Specifically, the "BLOCKIO system service and Diagnose X'70' are provided. "BLOCKIO in VM/XA SP Release 1 does not handle FBA devices, and SQL/DS in VM/XA SP Release 1 does not sup port data bases on FBA devices (such as the 3370).
• Programmable Operator (PROP) - PROP is functionally compatible with the PROP provided by VM/SP HPO Release 5 with the exception of the PROP/NCCF message interchange. PROP message filters and action files should be re-examined for in compatibilities in command syntax, command responses, and error messages. The Single Console Image Facility (SCIF), also referred to as the Secondary User facility, is also provided (consistent with that provided by VM/SP), to give a secondary con sole access to a virtual machine console.
• Protected Application - allows a new option, CONCEAL, to be added to a user's di rectory entry. This option allows an automatic re-IPL of the virtual machine's oper ating system in case of CP error or virtual machine state changes. This option is normally used only for CMS users.
• Scheduler - the scheduler now schedules workload with a more comprehensive view of system resources, system load, and individual user characteristics. The result is improved system throughput and better response time. • N-Way Support - the user is provided with a single image of the system when run ning on systems with multiple instruction processors. Internal changes have been made to improve performance in this environment.
• System Performance - this enhancement consists of: •A software Last Translated Address Lookaside buffer, which improves the page translation function.
• Additional performance improvements.
• Monitor - VM/XA SP Release 1 includes a monitoring facility similar to the VM/370 monitor implemented in VM/SP and VM/SP HPO, but significantly enhanced to sat isfy user requirements in the VM/XA SP Release 1 environment. Products VMMAP and VM/PPF do not support this monitoring facility.
• User Class Restructure (UCR) - UCR allows for up to 32 user privilege classes. It allows an installation to assign those 32 classes to commands in any way that is appropriate. In practice, for example, the IPL command might be removed from the general user category. This function is similar to the UCR function implemented in VM/SP and VM/SP HPO systems.
Summary of New Features in VM/XA SP Release 1 13 • New DIAGNOSE codes - DIAGNOSE X'20' and DIAGNOSE X'3C' are now compatible with VM/SP HPO. DIAGNOSE X'04' has been changed to examine all real storage, including guest storage. DIAGNOSE X'3C' will now recognize a CP system directory on any CP owned device as VM/SP HPO does.
• Terminal enhancements - 3278 Model 5 and 3290 terminals in native mode can now be used on VM/XA SP Release 1. Additional virtual console functions are provided in addition to enhancements to the local 3270 display device configuration definition. Additionally terminal enhancements are provided which can improve the availability of a system. Installations can add or move displays without necessarily having to reassemble the HCPRIO or re-IPLing. • Printer capability - provides full capability for 3262, 4245, and 4248 printers as dedi cated devices, system spooling devices, virtual spooling devices, CP ABEND and stand-alone dump devices, DDR printers, CP starter system printers, and system load printers. • Message compatibility - the message numbers and message texts of various VM/XA SP Release 1 error messages have been changed to provide greater compatibility with VM/SP HPO. • Four-digit message numbers - VM/XA SP Release 1 has added the capability to produce error messages with a 4-digit code. This format is used only for messages with a number greater than 999, and allows a total of 9999 messages, instead of the 999-message limit that exists in VM/XA SF. • CCW Translation redesign - the function of CCW translation is the same as for VM/XA SF. The modules have been redesigned and restructured.
• Installation execs - a new set of installation execs have been provided to maintain compatibility with VM/SP Release 5.
• Control Blocks IDs - all control blocks that are allocated from system free storage are now provided with an identifier, which allows an easy recognition of the control blocks in a system dump. • Logged-on user limit enhancements - this function is provided to allow installations to set the maximum number of users allowed to log onto the system. The limit can be adjusted to fit the needs of the installation, or the limit can be removed entirely. The CP command SET MAXUsers can be used to adjust or remove the user logon limit. The command Query MAXUsers can be used to display the current limit. The SYSMAXU macro can be used at SYSGEN time to adjust or remove the limit. • Terminal Availability Enhancements - this function allows an installation to move or — add displays without necessarily having to reassemble HCPRIO and regenerate a new nucleus. • Multiple Preferred Guests (MPG) - This function in conjunction with the hardware feature Multiple High Performance Guest Support (MHPG) allows, in addition to the Virtual = Real (V= R) preferred guest virtual machine, 3 additional Virtual = Fixed {V= F) preferred guests.
14 VM/XA SP Guide Summary of New Features in VM/XA SP Release 2
The VM/XA SP Release 2 now support SNA networks. VM/XA SP Release 2 contains the VM/Group Control System (GCS) which supports the installation and operation of ACF/VTAM. These facilities allow VM/XA System Product Guide to control and partic ipate in SNA networks as well as offering native support for SNA devices.
Overview
VM/XA SP Release 2 offers the benefits of VM/XA System Product Guide to those cus tomers requiring native support of SNA networks. This support allows VM/XA System Product Guide to participate in and control SNA networks without requiring a guest such as VM/SP HPO or VSE with VCNA to handle the SNA functions. This support is similiar to that provided initially in VM/SP Release 4 and VM/SP HPO Release 4.
Compatibility
While one of the primary objectives of VM/XA System Product Guide is to provide a growth path for VM/SP customers (with or without HPO), due to factors such as archi tectural differences, full compatibility is not possible. VM/XA SP has made every effort to facilitate this migration by keeping command syntax and responses and message text the same. Common DIAGNOSES are functionally equivalent. Customers considering migration from VM/SP HPO Release 5, should be aware that VM/XA SP Release 2 does not support all of the functions of VM/SP HPO Release 5. For instance, VM/XA SP Re lease 2 does not contain support for Transparent Services Access Facility (TSAF). Refer to the VM/XA SP General' Information manual and the VM/XA SP Conversion Notebook for a complete description of the incompatibilities between VM/SP HPO Release 5 or VM/XA Systems Facility and VM/XA SP Release 2.
Licensed Programs supported:
The following additional licensed programs are supported by the VM/XA SP Release 2: ACF/VTAM Release 3.1.1 or later (5664-280) Netview Release 1 or later (5664-204) NCP Version 4 Release 2 (5668-854)
ACF/SSP 3.2 or later (5735-XXA) RSCS Version 2 Release 2 or later (5664-188)
VM/VCNA (5735-RC5)
Summary of New Features in VM/XA SP Release 2 15 16 VM/XA SP Guide Part 2 - Technical Guide
This part provides a more detailed and technical look at the topics already summarized in "Part 1 - General User Guide".
The following topics are covered: Elimination of growth constraints Functional compatibility and hardware enhancements Performance enhancements Multiple Preferred Guests VM/XA SP Release 1 monitor RAS and usability enhancements Migration considerations
Part 2 • Technical Guide 17 18 VM/XA SP Guide Elimination of Growth Constraints
This chapter describes the ways in which the VM/XA SP Release 1 reduces or eieminates barriers to system growth.
Architectural Constraint Relief
Extended Architecture removes some of the architectural constraints inherent in the System/370 architecture. Principle among the enhanced capabilities of Extended Archi tecture are:
• 31-bit virtual and real addressing (instead of the System/370 24-bit addressing). • A 370-XA I/O subsystem that incorporates System/370 software in microcode, al lowing 370-XA systems to have a faster and more robust I/O subsystem and also allowing off-loading of I/O to the channel.
Many of the future hardware growth-constraint solutions will be available only on Ex tended Architecture. VM/XA SP Release 1 provides a growth path for the VM/SP HPO customer who is exceeding the limitations of the current System/370 architecture.
VM/XA SP Release 1 handles a CMS-intensive environment in 370-XA mode. This allows those customers who have a need for storage constraint relief to migrate to CMS. An additional guide, Bimodal CMS for VM/XA Systems, provides further information on CMS considerations.
Spool File Limit Relief
In addition to the relief provided by CMS and by the Extended Architecture I/O subsys- tem, growth constraint is relieved by increasing the spool file limit.
VM/XA SP Release 1 allows each user up to 9999 files. The number previously allowed for the entire system was 9999.
User spool files are now identified by the userid and a 4-digit spool file identifier, SPOOLID. In previous releases the 4-digit spoolid was unique within the system, and never changed during the life of the file.
The number of spool files allowed in the system is a function of the amount of space al located for the warm-start area. Therefore, the size of the warm start area in your sys tem should be checked to ensure it can contain enough spool file blocks to support your installation. In addition, you may wish to increase the size of your spool area, as you can now have a larger number of files in your system.
The system administrator can limit the number of spool files available for individual us ers through an entry for each user in the system directory.
Spool file handling commands have been extended to include options valid under VM/SP HPO . General users do not see any change in commands they enter. The operator
Elimination of Growth Constraints 19 commands change slightly, since the option SYSTEM can no longer be used with a spoolid to select a specific file. When file ownership is transferred to another user, the file is assigned a new spool file id from the pool of ids available to the receiver.
There are no changes required for the Remote Spooling Communications Subsystem (RSCS) Version 1 Release 3 Program Product, or other program products that handle files sent to virtual machines.
20 VM/XA SP Guide Functional Compatibility and Hardware Enhancements
Important functions of VM/SP Release 5 and VM/SP HPO Release 5 are available In VM/XA SP Release 1. Furthermore, the commands, DIAGNOSE codes, and messages In VM/XA SP Release 1 are upward compatible with those provided by VM/SP Release 5 and VM/SP HPO Release 5 where possible. Architectural and usability considerations require some differences between VM/SP and VM/XA SP Release 1. At the same time, consideration Is given to the migration of VM/XA SF customers. Since the usability features of VM/XASF are. In some cases, superior to the features of VM/SP and VM/SP HPO, the VM/XA SF features are preserved In VM/XA SP Release 1.
Functional compatibility extends to:
• Hardware Processors Devices Software Commands Responses Messages DIAGNOSE Codes Directory Options System Supplied EXECs Virtual Machine Simulation
Functional Compatlbllity
Functional compatibility Is described In the following sections:
"User Class Restructure" "Command and Message Compatibility" "DIAGNOSE Code Compatibility" "SQL/DS" "Protected Application" "System Profile {SYSPROF EXEC)" "Programmable Operator Facility" "Single Console Image Facility"
User Class Restructure
User Class Restructure (UCR) provides an expanded privilege class structure for com mands and DIAGNOSE codes. It also provides a means to dynamically alter the privilege class structure to meet the needs of Individual Installations.
Functional Compatibility and Hardware Enhancements 21 Privilege Classes
The privilege class structure is expanded to allow 32 privilege classes, A-Z and 1-6. The default privilege class structure remains the same as that of VM/XA SF. Several CP commands provide different function and allow different options based on the authority of the user issuing the command. When changing the class for these com mands, the user should refer to them by the IBM-defined privilege class associated with them. Some commands have an IBM-defined privilege class of'ANY'. These commands may be used by any user and the privilege class for these commands cannot be changed. Several CP internal functions are controlled by privilege class. These functions contin ues to be controlled by class; however, the class may be assigned at system generation time by means of the SYSFCN macro in HCPSYS ASSEMBLE. The privilege classes for these functions may then be changed by using the SYSFCN macro and the OVERRIDE command. The functions and the default classes are as follows:
Authorization to logon as the primary system operator {Class A) Authorization for intensive recording (Class F) Authorization to issue Diagnostic Load/Write or Sense/Read command (Class F) Authorization to issue the Buffer Unload command (Class F) Authorization foriOCP Read (Classes C and E) Authorization for lOCP Write (Class C)
Changing Classes
The installation may alter the privilege class structure at any time. Alterations are made by preparing a file that contains the commands and the new privilege classes, and then issuing the OVERRIDE command. The changes may be made to take effect immediately, or may be delayed until the next IPL occurs.
When the OVERRIDE command is invoked to store a new privilege class structure, a DI AGNOSE code is invoked to store the new data. This data is then stored in a new type of System Data File known as a User Class Restructure File (UCR). New commands, QUERY and PURGE UCR, operate on the files either by file number or by queue type.
The new privilege class structure is defined in a CMS file called a CLASS OVERRIDE file. The default name of this file is CLASS OVERRIDE, but it may be given any filename and filetype. The file contains a list of all the CP commands and DIAGNOSE codes whose privilege classes will be changed.
Some commands have more than one IBM-defined privilege class associated with them. To change the class of these commands, the CLASS OVERRIDE file must show which version of the command is being changed by specifying the IBM-defined privilege class of the command whose class is being changed.
Some commands and DIAGNOSE codes have a privilege class of 'ANY'. 'ANY' indicates that all users may issue these commands and DIAGNOSE codes. The privilege class of these commands may not be changed.
All DIAGNOSE codes that were previously classified as class G DIAGNOSE codes are now defined as class ANY. In this way, an installation may protect end-users from as many CP commands as they wish without fear of'locking them out' of the DIAGNOSE codes that CMS requires. The privilege classes for the CP internal functions may be changed by using a SYSxxxx statement in the CLASS OVERRIDE file, where xxxx is the name of the function. They may also be specified by means of the SYSFCN macro in HCPSYS ASSEMBLE.
The OVERRIDE command processes the CLASS OVERRIDE file. There are options to check statements for correct syntax, to revert to the IBM-defined privilege classes, or to
22 VM/XA SP Guide write the file in its internal format and have the changes take effect immediately. If no options are specified, the file is converted to its internal format and written to a System Data File (SDF), but the changes will not take effect until the next IPL occurs.
Directory
Since the number of privilege classes has increased from eight classes to 32, the direc tory has changed to allov/ up to 32 classes for any user. The privilege classes for a user may be specified on the USER control statement as be fore. However, since a user may have many classes, it is possible that all the classes may not fit on one line in the file. For this reason, a CLASS statement may be included for the user instead of specifying privilege classes in the USER statement. The classes to be assigned to a user may be specified on either the USER statement or the CLASS statement. Of course, a class may be specified only once for each user. The classes need not be specified in any specific order on the statement, however, each class may appear only once.
Commands a User May Issue
The QUERY COMMANDS command displays, for a user, the commands and DIAGNOSE codes the user is authorized to issue. The QUERY COMMANDS command is a class ANY command, which means that all users are authorized to issue this command, and its class cannot be changed. For compatibility with VM/SP HPO, this command may be entered without the QUERY prefix.
Command and Message Compatibility
Increased compatibility between VM/XA SP Release 1 and VM/SP HPO Release 5 is provided in the area of command syntax and response. There are instances where compatibility is not possible due to factors such as architecture, overall CP design, or significantly improved usability. For most message numbers issued by both VM/XA SP Release 1 and VM/SP HPO Re lease 4.2, the message texts will be identical. Exceptions have been made when in compatibilities are necessary because of architectural differences or to maintain the superior usability features of VM/XA SF. Certain differences are of a global nature and exist throughout VM/XA SP Release 1: • Commands are considered compatible if the only difference is a 4-digit device number in the response. Due to the differences in the I/O architectures, VM/XA SP Release 1 uses 4-digit device numbers, instead of three-digit device addresses in VM/SP and 3-digit virtual device addresses in VM/SP HPO. • Commands are considered compatible when the privilege classes are not the same. The privilege class required to invoke a particular CP command may not always be the same in VM/XA SP Release 1 as it is in VM/SP HPO. A message in VM/XA SP Release 1 may have the same number and text as in VM/SP HPO, but the action indicators may be different. There are cases when a message is considered compatible if the action indicators are not the same. VM/XA SP Release 1 and VM/SP have different guidelines for action indicators.
When an incorrect command is issued in VM/SP HPO and the same incorrect com mand is issued in VM/XA SP Release 1, the same error message might not result.
Functional Compatibility and Hardware Enhancements 23 and therefore the same non-zero CP return code might not be provided in each case. The majority of these situations occur in cases of incorrect syntax.
DIAGNOSE Code Compatibility
The DIAGNOSE codes provided in VM/XA SP Release 1 are functionally compatible with those in VM/SP HPO Release 5 except as differences in architecture require. In some cases, the privilege class required to invoke a particular DIAGNOSE code may not al ways be the same in VM/XA SP Release 1 as it is in VM/SP HPO.
Three DIAGNOSE codes are enhanced in VM/XA SP Release 1 to provide increased compatibility with VM/SP HPO Release 5:
• DIAGNOSE X'04' (Examine Real Storage) will now examine user pages in storage as well as CP pages.
• DIAGNOSE X'20' (General I/O) will now accept a valid CCW chain for a unit record device as well as for tape and disk.
Note: DIAGNOSE X'20' can be used only in a 370-mode virtual machine. • DIAGNOSE X'3C' is unchanged from VM/XA SF Release 2; however, this DIAGNOSE will now bring a directory online if and only if: 1. It is on the same volume on which the directory was found at CP initialization time, or 2. No directory has yet been found, and the given directory is on a volume that is currently CP-owned. (In previous releases, criterion (1) always referred to the system residence volume.) VM/XA SP Release 1 now recognizes a CP system directory on any CP-owned vol ume. At system initialization time, CP checks for a valid directory on the system residence volume. If found, CP uses that directory; otherwise CP checks every other CP-owned volume that is brought online at initialization time, in the order of their appearance in the SYSCPVOL list of HCPSYS, and uses the first directory found. As in previous releases, if no valid directory is found, the system creates a dummy operator userid, which can then be used to create a valid directory. In this case, a directory can be brought online: 1. By running the directory utility to install a directory on a CP-owned volume, or 2. By attaching to the system a volume with a valid directory, whose name ap pears in the SYSCPVOL list, but which was not brought online at initialization time. Once CP has brought a directory online, the volume on which it resides remains the directory volume for the duration of the VM/XA SP Release 1 IPL. Rewriting a di rectory on a different volume, even one higher in the search order, will have no ef fect. (However, a directory written higher in the search order will become effective at the time of the next hardware IPL or software re-IPL.) More information on DIAGNOSE codes may be found in "Appendix B. DIAGNOSE Codes" on page 83.
SQL/DS
The Structured Query Language/Data Systems (SQL/DS) is a relational data base man agement system. VM/XA SP Release 1 provides all the services that SQL/DS Version 2
24 VM/XA SP Guide Release 1 is using on VM/SP HPO Release 4.2. VM/XA SP Release 1 does not provide the Transparent Services Access Facility and therefore this facility can not be utilized by SQL/DS Version 2 Release 1.
All CP commands, DIAGNOSE codes, and other functions used by SQI_/DS Version 2 Release 1 are made available in VM/XA SP Release 1. The DASD Block I/O System Service is required for SQL7DS Version 2 Release 1 and is available in VM/XA SP Re lease 1.
DASD Block I/O System Service
The DASD Block I/O System Service is a CP system service. It provides a virtual ma chine with device-independent access to its virtual DASD devices. Device types sup ported are the Count Key Data (CKD) devices: 3330, 3333, 3340, 3344, 3350, 3375, and 3380. {Device 3333 is formatted as a 3330, and device 3344 is formatted as a 3340.) The Fixed Block Architecture (FBA) devices (3310 and 3370) can not be utilized by SQL/DS as these devices may be dedicated only to a virtual machine with VM/XA SP Release 1.
The CMS RESERVE command and the CMS DISKID function should be issued before using the DASD Block I/O System Service. These two facilities enable you to create a uniquely organized CMS file on a DASD and obtain information about the file needed to use the DASD Block I/O System Service.
DASD Block I/O System Service uses lUCV to set up communication between itself and a virtual machine. No special authorization is required for a virtual machine to use the DASD Block I/O System Service. The maximum connection (MAXCONN) limit in the di rectory can be enlarged to satisfy the user's requirements. The DASD Block I/O System Service allows connections from any user.
Protected Application
A protected application environment is provided to prevent an interactive user from ac cidentally entering the CP environment. The user is placed in a protected application when the SET CONCEAL ON command is issued, or at logon if the user's directory contains the new option CONCEAL. When the user is operating in a protected application:
• Multiple attentions do not cause the user to enter CP mode.
• TERMINAL BREAKKEY is set to the new option NONE.
• CP initiates an automatic re-IPL when it finds errors such as virtual machine disa bled wait, paging error, invalid PSW, external interrupt loop, program interrupt loop, and translation exception. • If a shared page is altered, CP attempts to resume execution in the virtual machine before initiating an automatic re-IPL.
• The error diagnostic information, provided by DIAGNOSE code X'BO', is not dis played on the screen. DIAGNOSE code X'BO' lets a virtual machine access diagnostic information saved for a user running in a protected application environment, for whom a re-IPL has been at tempted. This information consists of the information normally displayed for one of the following errors: shared page altered, virtual machine disabled wait, paging error, invalid PSW, external interrupt loop, program interrupt loop, or translation exception.
Functional Compatibility and Hardware Enhancements 25 System Profile (SYSPROF EXEC)
The system profile Is an exec, SYSPROF EXEC, containing part of the CMS initialization function previously done in a module. It can be invoked by default during CMS initial ization, before any user disks are accessed. Therefore, an installation can use it to tailor the CMS environment. In tailoring an environment, an installation can do such things as access additional system disks or bring up application programs automatically. Make tailoring decisions based on userid, responses to prompting, CMS parameters on the IPL command, or other conditions defined by the installation.
By having this initialization function in an EXEC rather than in a module, an installation can easily change the default CMS environment for its users without having to modify a CMS module and rebuild CMS. In addition, there is no requirement to modify PROFILE EXECs and depend on users not to change the execs provided.
The system profile can be bypassed by using the NOSPROF parameter provided on the IPL command.
The CMS initialization module calls the SYSPROF EXEC and executes it from a DCSS (Discontiguous Saved Segment), or from the S disk or its extension. This is done before any user disk is accessed. The SYSPROF EXEC executes by default when you enter the IPL CMS command, unless:
• You specify the NOSPROF parameter on the command line
• You are IPLing a non-DASD device
• No SYSPROF EXEC is found.
Default Functions
The following default functions are in the supplied SYSPROF EXEC:
Process the parameters passed on the IPL command.
Display the CMS system identification (system ID) defined when the CMS system was built.
Issue the initial console read.
Handle the first command entered at this read.
Access the 191 disk as the A-disk.
Access the 192 disk as the D-disk.
Issue the S-STAT/Y-STAT messages.
Issue other initialization related messages.
Execute the PROFILE EXEC if the user has one.
These default functions are identical to those in VM/SP Release 5. CP provides restart information when it re-IPLs for a protected user who has dropped into CP. (See "Protected Application" on page 25.) This information shows the nature of the problem and is availatile to the system profile. The system profile issues a mes sage when this condition is detected. The installation can choose a different action by modifying the exec.
The IPL CMS command can be placed in the user's directory entry or the command can be issued after the user logs on.
26 VM/XA SP Guide Building a Protected Application Environment
Ifthe user's only interest is in using application programs, a protected application envi ronment can be built. In this way, the user is automatically placed in the protected ap plication environment at logon time, and cannot inadvertently drop into CP.
Examples of Initialization Functions
The SYSPROF EXEC can perform the following functions at initialization, among others: • Recognize of new parameters in the PARM field of the IPL command. For example, the installation can add the following IPL statement in a user's directory:
IPL CMS PARM ISPF
The installation can then recognize this parameter and set up an ISPF environment for the user. • Access additional system disks, or change provided defaults. The default user disks (191 A-disk and 192 D-disk) can be changed or eliminated, or additional user disks can be accessed. • Recognize specific users or groups of users for placement Into an application or other environment. • Suppress of the initial console read or change the default to AUTOCR. • Prompt novice users for information. • Modify or suppress certain system messages, such as the CMS system ID, to hide complexity of the system. • Handle conditions when protected users enter CP and are re-IPLed. For example, a message can be sent to the system administrator.
Programmable Operator Facility
The Programmable Operator Facility (PROP) is designed to increase the efficiency of system operation and to allow remote operation of systems in a distributed data proc essing environment. It does this by intercepting all messages and requests directed to its virtual machine and by handling them according to pre-programmed actions. It de- termines whether a message is to be simply recorded for future reference, whether the ^ ^ message is to be acted upon, or whether the message is to be sent on to the operator to handle. PROP is functionally compatible with the PROP facility provided by VM/SP HPO Release 5 with the exception of PROP/NCCF message interface, that is not available in VM/XA SP.
Use in a Single System
When PROP is operational in a single-system environment, it can: • Reduce message traffic to the operator by: • Filtering (logging) non-essential, information-only messages. • Routing messages (for example, I/O intervention requests) to someone else for specialized action.
Functional Compatibility and Hardware Enhancements 27 • Increase productivity, by freeing the system operator from certain routine responses or tasks. Such responses (whether they consist of one or a series of commands, whether VM/XA BP Release 1 or guest operating system) may be pre-programmed to execute automatically upon receipt of a given message. Thus, only essential, non-routine messages (that is, those requiring the skill and experience of a system operator to handle) are sent to the operator for response or action.
Use in Distributed VM/XA SP Release 1 Systems
The capabilities of PROP, outlined above, also allow for the remote operation of systems in a distributed VM/XA SP Release 1 environment. When PROP is operational in a dis tributed VM/XA SP Release 1 system, it can: • Issue responses and perform tasks that do not require an on-site operator. • Filter (log) non-essential, information-only messages. • Route messages requiring on-site (that is, manual) intervention to someone, not necessarily an operator, at the distributed site for action. • Route messages that require the skill and experience of a system operator to handle to the operator at the host system. The operator at the host site can also send commands to PROP to control its operation, as well as commands to execute on the distributed system to control the system itself. By running PROP on VM/XA SP Release 1 systems distributed at several different lo cations (network nodes), one operator at a host site can control a network of systems.
Single Console image Facility
The Single Console Image Facility allows one user logged on to a single virtual machine to control multiple disconnected virtual machines. CP prefixes any output coming to the controlling virtual machine with the userid of the originating virtual machine. The con trolling virtual machine communicates with the virtual machines it is controlling through the CP class G SEND command. The user whose virtual machine is being controlled is the primary user. The user whose virtual machine controls the primary user's virtual machine is the secondary user. The secondary user may run disconnected if there is a valid path to the lUCV Message Sys tem Service. To enable a virtual machine to use the Single Console Image Facility, the installation must specify the userid of the secondary user on the CONSOLE directory control state ment of the primary user. When the primary user disconnects his virtual machine and the secondary user is logged on, the secondary user receives control of the primary user's virtual machine. Even if the secondary user is not logged on when the primary user disconnects, the secondary user receives control of the disconnected virtual machine whenever he does logon. The primary user can regain control of his virtual machine at his own terminal by entering the LOGON command. After the primary user disconnects, all console output from the disconnected virtual ma chine appears on the console of the secondary user if he is logged on. Output from the primary user's disconnected virtual machine is prefixed with the userid of the primary user. The secondary user uses the CP SEND command to communicate with the primary us er's disconnected virtual machine.
28 VM/XA SP Guide The example In Figure 3 shows the way the Single Console Image Facility works. The primary user (GUESTSYS In the example) Is running disconnected and the CONSOLE directory statement for GUESTSYS Indicates that the userld OPERATOR is the secondary user for GUESTSYS. Any messages appearing on the virtual console for GUESTSYS are displayed on the virtual console for OPERATOR with a prefix of GUESTSYS.
The secondary userld {OPERATOR In the example) can communicate with the primary user by using the SEND command.
SEND secondary-userid command/reply
To the primary user, any commands or replies entered by the secondary user using the SEND command appear to have been entered on the secondary user's console. To Issue a CP command on the primary user's console, enter the SEND command In the format:
SEND CP secondary-userid command
Primory User Secondary User (Disconnected) (Logged On)
Userid: GUESTSYS Userid: OPERATOR
Virtual Console Output ^ GUESTSYS Virtual Consale ' Output
Cominand or Reply SEND GUESTSYS Command or Reply
CP
Figure 3. Single Console Image Facility
Hardware Enhancements
Hardware enhancements are described In the following sections:
Display Support Improvements" 'Printer Enhancements"
Display Support Improvements
Display support Improvements are compatible with functions provided in VM/SP HPO Release 4.2. Principally, however, terminal support Improvements apply to system characteristics, additional virtual console functions, and additional hardware support over VM/XA SF Release 2.
3290 Information Panel
The 3290 Information Panel, which uses a plasma panel as a display screen. Is capable of displaying 9920 characters. The 3290 uses the 3270 data stream and Interacts with host programs written for the 3270 displays. Also, the 3290 supports the Multiple Inter active Screens and Multiple Copy Screens functions. These functions allow the user to
Functional Compatibility and Hardware Enhancements 29 benefit from the larger 3290 screen, while using existing 3270 host programs as well as new programs. The Multiple Interactive Screens function allows the 3290 to operate as up to four logical displays, each interacting independently with its own host program. Each logical display appears to the host control program as a separate device address. The Multiple Copy Screens function allows the 3290 operator to initiate a copy of the active screen to one of up to three copy screens and to retain the copies for reference. With new or modified 3270 host programs, the 3290 displays large screens and multiple (up to 16) partitions, with or without vertical scrolling. VM/XA SP Release 1 recognizes changes in screen size and modifies screen addressing as appropriate. Since the screen size may be configured to almost any dimension, CP permits dimensions from the largest size (62 rows of 160 characters) to a minimum of three rows of 50 characters. This minimum size allows for an output area, an input area, and a status area.
3278 Model 5 Display Station
The IBM 3278 Model 5 Display station can operate with a screen size of 24 rows of 80 characters or 27 rows of 132 characters. Other than screen size, the 3278 Model 5 op erates as any other 3278. VM/XA SP Release 1 provides for the use of the alternate screen size (27 rows of 132 characters) in addition to the standard size of 24 rows by 80 characters.
APL and Text
APL/TEXT characters defined in the TERMINAL TABCHAR command can be translated. APL/TEXT characters for PF DELAY are allowed.
Output Batching
Output lines from CP command processors and basic CMS commands (line mode only) are "batched" so that as few START SUBCHANNEL (SSCH) instructions as possible are used.
System Generation for Displays
The RDEVICE macro accepts 3290 as a device type. Internally, however, a 3290 is re presented as a 3278/3279. In addition, the RDEVICE macro accepts the MODEL = 5 op erand for a 3278 display. A new device type of '3270' has been added as a generic device type for any local 3270 display except for 3277. The requirement to specify the model operand for local 3270 displays on the RDEVICE macro is now optional. If the model number is not specified, the display characteristics are set to a Model 2. CP attempts to determine the real local display device character istics during terminal initialization processing and set the real device descriptor block (RDEV) accordingly. Terminal initialization processing for local display devices occurs when either CP receives an unsolicited device end for an enabled display device or when the ENABLE command is issued for a powered on display device that is currently disa bled. This feature allows an installation to move or add displays without having to re assemble HCPRIO. CP uses the Write Structure Field - Read Partition (Query) Structured Field (WSF) CCW command to determine the display device characteristics. If the WSF command is re jected, a READ BUFFER command is issued for a maximum screen size count, and the
30 VM/XA SP Guide screen size Is determined from the residual byte count in order to set the display device characteristics. The latter operation is necessary for those control units and 3270 Display Devices that do not accept the WRITE STRUCTURED FIELD command.
Virtual Console Display
The TABCHAR option has been added to the TERMINAL command. TABCHAR option allows user-defined tab characters. The TABCHAR value in effect is added to the QUERY TERMINAL response.
Printer Enhancements
VM/XA BP Release 1 provides support for: • The 3262 Model 5 in 3262 Model 1 compatibility mode and 4248 compatibility mode, • The 4245 in 3262 compatibility mode,
- • The 4248 in 4248 mode or in 3211 compatibility mode.
These printers can now be utilized as:
• Dedicated devices. System spooling devices {including the use of the extended functions and full error recovery). Virtual spooling devices. • CP ABEND and stand-alone dump devices. • DASD Dump Restore (DDRXA) printers. • CP starter system printers. • System loader printers.
^ The affected commands and macros are as follows:
• The START command allows the specification of an image library, FCB, and char acter set for impact printers. The operator may now specify the FCB and character set to be loaded and start impact printers with a single command (START), rather than with three commands (LOADBUF FCB, LOADBUF UCS, and START). This change provides the operator with one command set to operate all spooling printers.
START also accepts a new FOLD/NOFOLD option for impact printers only. It controls whether lowercase characters are translated (folded) into uppercase characters for output. This option corresponds to the FOLD/NOFOLD option on the LOADBUF r") command.
Note: For the sake of compatibility with existing impact printer terminology, UNFOLD will be accepted as the equivalent of NOFOLD.
In addition, for 3211 printers only, the START command accepts a new INDEX option, corresponding to the existing INDEX option on the LOADBUF command.
The response for the START command for impact printers now has an additional third line that displays the image library, FCB, and character set being used. This line will not appear for 1403 printers that do not have the universal character set feature installed.
• The LOADBUF command is used to load Forms Control Buffers (FCBs) and character sets on real impact printers. This command becomes obsolete since the functions it provides have been added to the START command to allow an operator to specify the FCB and character set to be loaded and to start an impact printer with one command. The LOADBUF command will still be maintained for the sake of com patibility.
Functional Compatibility and Hardware Enhancements 31 The response to the DRAIN command for impact printers is being changed to add a third line that includes the image library, character set, and Forms Control Buffer being used. The response will not be displayed for 1403 printers that do not have the universal character set feature installed.
The response to the QUERY UR command for impact printers now has a third line that includes the image library, character set and Forms Control Buffer being used. This third line of response will not be displayed for 1403 printers that do not have the universal character set feature installed. This is a useability improvement over VM/SP, VM/SP HPO, and VM/XA SF, which have no way to query the FCBs and character sets in use by impact printers.
The HCPFCB, HCPUCC, HCPUCB, and HCPUCS data areas are deleted since all of the FCBs and character sets that these contained are now contained in image li braries. Because of this change, the FCBs and character sets can now be added, changed, and deleted without requiring a system generation. The macros UCSI and UCStCCW are added to replace the previous UCB, UCC, and UCS macros.
The FCB macro has been modified to include the extended 4248 FCB. The extended FCB macro is used if the 4248 printer employs features of the extended FCB. (These features include producing a duplicate copy of a printed line to the right of the ori ginal line, varying the printer speed, controlling paper stacker levels, and controlling paper stacker drop rates.) If the user does not need the added features of the 4248 the macro is codes as it exists for VM/XA SF.
The LOADVFCB command is used to specify the forms control buffer image for a virtual spooled 3203 or 3211 printer. This command now includes the optional image specification and supports the new 3262, 4245 and 4248 printers.
Note: Use the START command or the LOADBUF command to load the forms con trol buffer (FCB) with a specified image for a real printer.
The QUERY VIRTUAL PRINTER command is used to display the status of all virtual printers. The syntax of this command has not changed. The response to this com mand has been changed to include the new 3262, 4245, and 4248 device types.
The QUERY VIRTUAL UNIT RECORD command displays the status of all unit record devices - printers, punches, and readers. The syntax of this command has not changed. The response has been changed to include the new 3262, 4245, and 4248 device types.
The DEFINE SPOOLING device command is used to add a virtual spooling device to your virtual machine configuration.
32 VM/XA SP Guide Performance Enhancements
The performance of VM/XA SP Release 1 can be viewed from two perspectives; guest performance {where VM/XA SP Release 1 is used primarily for the production, testing and maintenance of guest operating systems such as MVS/XA and VSE) and CMS in tensive environments, which include interactive as well as CMS based production appli cations.
Guest performance will be similar to that experienced under VM/XA SF.
For CMS intensive environments that have been experiencing growth constraints due to System/370 limitations, VM/XA SP Release 1 offers greater capacity through exploitation of storage greater than 16 megabytes, the VM/XA I/O subsystem, and single-image ca pability for multiprocessing systems such as the 3090 Model 400.
For currently unconstrained CMS environments, VM/XA SP Release 1 performance should approach that of VM/SP HPO Release 5.
In this chapter, we will discuss:
• Changes to the performance characteristics • Changes to the Scheduler
In addition, VM/XA SP Release 1 provides monitor data to the user. This data enables you to gain more information about how your system is performing. The monitor is dis cussed in "Monitor Facility" on page 57.
For VM/SP HPO customers, the primary objective in VM/XA SP Release 1 is to provide a growth path (storage, I/O support, n-way processors) to 370-XA capabilities.
Performance Characteristics f 1 Modifications fiave been made ttiat change tfie performance characteristics of the VM/XA SP Release 1 system from those of VM/XA SF. Many of these changes are not obvious to the user and have been achieved through internal improvements. These enhance ments include:
• Scheduler Changes.
These changes should improve system throughput and response times.
• Software Last Translated Address Lookaside buffer.
This is an enhancement to the virtual address translation function of VM/XA SP Re lease 1. When a virtual address translation is requested, the input data is compared with data saved from the previous virtual address translation performed by this processor. If the segment table origins are the same, and the virtual addresses are contained in the same page, the real address is calculated by simply adding the byte offset to the frame address. Previously, each virtual address translation was per formed afresh.
Performance Enhancements 33 • Terminal Enhancements.
Output lines from CP command processors and basic CMS commands are "batched", so fewer START SUBCHANNEL commands are used. This should im prove terminal I/O performance, and improve performance in CMS intensive envi ronments.
• Streamlining the entire page fault processing path.
A new fast path for page fault processing reduces the overhead to process a page or segment fault from SIE interrupt to redispatch.
• Minimizing the amount of code located in the linkage routines, and providing fast paths for each type of linkage.
In VM/XA SF, many decisions have to be made whenever one entry point transfers control to another entry point. VM/XA SP Release 1 enhances the information available to the linkage macros so that many of those decisions are now made at assembly time.
• Providing a self-contained processor local savearea manager.
Processor local lists of saveareas are now maintained to provide high performance dynamic linkage.- Saveareas are allocated on cache boundaries. • Saving the condition code for dynamic returns only when a condition code is re turned.
RAS considerations recommend that return codes and not condition codes be passed from a called routine to its caller. In addition to the RAS recommendation, performance is improved when condition codes are not saved during a dynamic re turn.
Scheduler
Improvements incorporated in the VM/XA SP Release 1 Scheduler address:
• The management of a CMS-intensive environment by providing consistently fast re sponse time for interactive users.
• An increase in overall system throughput. Before any discussion of Scheduler topics (which often includes a great deal of jargon) it is important to define a few commonly used terms: Resource One of the system components that is shared between the users. Typi cally these components would be CPU, Paging, Storage or I/O. This Scheduler does not include I/O in its calculations. Eligible list A queue in which your virtual machine waits for enough resource to be available to be considered for dispatching. Dispatch list The queue where your virtual machine is kept for the duration of an elapsed time-slice, where you actually consume resource (run). Dormant list The queue where your virtual machine waits when it is idle. Time-slice A period of time. There are two distinct types of time-slice:
Minor (or Dispatch) A system-wide value based on processor speed. It is used to
34 VM/XA SP Guide determine the real CPU time that you will consume before being re-prioritized in the dispatch list. Major (or Elapsed) The amount of real time that you will be allowed to remain on the dispatch list.
Hotshot A very short, high priority burst of service. The Hotshot service is given to you when you interact with the terminal while already processing a transaction. This is to allow you to enter commands such as "IND LOAD" or "DISPLAY PSW" to check on progress. (You might consider this to be a "nice warm feeling" type of command!) Share Percentage or ratio of a system resource that a you are entitled to con sume.
Transaction Basic unit of work. A transaction is usually the exchange that occurs between your pressing the ENTER key at your terminal and the processor responding.
Interactive Usually you would be considered as interactive if you were a CMS user entering commands at a terminal. The characteristic of interactive com mands is that they normally arrive at random, are unpredictable in con tent, b.ut tend to be short-running. Previously the VM/XA SF Scheduler monitored only two resources: CPU and storage. The VM/XA SP Release 1 Scheduler schedules other resources. In VM/XA SP Release 1, scheduling of the paging resource is added, and the existing scheduling of storage and CPU resource have been improved. Changes have been made to:
Improve existing scheduling policies by introducing a working set size growth limit. This allows the Scheduler to detect and control high storage consumers. • Improve the Scheduler's interface to Real Storage Management, improving the management of the storage resource. This should decrease the likelihood of thrashing and gain more efficient use of storage.
• Improve handling of interactive users: • Implement multiple eligible lists (similar to those of VM/SP HPO). • Implement "interactive buffers" of Scheduled resources. This reserves some amount of a resource for interactive users. • Provide external controls to "tune" the amount of reserved resource:
SET SRM STORBUF SET SRM LDUBUF SET SRM DSPBUF
Note: These commands are discussed in more detail in "Control of the Re sources by the Scheduler" on page 38. • Pre-empt long-running work for interactive work in extreme cases of storage contention. Resource SHARE management. In VM/XA SF, directories "SHARE" applies only to the CPU resource. VM/XA SP Release 1, however, applies "SHARE" to the current resource bottleneck, which might be CPU, storage, or paging. (This is similar to VM/SP HPO's implementation of priority). As a result, "ABSCPU" is no longer a valid type of SHARE specification. Consider expanded storage in its scheduling algorithms when some or all of the expanded storage is in use by CP. Implement a "QUICKDSP" function, which provides specified users with a fast path to the dispatcher (similar to HPO's "SET FAVORED" without a percent).
Performance Enhancements 35 Overall Design
The Scheduler manages resources by maintaining users in three lists:
Dispatch list Eligible list Dormant list
The Scheduler moves users between these lists as their status, or resource consump tion, changes, as shown in Figure 4. As a user you would start in the dormant list. Then, when you have work to do, you are moved into the eligible list. Here you are prioritized for entry to the dispatch list. As resources becomes available, you are moved to the dispatch list. When you reach the head of the list you are given CPU resource to consume.
Dormant Logon Logoff
User becomes runnoble
...but in 0 voit stote
Resource limit Exceeded... ..but reody ^
Dispatch Eligible
'i Hinor Tiiae-sl ice end I(Recolculotes jpriority)
E-list Selection
Figure 4. Use of Queues by the Scheduler
Dormant List
You reside in the dormant list when you are not executing transactions. While you are dormant you play no part in the scheduling process. Normally you would expect to find that the dormant list is by far the largest list. While you are dormant, a flag is set that indicates that your pages may be taken for other users, if it becomes necessary.
36 VMfXA SP Guide Eligible List
From the dormant list you enter the eligible list (by entering a command) and thus be coming ready to run (see Figure 5). Your eligible list entry belongs to one of a number of classes:
EO You use this class if you are "just passing through" and do NOT wait for re sources to become available, (an example would be if you run with QUICKDSP set, or if you were a "hotshot" transaction, or if you are the V= R virtual machine.)
E1 You use class 1 with transactions that are expected to be short. This is where you go when you first enter the eligible list.
E2 If you have completed a stay in the dispatch list, but have dropped back to the eligible list because your time slice expired, you become a class E2 entry. You are now considered to be running a medium length transaction.
E3 If you complete a stay in the dispatch list and your time slice expires without you completing the transaction, you are classified as E3. You are now a long running transaction.
These classes are not separate lists, they are just classifications of the entries within the eligible list.
(liir Ritirii Uiir latiri IrM Oiipitek Hit (r«n BortiMBt Hit
i: ICIiii E»l Still iicifTl
Cileilitf E-liil f. Priirtti ^ El-iilei V^CwipliliSfJ
Silicl liir froa lilt ICIaii Ell
Cilcaliti D-liit I Pirmit I Priiriti, EIimi' T-illti. Pm efiftli.
Kit* liir t» OiiMtct lilt
Figure 5. Use of Eligible List by Scheduler
Dispatch List
When adequate resources are available for you to run, you are moved into the dispatch list (See Figure 6). You remain here for a period of time defined by the Scheduler and corresponding to the eligible list classification you had. For example, if you were an E1 user, you become a Q1 user and you would get a short time-slice. Whereas if you were an E3 user, you become a Q3 user and you would get a longer slice. Your stay in the dispatch list is broken down further into "minor time-slices" (the length of this slice depends on the processor speed and on the CPU time consumed).
Performance Enhancements 37 Eitir P-liit froi E-liit 1 Salad flril ruanabia aiar 1 iiapatcb Piar far Hlaar Una allta
Ricilciloto Prioritv I idjiii oin Hiior tino-iliei ii4
la rot liliri ti Traaaaetloi Elopoid tlai- Ckick root Eliiikit lilt eoB^lili 1 ilieo Old f ottk Oil too
litiri to OfliMol Hit
Figure 6. Use of Dispatch List by Scheduler
As each minor time-slice completes, your priority within the dispatch list is recalculated. Whenever you reach the head of the dispatch list, you are dispatched for a minor time- slice. You will probably receive a number of these minor time-slices before the elapsed time-slice expires and you are moved out of the dispatch list. When you are moved out of the dispatch list, the Scheduler looks at your transaction, and if it is complete, you are dropped to the dormant list; otherwise you go back to the eligi ble list (See Figure 5).
Control of the Resources by the Scheduler
The commands discussed here are available to help control the way that the Scheduler allocates resource to virtual machines.
SET SHARE
userid Specifies the target share of the available resource that should be allocated to the specified user. There are three variations to this command:
ABSolute nnn% The user is to receive "nnn%" of the scheduled system resources (CPU, paging, and storage).
RELative nnnnn The user is to receive a relative share of "nnnnn". This is an al location of the system resource remaining after the absolute shares have been allocated. If no share is allocated, it defaults to relative 100 (the possible range is 1-10000).
INITial Tells the Scheduler to reset the user to the share value specified in the directory. This would probably be used after the SHARE has been changed, using operator commands, to provide a temporary performance boost.
Note: The VM/XA SF command SET SHARE userid ABSCPU form of this command is no longer used. If it is used a warning mes sage is issued.
38 VM/XA SP Guide SET SRM STORBUF Allows you to influence the Scheduler's policy concerning the al location of the storage resource to users. The command sets im aginary boundaries in the available storage, one for each of the classes E1, E2, and E3. These are referred to as "storage buffers".
The Scheduler maintains an estimate of your working set size (WSS). Before you are added to the dispatch list, the Scheduler checks that your projected WSS will fit into the storage buffer that has been allocated for your E-class (see Figure 7). Some storage is reserved for E1 users. It reserves another portion for El and E2 users and the remainder is available for E1, E2, and E3 users. The percentage of these 3 groups are, respectively, the first, second, and third percentages given on STORBUF. Assume the values are 100%, 80%, and 70%. When the scheduler is considering putting an El user in the dispatch list, it ensures that this user's storage plus the storage of all other users already in the dispatch list Is not greater than 100% of the available storage. For an E2 user, its storage plus the storage of all all dispatch list users must not be greater than 80% of the available memory.
Storage Buffer Allocotion
Et Users
STORBUFEl boundorjf ^ E2 Users
E2
• r t.t ;.T .t, STORBUF boundary E3 Users 75
E3 STORBUF boundory 45
Figure 7. Storage Buffer Allocation
Performance Enhancements 39 SET SRM LDUBUF Influences the system's paging resource. If you have recently ex perienced some high paging rates during your dispatch list stays, the Scheduler would classify you as a "loading user". Three loading limits are maintained: 1. Total number of class 1, 2, and 3 loading users allowed in the dispatch list.
2. Total number of class 2 and 3 loading users allowed in the dispatch list. 3. Total number of class 3 loading users allowed in the dispatch list.
The Scheduler limits the number of loading users allowed in the Dispatch list in order not to over-utilize the Paging subsystem.
SET SRM DSPBUF Controls the multiprogramming level (MPL). This command con trols resources in general and is not as specific as either SET SRM STORBUF or SET SRM LDUBUF. Specific controls are desirable, but for the CPU and general I/O resources, VM/XA SP Release 1 does not have specific control over the MPL, and SET SRM DSPBUF can be used to control the MPL and the concurrent de mand for a bottlenecked resource {CPU or I/O) by controlling the number of concurrent users. The command allows you to control the MPL for each transaction class (Q1, Q2, Q3). These three numbers establish the maximum number of users allowed on the dispatch list from each transaction class.
SET SRM lABIAS Allows you to control the "Interactive Bias". The interactive bias is a means of "front loading" service for a transaction. When you first enter the dispatch list, the Scheduler artificially improves your position in the dispatch queue. This inriprovement is allowed to fade away over a number of minor time slices. If you did not complete the transaction within the biased period, you are penal ized by being repositioned in the queue to where you would have been had the bias not been applied. This keeps the scheduling algorithm both fair and correct.
SET QUICKDSP Signifies that the specified user has critical response time re quirements. If you are a user with QUICKDSP set ON, you are al ways moved straight to the dispatch list, bypassing the eligible list, whenever you become ready. This means that you become dispatchable, despite current resource commitments. Note: Do not use QUICKDSP for too many users. The option is designed for a few, critical response service machines. Indiscrim inate use nullifies the attempts made by the Scheduler to balance loads against resources. QUICKDSP should NOT be used for interactive users, and is not relevant to the V = R machine.
Impact of Scheduler Changes
The overall effects of the new scheduling algorithms are: • To schedule large numbers of virtual machines efficiently. • To provide controls that enable your performance analyst to "fine tune" your system. • To manage the allocation of system resources between your users.
40 VM/XA SP Guide • To allow you to run a CMS intensive workload.
Performance Enhancements 41 42 VM/XASP Guide Multiple Preferred Guests
This new feature of VM/XA SP Release 1 improves the possibilities for preferred guest handling. We discuss in the following paragraphs how a user may use MPG to obtain a better sharing of the CPU(s). the expanded storage, and the real storage among all pre ferred guests.
Overview
Multiple Preferred Guest (MPG) creates a new type of virtual machine in the system. These guest virtual machines are designated as Virtual = Fixed (V = F). These virtual machines have some characteristics of V = R virtual machines and some characteristics of V= V virtual machines. Due to the mix of characteristics, performance for these guests should be better than V=V guest performance and may be as good as V = R guest per formance.
V = F and V = R Similarities
The following characteristics of V = F guests make them similar to the VM/XA SF Release 2 V = R guest: • Virtual storage is mapped into contiguous real storage. The storage is allocated at guest logon from the V = R region and remains allocated and reserved until guest logoff. No paging activity is required to support these guests. • A V = F guest may be dedicated to a CPU. An MP V = F guest may have one or more of his virtual CPUs dedicated to a real CPU or CPUs. This will also become a char acteristic of V = V guests.
• A V = F guest can take advantage of the SIE assist for its dedicated devices.
•AV = F guest uses CP I/O simulation for shared devices.
• A V = F guest can use dedicated expanded storage.
V = F and V = V Similarities
The following characteristics of V= F guests make them similar to V=V guests: • More than one V= F guest may exist in the system. • V= F storage, while contiguous and fixed, doesn't start at zero origin. Page and segment tables need to be created for all V= F users at guest logon.
Multiple Preferred Guests 43 Real Processor Management
We discuss in this section of the management of CPUs with the MPG feature. We look at the dedication of CPUs and how CP handles them.
Overview.
The Dedicate command can be issued for any guest in order to dedicate one or all of his virtual CPUs to real CPUs.
The automatic dedication for the V = R user continues to be the default. It may be over ridden by the installation in the directory or via the UNDEDICATE CPU ALL command. Automatic dedication does not occur for V = F and V=V users.
System Management
Directory Statements have been updated to take into account the new dedication possi bilities.
CPU directory statement
The CPU directory statement now allows any virtual processor, including V= F and V=V, to be dedicated to a real processor. In addition, the user can prevent the automatic dedication of a real processor to a virtual processor for a V=R guest.
CPU [ DEDicate ] [ NODEDicate j
Figure 8. CPU Directory Statement Changes
Where:
DEDicate Indicates that this virtual cpu is to be dedicated at LOGON time to a real processor. This Is the default for V= R guests when DEDICATE is specified or defaulted on the OPTION directory statement. NODEDicate Indicates that this virtual cpu is not to be dedicated to a real processor. It is as if an UNDEDICATE command was issued for this virtual CPU at LOGON time. This is the default for V=F and V=V guests and for V= R guests when NODEDICATE is specified on the OPTION directory statement. Usage notes: The use of DEDICATE or NODEDICATE on a CPU directory statement overrides the use of DEDICATE or NODEDICATE on an OPTION directory statement. However, it overrides only for the specific CPU listed on the CPU statement.
OPTION Directory Statement
The user can prevent the automatic dedication of a real processor to a virtual processor for the V = R guest.
44 VM/XA SP Guide Option [ Virt={Real } ] ... [ DEDicate ] [ {Fixed} ] [ NODEDicate ]
Figure 9. Option Directory Statement Changes
Where: VIRT=REAL Specifies that this guest is a V= R preferred guest if possible. VIRT=FIXED Specifies that this guest is a V= F guest if possible. DEDicate Indicates that if this user is logged on as the V= R virtual machine then every virtual processor for this virtual machine will be dedicated to a real processor if possible. Automatic dedication is in effect. This is the default. A virtual processor which has NODEDICATE specified on its CPU directory statement will not have a real processor dedicated to it. This option is valid only when VIRT = REAL is specified on one of the OPTION directory state ments for this user. NODEDicate Indicates that if this user is logged on as the V= R virtual machine then no virtual processor for this virtual machine will be dedicated to a real processor. Automatic dedication is disabled. A virtual processor which has DEDICATE specified on its CPU directory statement will have a real processor dedicated to it if possible. This option is valid only when VIRT=REAL is specified on one of the OPTION directory statements for this user.
Usage notes: • If a V= R logon is attempted and there is already a V= R user, the request is con verted into a V= F logon attempt. If a V= F logon is attempted and there isn't enough storage to satisfy the request, the request is converted into a V=V logon. If a V= F logon is attempted and the only storage available includes absolute frame 0 then the user is treated as V=V. It is not converted to a V=R virtual machine. If the maximum number of V= R or V= F users are logged on, then aV = RorV = F logon attempt is converted into a V=V logon. • The NODEDICATE option can be used to prevent a V= R user from having automatic dedication of real processors at V= R logon time. It prevents automatic dedication when a new virtual processor is defined by the V=R user via the DEFINE CPU command. It also prevents automatic dedication when a real processor becomes available and the V= R virtual machine has a virtual processor that is not dedicated. • Ifthe DEFINE CPU command is used to define a virtual processor for the V= R virtual machine, the DEDICATE operand will cause CP to try to find a real processor to dedicate to this new virtual processor. Similarly, if a real processor becomes available, a virtual processor associated with the V= R virtual machine which is not already dedicated will be dedicated to the new real processor. • If OPTION DEDICATE is specified and a virtual CPU has a dedicated real CPU then if an undedication occurs, for any reason, CP will attempt rededication. • The CPU directory statement overrides the specification on the OPTION directory statement.
• The DEDICATE CPU ALL command can be used to override OPTION NODEDICATE. The UNDEDICATE CPU ALL command can be used to override OPTION DEDICATE.
• If VIRT= REAL and DEDICATE are specified on the OPTION cards for a user and the user is converted toaV= ForV = V user then the DEDICATE option is ignored.
Multiple Preferred Guests 45 • OPTION VIRT= REAL or VIRT= FIXED causes the the storage size to be rounded to a megabyte boundary.
Real System Operation
The DEDICATE and UNDEDICATE CP commands allow any virtual processor, Including V= F and V=V, to be dedicated to a real processor or undedlcated from a real processor.
DEDICATE Command
A "userld" can be specified on this command via the USER operand. This operand can appear In any order with existing operands.
DEDlcate ... [ USER f userid }] ... A [{ * ]]
Figure 10. DEDICATE Command Change
Where:
USER userid * Indicates the user whose virtual processor Is to be dedicated to a real processor. Ifthe USER operand Is specified then either a userld or must be specified. Ifthe USER operand Is not specified then the V= R user Is the default. Usage note: If "DEDICATE USER userld CPU ALL" Is specified, all the currently defined virtual processors for the userld are affected. In addition. If automatic dedication Is not In effect for this user and this user Is V = R then automatic dedication Is enabled for this user. To avoid enabling automatic dedication use "DEDICATE USER userld CPU nn" In stead.
UNDEDICATE Command
A "userld" can be specified on this command via the USER operand. This operand can appear In any order with existing operands.
UNDEDicate ... [ USER { userid } ) ... A [{ - ]]
Figure 11. UNDEDICATE Command Change
Where:
USER userid Indicates the user whose virtual processor Is to be undedlcated from a real processor. Ifthe USER operand Is specified then either a userld or """ must be specified. Ifthe USER operand Is not specified then the V= R user Is the default.
46 VM/XA SP Guide Usage note: If"UNDEDICATE USER userid CPU ALL" is specified, all the currently de fined virtual processors for the userid are affected. In addition, if automatic dedication is in effect for this user (which must be V= R) then automatic dedication is disabled for ^ this user. To avoid disabling automatic dedication use "UNDEDICATE USER userid CPU nn" instead.
Support Use Information
With the new possibilities given by the directory statements and the CP commands on CPU dedication the user should be aware of the following information.
Directory Changes
With the addition of support to dedicate a real processor to any virtual processor, the user should reexamine how real processor resources are dedicated. V=V and V= F virtual machines can now have their virtual processors dedicated to real processors.
For installations that want total control of real processors via the operator (class "A" —^ user), all V= R directory entries should have the NODEDICATE operand on the OPTION ^ directory statement and any CPU directory statements should have the NODEDICATE operand. This prevents CP from automatically dedicating virtual processors to real processors for the V= R user. The DEDICATE command can then be used to dedicate virtual processors to real processors. However, if you don't want to enable automatic dedication for a V = R user, use "DEDICATE CPU nn" rather than "DEDICATE CPU ALL". Using the 'ALL' operand will enable automatic dedication if the target userid of the command is the V = R user.
For installations that want to cause dedication of specific virtual processors to real processors at LOGON time, they should put the NODEDICATE operand on the OPTION statement for V= R users and add the DEDICATE operand for each CPU directory state- ^ > ment which is to be dedicated at logon time. The DEDICATE operand can be specified for V = R, V = F, or V = V users.
If the installation makes no changes, CP will automatically dedicate any V= R virtual processor to an available real processor.
DEDICATE/UNDEDtCATE Commands for V=R
Issuing the "DEDICATE USER userid CPU ALL" command results in dedication occurring for the currently existing virtual processors of the target V= R userid. It also overrides an OPTION NODEDICATE operand in the directory. If an additional virtual processor is ^ defined afterthe DEDICATE command, the new virtual processoris dedicated automat ically even if OPTION NODEDICATE is in the directory entry. In a similar manner, issuing the "UNDEDICATE USER userid CPU ALL" command results in undedication occurring for the currently existing virtual processors of the target V= R userid. It also overrides an OPTION DEDICATE operand in the directory. If an additional virtual processor is defined after the UNDEDICATE command, the new virtual processor is not dedicated even if OPTION DEDICATE is in the directory entry.
V=V Dedication
Although V=V virtual processors can now be dedicated to real processors, the installa tion should be aware that dedicating a virtual processor does not guarantee performance improvement for a V=V virtual machine. If real storage is not available to run the V=V virtual machine, the V=V machine will be delayed until real storage becomes available. To reduce or eliminate the chance that a V=V virtual machine will be delayed, the in- - stallation can use the SET RESERVED or LOCK commands.
Multiple Preferred Guests 47 Vector Facilities and Dedicated Processors.
The Installation should consider the following when automatic dedication is not in effect. Automatic dedication is not in effect for all V = V and V = F users as well as for a V = R user that has OPTION NODEDICATE in its directory entry or has had an UNDEDICATE CPU ALL command issued for it. • If a virtual CPU without a virtual Vector Facility is dedicated to a real processor without a real Vector Facility and the user defines a virtual Vector Facility, CP will define the virtual Vector Facility and issue a message indicating that no real Vector Facility exists to service the virtual Vector Facility. If a real Vector Facility exists on another undedicated processor then a class "A" user should issue the UNDEDICATE command for the virtual CPU that had the virtual Vector Facility added. If desired, the DEDICATE command can then be issued to dedicate a real processor that has a real Vector Facility. Similarly, if a virtual CPU with a virtual Vector Facility is dedicated to a real processor with a real Vector Facility and the real Vector Facility is varied offline, a message is issued. A class "A" user should undedicate the virtual CPU as it is stated in the previous paragraph.
Expanded Storage Management
We discuss in this section of the new possibilities given by MPG to handle the expanded storage among multiple users.
Overview
In VM/XA SF Release 2 SPE there is only one guest partition and it is located at the lowest block numbers. CP retained Expanded Storage is located at the highest block numbers. The CP partition is located between the guest partition and the CP retained Expanded Storage. In VM/XA SF Release 2 SPE the allocation is on a hardware de pendent boundary known as the Expanded Storage increment size. The actual allocation unit changes as the hardware changes.
With MPG the allocation boundary for Expanded Storage is 1 Mb.
Multiple guest partitions can exist and they can be located anywhere although CP at tempts to allocate them at the lowest block numbers. Each guest partition is contiguous. If a guest requires a larger amount of Expanded Storage than it currently has, then the DETACH and ATTACH XSTORE commands must be used. If CP can not find contiguous Expanded Storage large enough to satisfy the ATTACH XSTORE request, the largest available is attached. No CP or other guest's Expanded Storage can be in the middle of a guest's partition. The CP partition can also be in multiple pieces. CP retained Expanded Storage can be in pieces although CP attempts to allocate it at the highest block numbers.
Real System Operation
In the following paragraphs we see the additions made to the three CP commands which deal with the expanded storage.
ATTACH XSTORE Command
48 VM/XA SP Guide The syntax of the command is the same as in VM/XA SF Release 2 SPE. If ALL is spec ified or defaulted, the user gets the largest amount of expanded storage available. The size may now be specified in units of 1 Mb. Usage note: Multiple users may have expanded storage attached to their virtual ma chines. If the request for expanded storage can not be satisfied at the current time, then the maximum amount that can be attached at this time will be attached to the virtual machine.
The expanded storage attached always appears contiguous to the guest. The block number of the first block attached is accessed as block zero (0) by the guest.
DETACH XSTORE Command
DETach {XSTore } {[FROM] { userid } } B [XSTorage] {[ ](}}
(XSTore } G (XSTorage}
Figure 12. DETACH XSTORE Command Format
Usage notes:
• In the DETACH XSTORE class 'B' command the "userid" operand is required but the "FROM" operand is optional.
• If a class "B" user issues DETACH XSTORE with no operands, then the command is in the class "G" format. Therefore the command is interpreted as a request to de tach any expanded storage from the user issuing the command.
• If a RETAIN XSTORE command was issued but not fully satisfied, the expanded storage detached will be used in an attempt to satisfy the amount remaining from the RETAIN request.
QUERY XSTORE Command
The class B command has more possibilities to accommodate the fact that multiple guests can now have expanded storage attached. A "MAP" operand is added to display how expanded storage is currently partitioned. A "userid" operand is added to the "QUERY XSTORE USER" command.
Query {XSTore ] [ USER [ userid ]] B {XSTorage] [ MAP ]
Figure 13. QUERY XSTORE Command Format (class B)
QUERY XSTORE: Without parameter means all System information.
Four different responses are given:
Response 1: lists the installed and configured XSTORAGE
Multiple Preferred Guests 49 XSTORE=niiimnnnnM, ONLINE=rmnimnniiM
Response 2; lists usable XSTORE
{INIT} XSTORE=iirmimimnM, USERID=SYSTEM USAGE={nnn%| RETAINED=niinnimnnM [NONE} PENDING=imimiinnnM
Where:
PENDING = nnnnnnnnM Is the amount of expanded storage that has not yet been made retained. The amount of expanded storage specified on the last RE TAIN XSTORE command could not be fully satisfied. When this amount is detached from virtual machines it will become retained expanded storage.
Response 3: repeated for each guest partition if any
XSTORE=nimnimnnM, USERID=userid
Response 4: after all -guest partitions are listed
XSTORE=nnnnnnnnM, USERID= (NONE) MAX ATTACH=iinmmnnnM
Where:
MAX ATTACH = nnnnnnnnM Indicates the maximum amount of expanded storage that could be attached to a single virtual machine. If this does not match the XSTORE value on this line then the expanded storage is fragmented.
QUERY XSTORE USER: When the "userid" is present, response 3 is displayed for the specified "userid". When no "userid" is given, response 3 is displayed for each guest partition and response 4 is displayed.
QUERY XSTORE MAP: A map of the expanded storage is displayed showing how ex panded storage is currently allocated. The response has the following format:
START SIZE STATUS %-IN-USE %-UNUSABLE nnnnimimM nimnimmiM CP nim% iinn% CP(RETAINED) useridim useridnn(N/A) useridim(MIG) N/A
where:
START Indicates the megabyte where this partition starts.
SIZE Indicates the size of this partition in megabytes.
STATUS Indicates the status or owner of the partition as follows:
50 VM/XA SP Guide CP CP is using this partition for CP paging. It is available to be attached to a virtual machine.
CP(RETAINED) CP is using this partition for CP paging. It is not available for attachment to a virtual machine.
useridnn The specified user has this partition attached to its virtual machine.
useridnn(N/A) The specified user's virtual machine has this partition at tached. This particular area is not available for guest use. There are one or more other partitions with this same userid above or below this partition. They are treated as one single guest partition even though it appears that the guest has dis contiguous expanded storage.
useridnn(MIG) This partition is in the process of being attached to the virtual machine specified. CP is migrating data from this area prior to completing the ATTACH.
N/A This area of expanded storage is not available for use by CP ^ ^ or a guest. %-IN-USE Indicates the percentage of this partition that contains a page of guest stor age. It is displayed only for CP and CP(RETAINED) partitions. %-UNUSABLE Indicates the percentage of the partition that can not be used by CP for paging due to hardware conditions. It is displayed for each online partition except those marked "N/A" or "useridnnfN/A)".
Real Storage Management
Overview
The definition of the V= R region is being expanded to include storage dedicated to both V= R and V= F guests. The only change to the way in which real storage is laid but will be in the V = R Area. The single V = R region continues to be defined via the SYSSTORE macro instruction of HCPSYS. The storage will be divided among multiple V= F guests and a single V= R guest as the users log on. As before, only one V= R guest may be logged on at any one time and the storage for that guest must be contiguous and begin at absolute zero. Storage for a V= F guest must also be contiguous, but must not begin at absolute zero. Storage for V= F or V= R guests is allocated from the V= R region at logon time. The search for storage for the V= F guest begins at the top of the V= R re gion. The first megabyte of storage is reserved for the V= R guest, as absolute page zero.
Multiple Preferred Guests 51 FREE STORAGE
DPA
Resident at Init.
Resident Nuc.
V=R Free
V=R
Region 1 Meg Reserved for V=R Gst 0
Figure 14. Real storage layout.
Real System Operation
We see In this section how the operator may get Information about the real storage lay out.
QUERY V=R Command
This class B CP command displays information about real storage allocated to V= R and V= F guests from the V= R region. It also reports expanded storage attached to these high performance guests. The userid, storage origin, storage size, expanded storage origin, and expanded storage size for each logged on high performance guest is dis played. The size of the V= R region and the maximum number of high performance (V = R and V = F) guests are also displayed.
Query | V=R
Figure 15. QUERY V=R Command Format
52 VM/XA SP Guide Responses:
USER STORAGE STORAGE XSTORE XSTORE ORIGIN SIZE ORIGIN SIZE userid nnnnM nnniiM nimnnnnnM nnnnimnnM userid nnnnM niinnM rmimnimnM nnimimimM
userid nnmiM nnnnM nnnnnnnnM nnnnnnnnM
SIZE OF THE V=R REGION nnnnM
MAXIMUM NUMBER OF V=R AND V=F USERS ALLOWED nnn
Where:
USER is the user.id of the user assigned the corresponding host real storage.
STORAGE ORIGIN is the main storage origin of the block of contiguous storage assigned to this user.
STORAGE SIZE is the size in megabytes of the host real storage assigned.
XSTORE ORIGIN is the expanded storage origin assigned to this user. XSTORE SIZE is the size in megabytes of the expanded storage assigned. This is the configured size.
SIZE OF .... is the size in megabytes of the V = R region. This is the same value as was specified in the system generation via the VRSIZE operand of the SYSSTORE macro.
MAXIMUM .. USERS .. is the maximum users that can be logged on as either V = R or V = F. This number includes those already logged on and shown in the detail of this response. The maximum number of users that can log on is limited by hardware and software capability, but remains constant after IPL.
Usage note: The storage size specified in the directory or on the STORAGE operand of the LOGON command will be rounded up to a megabyte boundary for both V = R and V = F users even if the storage size specified is less than 16M.
Support use information
This section discusses how the customer allocates V = R storage now that multiple virtual machines can use this storage.
Allocating sufficient V=R storage
The means for specifying the size of the V = R region remains the VRSIZE operand of the SYSSTORE macro used during system generation. The value must be equal to the sum of the storage sizes of all the V= R and V= F users that will be logged on concurrently. If the installation has different sets of high performance users logged on at different times, the VRSIZE must be specified as the largest sum of storage sizes. Otherwise an IPL will be necessary in order to change the V= R region size as requirements change.
Multiple Preferred Guests 53 Logging on V=R and V—F users
Storage is allocated from the V = R region to V = R and V=F users on a first come first serve basis. An attempt is made to allocate V= F user storage from the top of storage available within the V= R region. Storage for the V= R user will always be allocated from the bottom of the V= R region. A V= F user will never be given the megabyte of storage containing absolute frame zero. However a V= F user may be given the second megabyte of storage. This wpuld make it impossible for a V = R user to obtain any more than 1 megabyte of storage, probably preventing the V= R user from logging on as V = R. V= R and V= F users are different in the following two ways: • The V= R user may see a slight performance advantage due to storage access without address translation.
• Preferred guest recovery is provided only for the V= R user.
If it is important to an installation that a V = R user be logged on to take advantage of the two V = R advantages, then the V = R user should be logged on before V = F users to ensure that sufficient storage is available for the V = R logon to succeed.
Handling the V=R region following a software re-iPL
When VM/XA terminates and initiates a software re-IPL, whether preferred guest recov ery is successful or not, an attempt is made to preserve storage in the V = R region. Preserving this storage allows for the user previously logged on, to log on again and run a stand-alone dump or recovery program. The only way in which the storage is pre served is for the same V = F or V = R user to logon again with the same storage size. If other high performance users are logged on, storage will be cleared and assigned to them.
Recovery
Preferred Guest Recovery is not being extended to V= F guests. V = R preferred guest recovery remains the same as in VM/XA SF or VM/XA SP Release 1 without MPG.
Migration
In migrating from VM/XA SF Release 2 SPE or VM/XA SP Release 1 without MPG, the customer should consider the effect of the new V= F support on the installation's re source allocation. Consideration should be given to:
Allocating a larger V = R region to accommodate V= F virtual machines.
Identifying users who are candidates for V= F status.
Determining if automatic dedication should continue to be done for the V = R virtual machine.
Determining if one or more specific V = R virtual processors should be dedicated to real processors.
Determining if real processors should be dedicated to V = F or V=V virtual ma chines.
Determine which users should have expanded storage attached. These can be V = R, V = F, or V=V virtual machines.
Determine how much expanded storage should be retained for CP's exclusive use.
54 VM/XA SP Guide • Determine If multiple systems can be merged onto one system where the V = R us ers from the multiple systems become V= F (or V= R) users on the merged system. Any guest which runs In a V= R virtual machine can run In a V= F virtual machine.
Migrating from VM/XA SF Release 2
In VM/XA SF Release 2 If two users had expanded storage In their directory and both logged on only the first one to logon would get the expanded storage. With the addition of multiple guest partitions, both can get expanded storage. This could cause a problem for Installations that Implicitly retain expanded storage for CP use by never attaching all expanded storage to a virtual machine. Issuing the RETAIN XSTORE command may be required to avoid having users take all expanded storage when the Installation wants to leave some for CP.
Migrating from VM/SP HPO Release 5
In VM/SP HPO Release 5 the expanded storage can only be used by CP. It can not be attached to a virtual machine. In VM/XA SP Release 1 with MPG, CP uses expanded ^ ^ storage by default. Therefore customers migrating from VM/SP HPO Release 5 do not have to make any changes. Ifthe VM/SP HPO Release 5 customer wants to attach some expanded storage to virtual machines then some planning Is required to determine how to assign this resource.
Multiple Preferred Guests 55 56 VM/XA SP Guide Monitor Facility
The Monitor Facility collects system performance data so that data reduction programs can provide an understanding of system operation. The installation can control the amount, nature, and destination of the data to be collected, depending on the type of analysis to be performed. One or more external tools are required to reduce the data collected. These tools enable the user to analyze the utilization of and contention for major system resources such as processors, storage, I/O devices, and the paging sub system. The major functions that make up the Monitor Facility are:
Monitor Data Domain Architecture Monitor Data Collection Monitor Control Mechanisms The Monitor Discontiguous Saved Segment lUCV Communication Note: IBM does not provide a program to perform reduction or recording of the Monitor Facility data.
Monitor Data Collection
The Monitor Facility collects two fundamental types of data: event data and sample data. This data is collected by different collection techniques. Event-driven Data Coliectlon produces one Monitor event record for each selected sys tem event at the time the event is detected. The volume of data produced is determined by the frequency of the selected system events. There are several event-driven domains, each providing data related to a particular area of system activity. Each domain can be started and stopped separately with the excep tion of the Monitor domain. Additional controls are allowed to further restrict the events to those of specific interest. For example, in the I/O domain, the user may specify device numbers, types, and classes to be included or excluded from Monitoring; in the user data domain, specific users may be included or excluded from event-driven records being created. Sample Data Collection produces Monitor records at the end of each interval. The re cords contain two types of data: single-sample data and high-frequency data. Most domains have their own high-frequency sample data or single-sample data that is sampled when requested. For the I/O and user domains, only the specified devices or specified userids are sampled. Single-Sample Data: The control program maintains counts of events and accumu lates elapsed time for those events that characterize system operation. The count ers and timers may be sampled relatively infrequently without losing any resolution, since they are not reset between samples. Therefore, after the initial values have been established, they need be sampled only once for each reporting period.
Monitor Facility 57 High-Frequency Data: High-frequency data is derived from a set of counters that capture states and counts that represent the system at the moment of sampling. The sampling is done at a higher rate than it is reported. For each domain or group of pertinent data within the domain, there is a separate counter that represents the number of times this particular data has been sampled. Each high frequency-counter contains a cumulative count of the frequency with which a value or set of values representing system states could be observed. Each time its domain is sampled, the data value is added to the counter. The counter is always incremented unless high-frequency sampling is stopped and restarted, which sets the sampling counters to zero. High-frequency data is placed in Monitor records only when the interval expires.
Monitor Data Domain Architecture
To enable the user to select which data is to be recorded, the system is divided into eight data domains, as follows: • General System Data Domain contains system resource usage data obtained by ac cessing system counters. This data gives the user an overall picture of how the system is running.
This domain contains sample and high frequency data. The system domain is automatically enabled when Monitor sampling is started, and remains active until Monitor sampling is stopped. Data for this domain is recorded whether or not any other domains are enabled. • Monitor Data Domain contains information on the system configuration (paging, storage, I/O, processors, and other areas) generated when the Monitor is initially started. This domain also defines the suspension records generated when events suspend and provides information on the active domains.
This domain contains sample and event data.
The Monitor domain is automatically enabled when Monitor sampling or event re cording is started, and remains active until the Monitor is stopped. Data for this domain is recorded whether or not any other domains are enabled. • User Data Domain contains data relating to a user's logging on and off, scheduling status, virtual I/O, and vector usage.
This domain contains sample, high frequency, and event data. • Scheduler Data Domain contains data about Scheduler queue manipulation, a user's use of the system (with terminal reads and writes), monitors the flow of work through the Scheduler, and indicates the resource allocation strategies of the Scheduler and Dispatcher.
This domain contains event data only. • Seek Data Domain records are generated each time a SEEK command is found in a CCW.
Note: Because of the extremely large amount of data this domain may generate, you should limit the number of devices for which you collect seek data.
This domain contains event data only.
• I/O Data Domain contains counters to monitor I/O requests, error recovery, inter rupts, and other information for real devices.
58 VM/XA SP Guide This domain contains sample, high frequency, and event data. • Processor Data Domain contains data about system locks, simulation, inter- processor signalling, and other statistics related to CPU usage.
This domain contains sample, high frequency, and event data.
• Storage Data Domain contains system statistics to determine the utilization charac teristics of real, virtual, expanded, and auxiliary storage.
This domain contains sample and event data.
Note: Both the monitor and system domains are enabled whenever the Monitor is started.
Monitor Control Mechanisms
The Monitor control mechanisms regulate all data collection and transmission activities of the Monitor. They allow enabling and disabling of the Monitor functions as required and allow detailed specification of the data to be collected. The MONITOR command allows the user to select the proper data for collection and to guarantee sufficient resol ution through the use of the following controls:
Data Selectivity Specifies those system activities for which the Monitor Facil ity is to collect data. For this purpose, the system activities are divided into the data domains discussed above.
Detail Selectivity Limits the data that is to be collected from a particular data domain; for example, data relating to specific I/O devices or to specific users.
Resolution Selectivity Specifies the sampling interval for single-sample data and the rate for high-frequency data. The MONITOR command is a privileged command that provides the user with control of the Monitor Facility. The command syntax provides considerable flexibility in specifying the data of specific interest. Use the MONITOR command to:
Enable or disable various domains or Monitor event data.
Enable or disable various domains or Monitor sample data. Specify the interval for sample data, and the rate for high-frequency sample data.
Start collection of Monitor event data, sample data, or both. Stop collection of Monitor event data, sample data, or both. Control Monitor data collection by including or excluding specific:
Real device numbers Real device types Real device classes Volume identifiers Userids
The QUERY MONITOR command is used to interrogate the settings that have been es tablished by the MONITOR command.
Monitor Facility 59 The Monitor Discontiguous Saved Segment The Monitor Discontiguous Saved Segment (DCSS) is at least 1 Mb of storage that con tains the Monitor records. A virtual machine accesses this DCSS and then displays, re cords, or analyzes the data in the records. Being in a DCSS, the Monitor records exist in the virtual machine's address space. The virtual machine connected to the "MONITOR CP system service must have the DCSS loaded (by means of DIAGNOSE X'64' or the CMS SEGMENT command) before the Monitor can be started.
MONITOR lUCV Communication
lUCV is the notification vehicle between the Monitor Facility and the virtual machine used to receive the Monitor data. Its purpose is to: Notify CP that a virtual machine wants access to Monitor data. Notify the virtual machine that access is accepted. Notify the virtual machine that data has been placed in the DCSS. Acknowledge the.receipt of data by the virtual machine. Terminate the communication.
The flow of information between the Monitor Facility and the virtual machine receiving the Monitor data is shown in Figure 16 and takes place as follows:
Virtual Mach i ne
Monitor DCSS
Dato Flow
Data Reduction Program
{ lUCV
CP 1 Monitor Facility ■^♦Monitor j
Figure 16. Monitor Facility Information Flow
The Monitor Facility inserts the data into the Monitor DCSS. The Monitor Facility signals the receiving virtual machine using lUCV that the data is available and gives the address of a control block pointing to the data. The receiving virtual machine processes the data and then signals the Monitor Fa cility using lUCV that the area that contained the data in the Monitor DCSS can be re-used.
60 VM/XA SP Guide A virtual machine must initiate lUCV communications before any records can be placed into the DCSS by the Monitor Facility. There Is a restriction that only one virtual machine can be connected to the "MONITOR CP system service.
Service Virtual Machine Wait End user response time measurements in VM/SP HPO are based on Scheduler states. A transaction is presumed to start when a virtual machine enters a Scheduler queue from an idle state, is presumed to be in progress if a virtual machine is in a Scheduler queue, and is presumed to terminate when a virtual machine drops from a Scheduler queue into an idle state. This approach overlooks the fact that a virtual machine may not be in a Scheduler queue, but nevertheless is considered as having a transaction in progress by the end user. One of the more prominent examples forthis situationoccurs in the use of service virtual machines. Wait for service virtual machines usually occurs out of any Scheduler queue. In VM/SP HPO, the time spent in queue prior to and after the wait for the service virtual machine would usually be considered separate transactions. This results in a gross f—y understatement of end user response time, and a gross overstatement of end user throughput. Therefore, a new virtual machine state SVMWAIT (Service Virtual Machine WAIT) has been introduced. A virtual machine that is in SVMWAIT is considered to have a trans action in progress. It cannot be established at all times by CP whether a virtual machine is in SVMWAIT or not, due to the generality of the VMCF/IUCV communications capabil ities.
Service Virtual Machine Statistics Service virtual machines must be analyzed quite differently from end user virtual ma chines (running CMS, for example). There is no single unique identifying characteristic from a performance perspective that uniquely identifies service virtual machines. Therefore, a new option (SVMSTAT) has been added to the directory OPTION statement. This option is used for service virtual machines to indicate tothe Monitor that the virtual machine is a service virtual machine. The presence of this option is indicated in both monitor and user domain records.
Monitor Writer The Monitor Writer function is invoked by a CMS command that allows the user to collect data produced by the VM/XA CP monitor and save it in a CMS file or on a tape. Once in the output file, the data can be processed via any application the userwishes. This file can be transported or sent to another computer for storage or processing. The Monitor Writer function is implemented in a standard CMS module which runs in a CMS virtual machine under control of VM/XA SP Release 1. This virtual machine should be an XA mode virtual machine since the Monitor DCSS may be loaded above the 16 Mb line. Figure 17 and Figure 18 describe the relationships between CP "MONITOR, the Writer, and the Data Reduction program.
Monitor Facility 61 VU/XA CP oUoni tor Monitor System Service
lUCV Connection
Monitor Monitor DCSS Writer
I iUCV I Connection
Output Dote Reduction Fi le Progrooi
Figure 17. Writer Communication with 'MONITOR
When the user starts the CP Monitor, some application must be at the other end of the lUCV connection to the "MONITOR system service before data is actually collected. That application can be the Monitor Writer function. Once the virtual machine that is to run the monitor writer has been logged on, the user issues the MONWRITE command specifying the output destination. Monitor writer will verify the command parameters and issue error messages if they are incorrect. Once the parameters are found to be correct, the writer loads the Monitor DOSS via the SEG MENT macro. Then it attempts to CONNECT to "MONITOR. Once the connect is accepted, MONWRITE notihes the user with a message. Then the user starts the Monitor and when the "MONITOR SEND occurs, the Monitor Writer func tion moves the data from the monitor DCSS to the output device.
VM/XA CP •Uonltor Monitor System Service
lUCV Connection
Dote Monitor OCSS Reduction Progrom
Monitor Output Writer File
Figure 18. Data Reduction Communicating with "MONITOR
62 VM/XA SP Guide RAS and Usability Enhancements
Some Improvements have been made to RAS and usability. These enhancements in clude:
Control Block Identifier CCW Translation Redesign PL/AS (Programming Language for Advanced Systems) Logged-on User Limit Enhancements Terminal Availability Enhancements
Control Block Identifier
VM/XA SP Release 1 includes control block identifiers for free storage blocks. This en hancement allows you to identify control blocks in a system dump even if anchors or chains are not available. In addition, the control block identifier is added to the trace table entry. As a result, a system programmer is able to find a control block in a system dump. The Control Block Identifier function is invoked whenever a control block is ob tained from free storage or returned to free storage.
cow Translation Redesign The VM/XA SP Release 1 Control Program translates a virtual channel program initiated by a guest Operating System into a real channel program. This CCW translation function is redesigned to remove complexity and be more understandable. The redesign in creases the reliability and the quality of the function. CCW translation is performed for virtual channel programs submitted by a guest oper- ating system for execution on the real channel subsystem. CCW translation occurs for ^ all dedicated devices and many non-dedicated devices, excluding only virtual spooling devices (virtual readers, printers, and punches that are logically connected to the spooling subsystem) and virtual channel-to-channel adapters that are not connected to any real device (coupled CTCAs). The redesigned CCW translation is invoked when a guest operating system issues any of the following instructions:
Resume I/O (RIO) Resume Subchannel (RSCH) Start I/O (SIO) Start I/O Fast Release (SIOF) Start Subchannel (SSCH) Diagnose X'20' (general I/O services) Diagnose X'28' (channel program modification) Diagnose X'58' (3270 virtual console interface) Diagnose X'A8' (general I/O services 31-bit interface)
RAS and Usability Enhancements 63 PLIAS
The use of PL/AS makes developers more productive and at the same time reduces er rors caused by manually performing many of the functions now handled by the compiler (for example, register usage). In addition, those modules written in this language have to be maintained without source code. Therefore,the service approach for object code maintenance is applied. This service approach is to provide a minimum set of service functions so that maintenance is equivalent to source maintenance. The objective of supplying object code is to provide control over locally applied fixes for an object code maintained environment. Also, this object code maintenance should be conceptually the same as source maintenance with the same control structure and tools to manipulate and control programs.
The primary method of object code maintenance is Text File Replacement'. Patches developed locally are used as bypasses until a replacement file arrives from IBM. Con trol for these bypasses is provided through the control and auxiliary structure similar to that used for source maintenance. This prevents the loss of patches if a replacement file arrives without the fix for the patch included.
The EXECs enhanced for PLVAS support are:
• SPGEN EXEC
• HCPLDR EXEC
• VMFHASM EXEC
Logged-on user limit enhancements
This function is provided to allow installations to set the maximum number of users al lowed to log on in a system. This limit can be adjusted to fit the needs of the installation, or the limit can be removed entirely. Previously the maximum number of users in the system was 999.
The CP command SET MAXUsers {privilege class A) is used to adjust or remove the user logon limit. The range is from 1 to 99999, and the user can specify OFF to indicate an unlimited number of users that can log on. The CP command QUERY MAXUsers can be used to display the current user logon limit. We can code the macro SYSMAXU to specify the user logon limit. This macro is optional; if we code it, we must place it after the first five required macros in HCPSYS ASSEMBLE:
• SYSCPVOL • SYSOPR • SYSRES • SYSSTORE • SYSTIME
But before the SYSEND macro. We can specify the maximum number number of users that can be logged on and the range is from 1 to 99999.
Terminal availability enhancements
The requirement to specify the model operand for local 3270 displays on the RDEVICE macro is now optional. If model number is not specified, the display characteristics will be set to a model 2.
64 VM/XA SP Guide CP will attempt to determine the real local display device characteristics during terminal initialization processing and set the real device block (RDEV) accordingly. Terminal in- itialization processing for local display devices occurs when either CP receives an un solicited device end for an enabled device or when the ENABLE command is issued for a powered on display device that is currently disabled. This feature allows an installation to move or add displays without necessarily having to reassemble HCPRIO and regenerate a new nucleus.
RAS and Usability Enhancements 65 66 VM/XA SP Guide Migration Considerations
This section discusses the impact of migrating to VM/XA SP Release 1 by looking at the tasks performed by a data processing installation. The discussion assumes that any in stallation involves the following topics:
System evaluation Migration planning Installation and service System management Real system operation Virtual machine operation Application programming development and debugging Diagnose codes "Appendix A. Summary of Changes from Prior Releases" on page 81 provides additional details on changes from prior releases.
System Evaluation
System evaluation is the task of judging the capability of the VM/XA SP Release 1 system to meet the needs of the establishment. The advantages and disadvantages discussed below should be considered if you plan to migrate to VM/XA SP Release 1.
Migration from VM/SP or VM/SP HPO Release 5 to VM/XA SP Release 1
This section discusses the advantages and disadvantages of migrating to VM/XA SP Release 1 from VM/SP Release 5 or VM/SP HPO Release 5.
Advantages
The following advantages accrue to an installation migrating to VM/XA SP Release land beyond:
• Growth constraints removed:
• Real storage - VM/XA SP Release 1 supports each storage size that is available on an IBM processor. • Virtual storage - 31-bit addressing capability allows you to address 2 Gb of vir tual storage. VM/XA SP Release 1 supports a virtual machine with up to 999 Mb of storage. • I/O - you get the advantages of the 370-XA channel subsystem. • Multiprocessing - VM/XA SP Release 1 supports all multiprocessor systems in single image mode.
Migration Considerations 67 Significant function added:
• Bimodal CMS - allows you to run your application above the 16 Mb line using 31-bit addressing mode.
Usability:
Compatibility emphasis - most of the commands and command responses are compatible with VM/SP HPO. Migration documentation - new documents help you to migrate.
General advantages:
You can run System/370 and 370-XA operating systems on VM/XA SP, whereas VM/SP HPO supports only System/370. Start interpretive-execution assist allows the VM/XA preferred guest machines get performance advantages by dedicating devices, but without the need to dedicate separate channels as VM/SP HPO does with the PMA microcode. VM/XA SP allows you to partition expanded storage between CP and one virtual machine. VM/SP HPO uses expanded storage for CP paging and swapping only. The following advantages accrue to an installation migrating to VM/XA SP Release 2:
• Group Control System (GCS) • Systems Network Architecture (SNA)
Disadvantages
The following may be disadvantages if an installation migrates to VM/XA SP Release 1:
• Some functions are not supported in VM/XA SP Release 1:
• Transparent Services Access Facility (TSAF) • ASCII device support • Journaling • lUCV discontiguous buffer • CP national language support • Advanced Function Printing Subsystem Support (APSS) • Double byte character set (DBCS) • FBA device support (only dedicated devices are supported)
• Usability:
• Some program products and vendor products are not supported. • New tuning and monitor tools are needed. • Education required.
Migration from VM/XA SF to VM/XA SP Release 1
This section discusses the advantages and disadvantages of migrating from VM/XA SF to VM/XA SP Release 1.
Advantages
The following advantages accrue to an installation by migrating to VM/XA SP Release 1:
• Growth constraints removed:
• Increased performance for interactive use - changes to the Scheduler allow an intensive CMS load.
68 VM/XA SP Guide • Improved tuning - the Scheduler has a more global view of the resources, which allows better tuning. • More processor support.
• Removal of VM/XA SF restrictions:
• Device support improved over VM/XA SF.
• Significant function added: • Bimodal CMS - allows you to run your application above the 16 Mb line using 31-bit addressing mode. On the other hand, you can IPL CMS in 370-mode and use VSE/VSAM and CMS/DOS. • More program products are supported. • More VM/SP HPO functions are implemented.
• Usability: • Migration documentation - new documents help you to migrate.
Disadvantages
If an installation migrates to VM/XA SP Release 1, usability may be reduced because some commands are incompatible with VM/XA SF commands.
Migration Information
Migration documentation consists of three publications: VM/XA SP General Information, VM/XA SP Conversion Notebook, and VM/XA SP CMS Application Program Conversion. The first book covers the general differences between VM/SP HPO Release 5 and VM/XA SP Release 1. The second book provides technical details on the migration task and the differences between VM/SP HPO Release 5 and VM/XA SP Release 1 in the tasks performed by a data processing installation. Refer to VM/XA Systems Facility Planning Guide and other VM/XA SP Release 1 publi cations for general planning information, including:
Resource requirements
Machine configuration
Virtual machine planning
Multiple CPU environments
DASD sharing
Migration Planning
To plan for migration to VM/XA SP Release 1 you must perform the following tasks: • Check all devices in your system to determine whether they are supported by VM/XA SP Release 1. If some of them cannot be used by VM/XA SP Release 1, consider whether to dedicate them to a guest operating system. Make sure that all the program products you need are supported by VM/XA SP Re lease 1. If some are not, consider running a second-level operating system.
Migration Considerations 69 • If you want to run your existing operating system as a guest of VM/XA SP Release 1, make sure you have enough resources available. Refer to VM/XA Systems Fa cility Planning Guide for planning information.
• Educate your staff members.
• Create a detailed migration plan.
VM/XA SP Release 1 is an extension to VM/XA Systems Facility that incorporates some VM/SP HPO Release 5 functions. Therefore, there will be two major migration environ ments for VM/XA SP Release 1. The first is a VM/SP HPO Release 5 customer or a VM/SP Release 5 customer migrating to VM/XA SP Release 1. The second environment is a VM/XA Systems Facility customer migrating to VM/XA SP Release 1.
Because of the large number of customers in the first environment, the compatibility of VM/XA SP Release 1 to VM/SP HPO Release 5 has been improved. On the other hand, due to architecture and system design differences, a 100% upward compatibility with VM/SP HPO Release 5 is not possible. The positive usability features of VM/XA Systems Facility were preserved in VM/XA SP Release 1 whenever justifiable trade-offs could be made between VM/XA Systems Facility usability and the requirement of VM/SP HPO Release 5 compatibility.
The changes that have to be considered include:
Command compatibility - increased compatibility is provided between VM/XA SP Release 1 and VM/SP HPO Release 5 in the area of command syntax and response. Some commands, however, are incompatible with VM/XA SF Release 2. New DIAGNOSE codes - some DIAGNOSE codes have been changed or added to be more compatible with VM/SP HPO. Four-digit device addresses. New or modified system messages with 3- or 4-digit message numbers. Installation EXECs - compatibility is provided with VM/SP Release 5. you plan to migrate to VM/XA SP Release 1 you should consider the following:
You may have to modify EXECs that parse CMS or CP command responses.
There are better tools available to control not only the processor share but also storage and paging resources. You can partition expanded storage between CP and one guest operating system. There is now some delay in the LOGON/LOGOFF time if expanded storage is used and it must be partitioned
Check the size of your spool file area and warm-start area. Spool file limit relief allows 9999 spool files per user. User Class Restructure allows up to 32 command privilege classes. The definition of a CTCA requires a userid in the directory statement and on the DEFINE command.
The NETWORK command is not available in VM/XA.
There is no macro equivalent to DMKSNT - you can now use the DEFSYS and DEFSEG commands.
The segment size is 1 Mb. This affects program product installation.
VM/SP Release 5 and VM/SP HPO Release 5
70 VM/XA SP Guide While one of the primary objectives of VM/XA SP Release 1 is to provide a growth path for VM/SP HPO customers with maximum compatibility to ease migrations, factors such as architectural differences, make full compatibility impossible. VM/XA SP Release 1 has made every effort to fulfill the migration objective by keeping, where possible, command syntax, responses and message text the same. Common DIAGNOSES are functionally equivalent. The bimodal CMS component of VM/XA SP Release 1 is generally compatible with the CMS component of VM/SP Release 5. Major exceptions are: • Some CMS based applications rely on CP functions that are not provided until VM/XA SP Release 2. For example, VM/XA SP Release 1 does not provide native VM SNA or the TSAF function provided in VM/SP Release 5.
• Differences in function provided and implementation between control programs cause some CMS incompatibilities. Programs that use certain CP DIAGNOSE func tions or rely on the syntax or output format of CP commands may require modifica tion due to incompatibilities between VM/SP and VM/XA support.
_ • Since the CMS in VM/XA SP Release 1 has been built on a CMS Release 5 level, users should consult the VM/SP Release 5 publications to determine fundamental differences between CMS Releases 4 and 5, if they are using VM/SP or HPO re leases based on CMS Release 4.
• Programs that operate on SPOOL files owned by another user must now refer to SPOOL files by userid and spoolid. CP spooling commands are enhanced for this support. • Programs using the DIAGNOSE x'58' interface to display 3270 full screen information may not provide the same display results when used with the full screen CMS sup port provided in CMS Release 5. Additional information may be found in "VM/SP Release 5 Library".
• Programs that are sensitive to PSW formats or that do their own I/O processing will require modification due to differences in S/370 and 370-XA architecture.
Specific considerations must be given to CP migration planning in the following areas:
• Some devices that are supported in VM/SP Release 5 or VM/SP HPO Release 5 are not supported by VM/XA SP Release 1; for example. FBA devices such as the 3370 DASD are supported only as dedicate devices.
• The customer will be able to migrate user spool files back and forth between VM/SP HPO and VM/XA SP Release 1, using the SPTAPE function.
•A customer migrating from VM/SP HPO to VM/XA SP Release 1 will be able to take the CP directory CMS file and load it to a VM/XA SP system as is, although HPO-unique statements and options will be ignored. This directory must be modified if the customer wishes to take advantage of 370-XA only functions.
• Many of the directory OPTION options of VM/SP HPO are not supported, namely: REALTIMER, ECMODE, ISAM, PMA, SVCOFF, BMX, AFFINITY, VMSAVE, STFIRST, 370E, XMEM, MAXDEV, DIAG98, COMSRV, LANG, and SVCACCL.
• DASD space used by CP need only be reallocated under VM/XA SP Release 1 before being used.
• User Class Restructure - the OVERRIDE file is now a system spool file (UCR file).
• VSE/VSAM can be used in a 370-mode virtual machine but not in an XA-mode virtual machine.
Migration Considerations 71 • There is no native VTAM support in VM/XA SP Release 1 it will be available in VM/XA SP Release 2. • Some programs have their names changed or do not exist any more:
IPL DDR has an XA version called IPL DDRXA. CPEREP has been replaced by CPEREPXA. DIRECT has been replaced by DIRECTXA. IPL FMT and CPFMT have been replaced by CPFMTXA. IPL DIRECT is not supported. • Handling of named saved systems (NSS) and discontiguous shared segments (DCSS) is different in VM/XA SP Release 1 compared to VM/SP HPO. All NSS and DCSS will have to be reinstalled and, the DASD areas previously used for NSS and DCSS in VM/SP HPO may have to be designated as spool space in VM/XA SP Re lease 1. New versions of saved systems can be installed under VM/XA SP Release 1 without a relPL.
• Maintenance and service of VM/XA SP Release 1 should be performed in the same manner as in VM/SP HPO (for example, source modification). However, some modules of some components are serviced by object deck replacement. Also, the Dump Viewing Facility is used in VM/XA SP Release 1 to examine dumps, as op posed to the use of IPCS in VM/SP HPO. This involves differences in the naming of dumps, in symptom record handling for non-CP dumps, and in the operation of the VMDUMP and PRTDUMP commands.
Details of incompatibilities and migration considerations may be found in: VM/XA SP General Information manual, VM/XA System Product Assembler Program Conversion Guide, and the VM/XA System Product Conversion Notebook.
VM/VSE
If you are migrating from VM/VSE, consider the following:
• 3370 devices are not fully supported in VM/XA SP Release 1. You can dedicate these devices to a VSE guest, but you cannot share the device with another VSE guest.
• CMS/DOS can be used in a 370-mode virtual machine but not in an XA-mode virtual machine.
• VSE/VSAM can be used in a 370-mode virtual machine but not in an XA-mode virtual machine.
• VSE/VCNA is not supported in VM/XA SP Release 2.
MVS
There are no special considerations for MVS. Refer to VM/XA Systems Facility Planning Guide for planning information.
VM/XA SF
In general, VM/XA SP Release 1.0 is upward compatible from VM/XA SF Release 2.0. Application programs that currently execute on VM/XA SF should execute without change unless they are dependent on those functions listed under exceptions, below.
Programs written in higher level languages are source and object level compatible on CMS (that is, CMS supports the same languages for both systems). Programs using
72 VM/XA SP Guide 24-bit virtual storage addresses continue to execute in virtual storage below 16 mega bytes without change.
Programs or EXECs that depend on one or more ofthe following will have to be examined for compatibility:
• CP or CMS structure of control blocks.
• Applications that use undocumented interfaces.
• Programs that depend on the syntax or output format of CP commands.
• DIAGNOSE CODES - All diagnose codes available in VM/XA SF are supported in VM/XA SP Release 1.0.
The changes listed below apply to different releases of VM/XA SF. Check the VM/XA publications for details:
• The installation execs have changed to be more compatible with VM/SP HPO. For example: SPGEN replaces GENERATE and SPGEN PROFILE replaces GENERATE DEFAULTS.
• Some commands and many command responses have changed to be more com patible with VM/SP HPO. This will affect all users. • The word DISPLAY in all commands and messages is generally replaced by GRAF.
Installation and Service
The installation and service tasks include:
Tailoring system generation files • Generating the system • Defining saved segments and image libraries
In this section the differences between VM/SP Release 5, VM/SP HPO Release 5, VM/XA SF and VM/XA SP Release 1 are discussed. Details of an installation and service EXEC are contained in "Appendix C. Installation and Service EXEC Procedure" on page 87.
VM/SP Release 5 and VM/SP HPO Release 5
If you plan to migrate to VM/XA SP Release 1, you should consider the following changes ^ ^ to VM/SP Release 5 and VM/SP HPO Release 5:
• CP directory and control statements
There may be directories on different volumes. VM/XA SP Release 1 uses the first directory it finds on a CP volume.
The following directory options have changed: • USER - has different reserved userids in VM/XA SP Release 1 and you may specify the NOPASS option instead of a password.
• OPTION - the following options are invalid in VM/XA SP Release 1:
REALTIMER, ECMODE, ISAM. PMA, SVCOFF, BMX, AFFINITY, VMSAVE, STFIRST, 370E. XMEM. MAXDEV. DIAG98. COMSRV, LANG, and SVCACCL.
• ACCOUNT - VM/XA SP Release 1 allows multiple account cards.
Migration Considerations 73 • SPECIAL - not all VM/SP HPO devices are supported. The GIGA option requires a userid.
• DEDICATE - the NETWORK and 3330V option is not supported in VM/XA SP Re lease 1.
• MDISK - not all VM/SP HPO device types are supported (for example, 3370).
• lUGV - not all system services are supported. • INCLUDE, PROFILE and SCREEN - are not supported in VM/XA SP Release 1.
RIO macros
The RIO macro file name in VM/XA SP Release 1 is HCPRIO (instead of DMKRIO). The CLUSTER, TERMINAL, RCTLUNIT, and RCHANNEL macros are not supported in VM/XA SP Release 1. The RDEVICE options CLUSTER and DPMSIZE are not valid and the ADDRESS option has changed to DEVNO. Not all VM/SP HPO device types, however, are supported.
SYS macros
The SYS macro file name in VM/XA SP Release 1 is HCPSYS (instead of DMKSYS). The SYSPAG, SYSMON, SYSJRL, and SYSMIH options are not valid in VM/XA SP Release 1. The SYSRES operands SYSCLR and SYSERR are invalid in VM/XA SP Release 1, as well as the SYSDUMP operand ofthe SYSOPR macro. Instead ofthese operands, the new macros SYSDUMP and SYSEREP can be used in VM/XA SP Re lease 1. The macros SYSOWN, SYSCOR, and SYSLOC correspond to SYSCPVOL, SYSSTORE, and SYSEND in VM/XA SP Release 1.
Defining saved systems or segments and image libraries
The DMKSNT macros have been replaced by commands in VM/XA SP Release 1. Instead of:
• The NAMESYS macro - use the DEFSYS and DEFSEG commands. • The NAMENCP macro - there is no equivalent function in VM/XA SP Release 1 • The NAME3800 macro - use the IMAGELIB and IMAGEMOD commands to install and modify image libraries. The segment size in VM/XA SP Release 1 is 1 Mb compared to 64 Kb in VM/SP HPO.
Defining FCBs or character sets
The functions of the DMKFCB, DMKUCB, DMKUCC, and DMKUCS macros are han dled in IMAGE libraries.
VM/XA SF
There are only a few changes if you plan to migrate from VM/XA SF to VM/XA SP Re lease 1: • Additional device support may require changes in the directory, HCPSYS, and HCPRIO. • The size parameter may be added to the XSTORE directory statement for users of Expanded Storage. • Implementation of the spool file limit relief requires a cold-start when bringing up VM/XA SP Release 1 for the first time. You can use SPTAPE to save your spool files and your system data files across the cold-start.
74 VM/XA SP Guide System Management
This section discusses the differences in System Management between VM/SP Release 5 and VM/SP HPO Release 5 on one side and VM/XA SP Release 1 on the other.
VM/SP Release 5 and VM/SP HPO Release 5
You should consider the following if you plan to migrate to VM/XA SP Release 1:
• Managing user access There is a System Data File in VM/XA SP Release 1. In the OVERRIDE file, the TYPE= parameter is replaced by NEWCLASS = .
• Managing National Language Support Only CMS is enabled for MLS, there is no CP support for MLS. Refer to "Appendix D. National Language Support (NLS)" on page 95 for details. • Managing system performance
The Scheduler has been enhanced in VM/XA SP Release 1 and there are new com mands to control the scheduling process.
• Collecting system data
The EREP and accounting information is collected by virtual machines. Some ac counting record types and journaling are not supported in VM/XA SP Release 1.
• Managing networks The following functions are supported in VM/XA SP Release 2:
• Group Control System (GCS) • Systems Network Architecture (SNA)
The following functions are not supported:
• Transparent Services Access Facility (TSAF) • ASCII devices
^ VM/XA SF
Since the Scheduler mechanism has changed, the ABSCPU operand of the SET SRM SHARE command is no longer valid. There are no other special considerations for VM/XA SF.
Real System Operation
This section describes the differences between VM/XA SP Release 1 and VM/SP Release 5, VM/SP HPO Release 5, and VM/XA SF concerning real system operation.
VM/SP Release 5 and VM/SP HPO Release 5
The following tasks and their changes have to be considered for real system operation:
• starting and stopping the system
Migration Considerations 75 The REIPL operand on the SHUTDOWN command can not be used.
Controlling storage
The QUERY PSTOR command has been replaced by QUERY XSTORE. Other storage control commands are ATTACH XSTORE. which specify a size parameter, and DE TACH XSTORE.
The DCP, DMCP and STOP commands to display, dump, and store host storage have been replaced by DISPLAY H, DUMP H, and STORE H, respectively.
Controlling I/O devices
The ATTACH CHANNEL command is not available in VM/XA SP Release 1. The ATTACH rdev and DETACH rdev commands work asynchronously in VM/XA SP Re lease 1.
The CACHE command has been replaced by the ATTACH, SET CACHE, and QUERY CACHE commands.
Controlling spool devices
Advanced Function Printing Subsystem Support (VM/APSS) is not supported by VM/XA SP Release 1
Managing data files
Named Saved Systems and Discontiguous Saved Segments are defined with the DEFSYS and DEFSEG commands. DMKSNT no longer exists, and you no longer have to generate a new nucleus if you made a change to the saved segments.
System files reside in the spool space. You should back up these files and set up a procedure to load them after a cold start.
Commands to query and delete system files are:
• QUERY NSS and PURGE NSS
- QUERY IMG and PURGE IMG
- QUERY DCSS and PURGE DCSS
- QUERY UCR and PURGE UCR
Managing system recovery
Instead of SET DUMP AUTO, you have to specify SET DUMP DASD.
Running utility programs.
The DIRECT command is called DIRECTXA in VM/XA SP Release 1 and similarly, CPEREP is called CPEREPXA. The IPL DDR file is renamed IPL DDRXA. IPL DIRECT is not supported in VM/XA SP Release 1. IPL FMT is replaced by the CPFMTXA command. The OVERRIDE command syntax is different ( more parameters ) and deals with systems data files that reside on a spool space.
VM/XA SF
The following tasks and their changes have to be considered for real system operation:
• Controlling storage
The QUERY STORAGE command has been changed to QUERY FRAMES. The QUERY REAL STORAGE command now returns only the size of the real storage.
76 VM/XA SP Guide • Controlling I/O devices The DISPLAY operand on the DEFINE DISPLAY and QUERY DISPLAY commands has been changed to GRAF.
• Controlling spool devices A spool file is now identified by the userid and a spoolid. The SYSTEM operand is no longer valid in combination with a spoolid, because the spoolid is no longer unique in the system.
• Running utility programs
CPFMTXA, DDR, DIRECTXA, DUMPLOAD, HCPLDR, and HCPSADMP are not sup ported in an XA-mode virtual machine.
• Running program products
VM/XA RTM/SF is not supported in an XA-mode virtual machine.
^ Virtual Machine Operation
This section discusses the differences between VM/XA SP Release 1 and VM/SP Release 5, VM/SP HPO Release 5, and VM/XA SF concerning virtual machine operation.
VM/SP Release 5 and VM/SP HPO Release 5
The following tasks and their changes have to be considered for virtual system operation:
• Communication with users and with CP
The DEFINE CTCA command requires a userid operand in VM/XA SP Release 1.
• Running the virtual machine The PMA option is not valid on the IPL command. In contrast to VM/SP HPO, the SYSTEM CLEAR command in VM/XA SP Release 1 resets I/O and registers. A SYSTEM RESET cancels the TERM CONMODE setting, which it did not in VM/SP HPO. Therefore, you should be careful if you want to define another console type and you issue a command that causes a system reset. The ATTN, HILIGHT, and SCRNSAVE options of the TERMINAL command are not supported in VM/XA SP Re lease 1. The CP command SCREEN is not supported in VM/XA SP Release 1.
• Managing the virtual machine environment In VM/XA SP Release 1, you can define a virtual machine with up to 999 Mb. You can also define additional virtual CPUs to set up a virtual multiprocessing system. Not all the operands of the SET command of VM/SP HPO are supported in VM/XA SP Release 1.
• Managing virtual I/O The 3-digit addresses (vaddr) of VM/SP HPO have been replaced by 4-digit device numbers (vdev) in VM/XA SP Release 1. On the DEFINE command, the CHANNEL, T2314, T2319. T3310, T3370, and SYSVIRT options are not valid.
VM/XA SF
Migration Considerations 77 The following tasks and their changes have to be considered for virtual machine opera tion:
• Managing the virtual processing environment The responses to the QUERY SET command have changed. The information that is first displayed is compatible with the VM/SP HPO format.
• Managing virtual I/O The QUERY TERMINAL responses are in VM/SP HPO format. The DISPLAY option on the DEFINE and QUERY command has been replaced by the GRAF option. The LINEDIT, MSG, WNG, EMSG, and IMSG options of the TERMINAL command are not supported in VM/XA SP Release 1.
• Managing spool files In VM/XA SP Release 1, spool files are identified by userid and spoolid. For a gen eral user, however, there is no change in most of the commands because the userid is internally added to identify his spool file.
Application Program Deveiopment and Debugging
This task includes activities that create new applications on VM/XA SP Release 1 and that migrate existing applications to run on this system. This section discusses differ ences in application program development and debugging that might be important during your migration.
VM/SP Release 5 and VM/SP HPO Release 5
If you plan to migrate from VM/SP Release 5 or VM/SP HPO Release 5 to VM/XA SP Release 1 you should consider the following:
• Initiating user connections The IPL command does not allow you to IPL by block number from an FBA device, and the PMA operand is not valid. The LOGON command allows you to reenter the password if it was mistyped. • Managing the processing environment If SET RUN ON has been specified and the virtual machine becomes disabled, RUN is not forced off.
The SLEEP command does not terminate on a reconnect of a virtual machine.
• Managing virtual I/O
The response ofthe COUPLE command is different in VM/XA SP Release 1 from that of VM/SP HPO Release 5. The SET PF COPY command needs a printer address in VM/XA SP Release 1. The TERMINAL command has no SCRNSAVE option.
The following commands are not supported in VM/XA SP Release 1:
• DEFINE SYSVIRT - (virtual MSS) • DEFINE TIMER - (pseudo-time) • DEFINE 1443 3262 3289E - (spooling printers) • QUERY VIRTUAL CHANNEL - (no virtual channel)
• Debugging
78 VM/XA SP Guide TRACE stops after each instruction, and ADSTOP is not supported in VM/XA SP Re lease 1. Additional commands, however, exist. PER is a synonym for TRACE but there are differences from the PER instruction of VM/SP HPO.
• Managing spool files The PURGE command does not have ALL as the default option. The response for mats of the CLOSE and TRANSFER commands have changed.
• Error messages The error messages of several commands have changed in VM/XA SP Release 1. • Programming Wherever possible, the new programming interface macros provided with bimodal CMS should be used in preference to the older macro forms.
VM/XA SF
Some of the changes mentioned below apply to different releases of VM/XA SF. Check the VM/XA publications for details. Ifyou plan to migrate from VM/XA SF to VM/XA SP Release 1 you should consider the following: • Managing the processing environment and virtual I/O
The SLEEP command has different return codes. The DETACH vdev and the REWIND command have changed response formats.
• Debugging The DISP DUMP and DISP/DUMP REGS commands have a respond format compat ible with VM/SP HPO.
• Error messages The error messages of several commands have changed in VM/XA SP Release 1.
DIAGNOSE Codes
Most of the DIAGNOSE codes in VM/XA SP Release 1 are compatible with those of VM/SP HPO Release 5. For detailed information, refer to "Appendix B. DIAGNOSE Codes" on page 83.
Migration Considerations 79 80 VM/XA SP Guide Appendix A. Summary of Changes from Prior Releases
The following tables summarize some changes you should be aware of If you plan to migrate from VM/SP (HPO) Release 5 or VM/XA SF to VM/XA SP Release 1. This list Is not complete. For a complete discussion of the changes, refer to VMfXA SP Conversion Notebook.
Function / If you migrate If you migrate VM/XA SP Cotntnand or from VM/SP(HPO) RS from VM/XA SF Option to VMyOCA SP you to VM/XA SP you Remarks should know that.. should know that.
Virt. mach. 16Mb virtual 999Mb virtual environment storage*limit storage limit
Managing SRM SHARE ABSCPU scheduler commands syst. perf. no longer valid enhanced
Networks SNA> GCS, ASCII -> not supported
TSAF TSAF not supported
DIRECTORY not all HPO R5 DIRECTORY on diff. devtypes supported volumes USER different reserved new NOPASS option userids OPTION not supported are: REALTIMER^ ECMODE, ISAM, PMA, SVCOFF, BMX, AFFINITY, VMSAVE, STFIRST, 370E, XMEM, MAXDEV DIAG98, COMSRV, LANG, SVCALLL SPECIAL not all devtypes CTCA reqs. userid DEDICATE NETWORK not supp. MDISK not all devtypes others not supported: new in VM/XA SP: ACIGROUP, INCLUDE, AUTOLOG, CPU, SRM, PROFILE, SCREEN DASDOPT, MACHINE, MINIOPT, NAMESAVE, NOPDATA, SHARE, SPOOLFILE, XSTORE
Controlling QUERY PSTOR —> Q XSTORE, ATT/DET Storage XSTORE DCP, DMCP, STCP -> DISPLAY H, DIAIP H, STORE H QUERY REAL STG —> QUERY FRAMES DEF/QUERY DISP --> DEF/QUERY GRAF
Contr. I/O no ATTACH CHAhWEL ATT/DET rdev ~> Asynchronous CACHE --> ATTACH, SET CACHE, QUERY CACHE
Contr.SPOOL APSS not SL^sported Spool file ident. by userid and spoolid Contr. DUMP SET DW1P AUTO ~> SET DUMP DASD
Appendix A. Summary of Changes from Prior Releases 81 Function / If you migrate If you migrate VM/XA SP ConKnand or from VM/SP (HPO) 5 from VM/XA SF Option to VM/XA SP you to VM/XA SP you Remarks should know that.. should know that..
RIO macros DMKRIO —> HCPRIO no: CLUSTER> TERMINAL, RCTLUNIT RCHANNEL RDEVICE-ADDRESS -> RDEVICE-DEVNO not all dev. si43p> SYS macros DMKSYS —> HCPSYS SYSOWN —> SYSCPVOL not supported: new: SYSPAG, SYSMON, SYSDUMP, SYSEREP, SYSJRL, SYSMIH SYSUVOL SYSCOR —> SYSSTORE SYSLOC —> SYSEND
def. SEGM. DKKSNT —> Commands: or SYSTEM NAKESYS DEFSYS, DEFSEG NAMENCP not supp. NAME3800 ~> IMAGELIB and IMAGEMOD cmd. SNTMAP tool ~> q NSS w/MAP option segm. size 64K —> segm. size def. FCBs DWCFCB .—> IMAGxxxx libraries and Char. DracucB, Dra
Utility DIRECT ~> DIRECTXA Programs IPL DIRECT —> not supported CPEREP —> CPEREPXA IPL FMT ~> CPFMT IPL DDRXA
LOGON no HELP from LOGO DIAL - HPO respons
Running a SYSTEM CLEAR ~> resets I/O and virt. mach. registers TERMINAL ATTN, —> not supported HILIGHT, SCRNSAVE not supported SYSTEM RESET —> cancels TERMINAL CONMODE setting Managing 3-digit vaddr > 4-digit vdev virt. I/O DEFINE CHANNEL, -> not supported T231<^, T2319, -> not supported T3310, T3370, -> not supported SYSVIRT -> not supported TERMINAL LINEDIT, not supported MSG,NN6,EMSG,IMS6 not supported
Command q VIRT CONS, responses responses Q DISP, DET vdev, changed to LOCATE, STORE, HPO format DISPLAY, DUMP ~ in HPO format
Managing DEFINE does not processing supp. all HPO dev. environment SLEEP does not SLEEP return codes term, on recom. are different System ' some messages have some messages have 3- and A^-digit messages changed changed message numbers Dev. Scfip. 3370 not supported Expanded for paging and dedicated to partitioned for Storage swapping > one guest > CP (paging) and one guest
NLS only CMS enabled
82 VM/XA SP Guide Appendix B. DIAGNOSE Codes
This appendix provides a summary of the compatibility of VM/XA SP Release 1 DIAG NOSE codes with earlier releases.
Compatible DIAGNOSE Codes
The following diagnose codes are compatible with those of earlier releases:
X'04' Examine Real Storage X'08' Virtual Console Function X'OC Pseudo Timer X'10' Release Pages X'14' Input Spool File Manipulation X'4C' Generate Accounting Records X'54' Control the Function of PA2 X'60' Determine Virtual Storage Size X'68' VMCF X'70' Activating TOD Clock Accounting X'80' MSSFCALL X'BO' Access information Saved for Protected Application Users X'DO' 3480 Tape Volume Serial Support
Upward Compatible DIAGNOSE Codes
The following diagnose codes are upward compatible with those of earlier releases:
• X'28' Channel Program Modification
VM/XA SP Release 1 provides an extra return code.
• X'SC Directory
VM/XA SP Release 1 provides an extra return code.
• X'40' Clean-up After IPL VM/XA SP Release 1 provides two clean-up routines after IPL.
• X'48' Issue SVC 76 Second Level
VM/XA SP Release 1 treats this code as a no-op; VM/XA SP Release 1 function provided by CP command SET SVC76. • X'SC Error Message Editing
VM/XA SP Release 1 uses 4-digit message numbers for numbers over 999; also re turns length of 11 for 4-digit number and allows for variable length headers
Appendix B. DIAGNOSE Codes 83 • X'64' Named Segments VM/XA SP Release 1 provides return codes 53, 304, 449, and 475 for condition code 2, which VM/SP HPO does not.
• X'74' 3800 Named System
VM/XA SP Release 1 has new condition and return codes. "
Incompatible DIAGNOSE Codes
The following diagnose codes are incompatible with those of earlier releases:
• X'OO' Store Extended ID
VM/XA SP Release 1 returns a different system name and different bit map.
• X'18' Standard DASD I/O VM/XA SP Release 1 gives return code 7 for different CON problems than VM/SP HPO's return code 7.
DIAGNOSE X'18' cannot be issued from an XA-mode virtual machine.
X'20' General I/O
VM/XA SP Release 1 returns only sense bytes 0 and 1 in Ry for return code 13; VM/XA SP Release 1 provides Os for sense l)ytes 2 and 3.
DIAGNOSE X'20' cannot be issued from an XA-mode virtual machine.
X'24' Device Type, Features
VM/XA SP Release 1 gives the same control block fields, but does not provide all the bits in VDEVSTAT and VDEVFLAG.
X'34' Read Dump Spool File
Dump files have different formats.
X'58' 3270 Virtual Console Interface
VM/XA SP Release 1 and VM/SP HPO are compatible in operation and interface. However, since specific sequences regarding channel program operations are not documented in either system, there may be functional inconsistencies between the two systems.
The following rules apply.,
1. The channel program must begin with a valid DIAGNOSE X'58' command code; X'19'. X'29'. and X'2A'.
2. A X'19' write can be command chained to another X'19', a TIC, or a NO-OP.
3. A X'19' with a CTL value of X'FF' or X'FE' can be chained to any other X'19', or to a X'29', or to an intervening TIC or NO-OP. In the X'29' case the X'19' must be the first CCW in the channel program.
4. A X'29' or X'2A' can be chained to another X'29', a X'2A', a TIC, or a NO-OP.
X'7C' Logical Device Support
84 VM/XA SP Guide VM/XA SP Release 1 has a limit of eight virtual machines that can create logical devices; VM/XA SP Release 1 provides logical printer support and allows 4-digit virtual device addresses.
• X'8C' Access Device Dependent Information VM/XA SP Release 1 may return a protection exception where HPO does not.
VMISP HPO Only DIAGNOSE Codes
The following Diagnose Codes are used only with VM/SP HPO:
X'1C' Clear Error Recording X'2C' DASD Start of LOGREC X'30' Read Page of LOGREC X'38' Read System Symbols X'50' Save 370x Image X'6C' Shadow Table Maintenance X'78' MSS Communications X'84' Directory Update X'94' VMDUMP Function X'98' Real Channel Program Support X'AO' Retrieve a Group Name X'B4' Virtual Printer Extended Attribute Buffer Manipulation X'B8' Spool File Extended Attribute Buffer Manipulation X'C8' MLS Set X'CC NLS Save X'D4' Alternate Userid
VMIXA SP Release 1 Only DIAGNOSE Codes
The following Diagnose Codes are used only by VM/SP: X'44' Voluntary Time Slice End X'90' Read Symbol Table X'A4' DASD I/O for System/370 or 370-XA X'A8' General I/O for System/370 or 370-XA X'C4' Handle Class Override Data for UCR
Appendix B. DIAGNOSE Codes 85 86 VM/XA SP Guide Appendix C. Installation and Service EXEC Procedure
Some Improvements have been made to installation and service for VM/XA SP Release 1. As a base component, VM/XA SP Release 1 supplies a CMS that can execute on both 370-mode and XA-mode virtual machines. We refer to this CMS as bimodal CMS. As it is a base component, bimodal CMS is installed as one part of the standard system in stallation. The installation exec for bimodal CMS will generate one CMS nucleus and two saved systems- one for CMS in 370-mode and one for CMS in XA-mode. (Additional information on the installation and service EXEC are contained in Bimodal CMS for VM/XA Systems.) Installation and service execs similar to those supplied by VM/SP Release 5 are supplied for VM/XA SP Release 1. Most of the installation activities are similar to those In VM/SP Release 5. tasks are:
• Installation Task The installation task prompts you through a number of optional tasks. By selecting those you want, the installation task allows you to:
• Load system files • Install Assembler H Version 2 • Generate the nucleus
• Administration Task
The administration task consists of four categories. Each category uses one or more of the HCPSYS, HCPRIO and system control file. These categories are:
• User administration • Storage administration • Device administration • Processor administration
• Service Task
The service task consists of two categories:
• Corrective service • Preventive service
Installation EXEC
For compatibility with VM/SP Release 5 the VM/XA SP Release 1 installation execs are called:.
• ITASK EXEC - initial installation tasks • SPLOAD EXEC - tape loading manager
Appendix C. Installation and Service EXEC Procedure 87 • SPLOAD PROFILE - product tape format • SPGEN EXEC - system generation tasks • SPGEN PROFILE - system parameter description • UTILITY EXEC - utility generation tasks
ITASK EXEC
This exec is used during VM/XA SP Release 1 system installation and utilizes the SPLOAD EXEC that installs the VM/XA SP Release 1 system according to the information in the SPLOAD PROFILE. By using this exec, you can load files for CP, CMS, Dump Viewing Facility (DVF), HELP, source and national language files, perform assemblies of HCPSYS, HCPRIO, and HCPBOX files, and build the CP and CMS nucleus.
The format of the ITASK command is:
LOAD
BUILD
ASSEyeiE
ALLOCATE
BASEIDS
Figure 19. ITASK Command Format
where:
LOAD Invokes the SPLOAD EXEC to load the files from the product tape, source tape, or national language feature tape.
BUILD Invokes the SPGEN EXEC to build CP and CMS nucleus using information supplied in the SPGEN PROFILE.
ASSEMBLE Invokes the SPGEN EXEC to assemble HCPSYS, HCPRIO, and HCPBOX file. ALLOCATE Allocates space on the DASD volumes according to the $ALLOC$ userid in CP directory. BASEIDS Formats the remaining minidisks defined in the CP directory to which files were not loaded during the installation process, or were not associated with any particular base component.
88 VM/XA SP Guide SPLOAD EXEC r^ The SPLOAD EXEC is used to load files from the product tape to the appropriate mini disks. It uses the information in SPLOAD PROFILE to determine where the files are to be loaded. SPLOAD may be invoked from the ITASK EXEC.
The format of SPLOAD command is:
SPLOAD element
Figure 20. SPLOAD Command Format
where:
group Is a name associated to a general category of files such as 'CP' or 'System'. This is an arbitrary name, and together with the element, uniquely names a tape file in-the SPLOAD PROFILE.
element Is a specific member of group. The group and element names together uniquely name a tape file entry in the SPLOAD PROFILE.
fn ft Form a file specification template. By default they are set to asterisks (meaning all files within a tape file), but may be set to other values according to the rules for file specifications on the VMFPLC2 command line. The tem plate is used to selectively load specific files from a tape file to a minidisk.
SPLOAD PROFILE
The SPLOAD PROFILE contains information such as:
Group name of a category Element name of group Userid of the owner of the target minidisk Minidisk address of the target minidisk Format of the tape Relative tape number Relative tape file number his profile is referred to by the SPLOAD EXEC during VM/XA SP Release 1 system in stallation to find the products on the tape and also where to load them. An SPLOAD command is supplied to maintain this profile.
The format of SPLOAD PROFILE is:
group element userid address format volume tope.file
Figure 21. SPLOAD PROFILE Format
where:
Appendix 0. Installation and Service EXEC Procedure 89 group Is a name associated with a general category of files such as 'CP' or 'Sys tem'. This is an arbitrary name, and together with the element, uniquely names a tape file in the SPLOAD PROFILE. element Is a specific member of group. The group and element names together uniquely name a tape file entry in the SPLOAD PROFILE. userid Is the owner of the minidisk to which the tape file contents are to be loaded. This information is used only if SPLOAD must attempt to do a LINK to the minidisk in order to load the tape file contents to it (after also doing an AC CESS). address Is the minidisk address to which the tape file is to be loaded. If this field is filled with '?' then SPLOAD prompts for the minidisk address. format Specifies the format of the tape. The SPLOAD PROFILE has a complete table for each tape to describe the location of the product tape files. The SPLOAD EXEC selects the appropriate entry in the profile depending on the format found in the tape file header of the product tape. volume Is the relative tape number on which the particular product tape file resides. tape file Is the relative file number on the particular product tape for the specified tape file.
SPGEN EXEC
You use the SPGEN EXEC to perform system assemblies, generate the system nucleus for CP or CMS, apply maintenance to the system, or maintain the SPGEN PROFILE.
The format of SPGEN command is:
SPGEN CREATE (opt ionA]
VERIFY (opt i onA]
DISPLAY ALL ^~| (opt i onA) comp idJ
ASSEUBLE f n comp i d (opt ionA)
SETUP compid (opt ionA)
NUCLEUS compid (opt ionA opt ionB)
MAP comp i d (opt i onA)
DTYPE vi rtaddr
Figure 22. SPGEN Command Format
where: CREATE Writes the SPGEN PROFILE (or the specified profile) on your A-disk.
90 VMfXA SP Guide VERIFY Reads and parses the SPGEN PROFILE (or the specified profile) displaying messages if errors were encountered in the file. DISPLAY Displays profile keyword values and their associated commentary from the SPGEN PROFILE (or the specified profile) for ALL components (or the speci fied component).
ASSEMBLE Assembles the system files using information in the SPGEN PROFILE (or the specified profile) and then invokes VMFHASM EXEC for the specified filename, using the control filename for CP (or the specified component) indicated in the profile.
SETUP Runs each instruction in the list that follows the SETUP tag for the specified component in the SPGEN PROFILE (or the specified profile). SETUP com mands may be any combination of ACCESS, LINK, or EXEC commands.
NUCLEUS Builds a system nucleus for the specified component. The steps are:
• Executes the list of instructions that follows the SETUP tag for the com ponent in the SPGEN PROFILE. • Spools the punch as class N (for Nucleus) and the printer as class M (for Map).
• Invokes the HCPLDR EXEC using the loadlist and control filenames from the SPGEN PROFILE (or the specified profile).
• Spools the reader as class N (for Nucleus). The spool file for CP nucleus is left in the reader until it is loaded (IPL OOC).
MAP Names the first available class M reader file to whatever file specification is indicated by the specified component's MAPNAME tag in the SPGEN PROFILE (or the specified profile).
•TYPE Issues a DIAGNOSE X'24' for the specified virtual device address, uses the returned information to look up the DASD type in the $DASD$ CONSTS file, and returns that information to the terminal (if the SPGEN DTYPE is executed) or to the program stack (if the SPGEN DTYPE is called).
compid The identification of the component being generated.
Options Permit the user to redefine default information:
• Option A permits the user to specify a profile to be used instead of SPGEN PROFILE. The format is PROFile (profile name). • Option B indicates that the nucleus being built should be written to DISK, TAPE or PUNch in preference to the destination specified in the SPLOAD PROFILE.
SPGEN PROFILE
The SPGEN PROFILE contains the miscellaneous information that the SPGEN EXEC re quires for nucleus generation, this includes the following entries, each identified by the name of the component to which they apply:
The control file name. The loadlist name. The name to be used for the nucleus map. The userid of the owner. The destination of the loader file (tape, disk or punch).
Appendix C. Installation and Service EXEC Procedure 91 The format of SPGEN PROFILE is:
comment imbeded in the prof iIe (not used)^
:compname.CONTROL. < fn > l^comment < ♦ > :compname_LOADLIST. < fn > [^comment < * > :compnQme_MAPNAME. < fn fftl > [^comment < ♦ > :compname_MAPUSEID. < userid > [|/» [^comment < ♦ >
;compname_DEST. < DISK,PUN,TAPE > comment < ♦ > [/•[ :compname_SETUP. [/•[ comment Qlist of CP, CMS commands)^ [/•[ comment
Figure 23. SPGEN PROFILE Format
UTILITY EXEC
UTILITY EXEC allows you to perform Infrequently used Installation utility functions, such as:
Printing the sample definition files such as USER DIRECT. USER DISKMAP, HCPSYS ASSEMBLE, and HCPRIO ASSEMBLE.
Creating stand-alone utilities, such as IPL DSF and IPL DDR.
Writing CP nucleus to tape.
Creating the CP load list of CPLOAD EXEC.
Generating utilities such as DIRECTXA MODULE. IPL DDRXA. and CPEREPXA MODULE.
Installation Steps
Overall installation steps for bimodal CMS in VM/XA SP Release 1 are:
1. Install the starter system.
2. Load the installation tools and sample files.
3. Load CP, CMS. and Dump Viewing Facility (DVF) files from the product tape.
92 VM/XA SP Guide 4. Generate CMS.
5. Install and generate Assembler H Version 2. 6. Assemble system definition files of HCPSYS, HCPRIO, and HCPBOX file.
7. Generate CP nucleus.
8. Shut down and re-IPL the new CP system.
9. Install EREP for VM.
10. Back up CMS using SPTAPE.
11. Back up the new CP system using DDRXA.
Appendix C. Installation and Service EXEC Procedure 93 94 VM/XA SP Guide Appendix D. National Language Support (NLS)
VM/SPRelease 5 introduced National Language Support to help users communicate with VM {CMS in particular) in their own language.
Enabling Normally, you enter CMS commands in American English, the panels you see are in American English, and the messages you receive are in American English. However, you can order and install other languages on your VM/XA SP Release 1 sys tem. This lets you interact with CMS in your own national language. You receive mes sages and see panels (helpfiles) in your own language (if it is available on your system). The VM/XA SP Release 1 is shipped with mixed case American English. The following languages will be provided as separate features:
• French • German • Kanji r > • Brazilian Portuguese • Upper-case English Note: Be sure that your terminals and printing equipment can properly display the char acter set of any language you order. The National Language Support that you can order does not permit you to enter com mands in your own language. This means that you have to enter your command in English and you get the response in your language. The Definition Language for Command Syntax (DLCS), however, allows you to create your own command syntax, in your own language. In VM/XA SP Release 1, only CMS, (not CP) is enabled for National Language Support. You still have to enter CP commands in English, and you will receive the responses in English.
Making Other Languages Availabie
VM/XA SP Release 1 allows several languages on one system. The system administra tor must decide whether to use the new language as a system default instead of Ameri can English or just make the language or languages available as an option to the users. The administrator must load the appropriate language files into the CMS nucleus. The procedure for doing so is similar to the one used for adding a local update. However, to make another language available as just an option to users, the adminis trator must:
Appendix D. National Language Support (NLS) 95 • Create a Saved System for the CMS language files. • Use the LANGMERG command to combine all CMS language files. • Use the LANGGEN command to save the CMS language files. Once the files for a language are saved, you can issue the SET LANGUAGE command to set the current language of the CMS session and any applications running in CMS that utilize the National Language Support. The language may be set any time during the session. SET LANGUAGE may be issued by an application, by a user in an application, from within an exec, or from the CMS command line. Installations may select a translated language to be the system default for CMS mes sages and HELP. This selected language is the default for all users until a different lan guage is selected by the SET LANGUAGE command. You can also check the language status of your virtual machine using these commands: QUERY LANGUAGE displays the current language QUERY LANGLIST displays a list of valid languages you can SET for CMS. Each user may select a different language, which could result in multiple languages be- ing utilized at the same time on the same system. It is possible to create a message repository for storing message texts. In this way, just this single message file has to be translated if you want these messages to be available in a language other than American English.
Bimodal CMS enhances two areas of NLS: • The PARSECMD macro, which now recognizes 31-bit module entry conventions. • The Definition Language for Command Syntax (DLCS), which now recognizes 4-digit device addresses. ^ ^
96 VM/XA SP Guide Index
•BLOCKIO 13 DMKSNT 73. 75 DMKSYS 73 dormant list 36-40
application program development 78 APSS 75 ASCII 75 eligible list 36-40 ATTACH CHANNEL 75 expanded storage 6 EO. El. E2. E3 37
F CACHE 75 CCW TRANS 14 FCBs 73 CCW Translation Redesign 63 channel subsystem 6 COMMANDS ATTACH XSTORE 48 DEDICATE 46 DETACH XSTORE 49 GCS {Group Control System) 11, 75 QUERY V = R 52 QUERY XSTORE 49 UNDEDICATE 46 H control block identification 14 Control Block Identifier 63 HCPRIO 73 CTCA 77 HCPSYS 73 Hotshot 35
DCP 75 debugging 78 lABIAS 40 DEFSEG 73 IMAGE libraries 73 DEFSYS 73 installation and service 14. 73 DIAGNOSE codes 13. 83-85 Installation and Service EXEC Procedure 87 DIAL 78 directory statements 73 Installation EXEC 87 dispatch list 36-40 Installation Steps 92 Interactive 35 DLCS 95 Interpretive Execution 7 DMKRIO 73 ITASKEXEC 88
Index 97 Last Translated Address Lookaside Buffer 13 RACF 7 Logged-On User Limit Enhancements 14, 64 RAS and Usability Enhancements 63 LOGON 78 Real System Operation 75-77 REIPL 75 Resource 34 M
message compatibility 14 message numbers 14 microcode assists 7 saveareas 34 Migration 67-79 scheduler 13, 33. 34-41 monitor 13 service 73 MPG 14. 41 SET DUMP 75 SET SHARE 38 DSPBUF 40 N lABIAS 40 LDUBUF 40 STORBUF 38 N-way 6, 13 Share 35 NLS (National Language Support) 75. 95 SIE (Start Interpretive Execution) 7 SLEEP 78 SNA (Systems Network Architecture) 11. 75 Software Last Translated Address Lookaside Buffer 33 SPGENEXEC 90 override file 75 SPGEN PROFILE 91 SPLOAD EXEC 89 SPLOAD PROFILE 89 spool file limit relief 13. 19 SQL/OS 7. 13 performance 33 STOP 75 PL/AS 64 system management 75 PMA (Preferred Machine Assist) 7 SYSTEM RESET 77 preferred guest 6 printers 14 PROFS 7 program development 78 program products 11 TERMCONMODE 77 Prop 27 TERMINAL 77 PROP (Programmable Operator) 13 Terminal Availability Enhancements 14. 64 Protected Application 13 terminals 14. 34 PSTOR 75 Time-slice 34 Transaction 35 TSAF (Transparent Services Access Facility) 11
QUERY command changes 77 u QUICKDSP 40
UCR (User Class Restructure) 13 UTILITY EXEC 92
98 VMfXA SP Guide X
V=R 6 XSTOR 75 Virtual Machine Operation 77-78
Index 99 VM/XA SP Guide Title: VM/XA SP GUIDE READER'S International Technical Support Center COMMENT Technical Bulletin FORM
You may use this form to communicate your comments about this publication, its organization, or subject matter, with the understanding that IBM may use or distribute whatever information you supply in any way it believes appropriate without incurring any obligation to you.
Yes No
Does the publication meet your needs?
Did you find the material:
Easy to read and understand? • • Organized for convenient use? • • Complete? • •
Well illustrated? • •
Written for your technical level? • •
What is your occupation?
How do you use this publication:
As an introduction to the subject? • Asan instructor inclass? Q For advanced knowledge of the subject? n As a student in class? •
To learn about operating procedures? • As a reference manual? •
Your comments:
If you would like a reply, please supply your name and address on the reverse side of this form.
Thank you for your cooperation. No postage stamp necessary if mailed in the U.S.A (Elsewhere, an IBM office or representative will be happy to forwards your comments or you may mail directly to the address in the Edition Notice on the back of the title page.) Reader's Comment Form
n 0) Tl Q C o m
Fili •«< Tiff Fliiif It III Slifli riN lU Tifi
NO POSTAGE NECESSARY IF MAILED IN THE UNITED STATES
BUSINESS REPLY MAIL FIRST CLASS PERMIT NO. 40 ARMONK, N.Y.
POSTAGE WILL BE PAID BY ADDRESSEE:
IBM International Technical Support Center Department H52, Building 930 P.O. Box 390 Poughkeepsie, New York 12602 U.S.A.
If you would like a reply, please print: Your Name Company Name Department Street Address City State Zip Code IBM Branch Office serving you •D 7}
m D
I m Title: VM/XA SP GUIDE READER'S International Technical Support Center COMMENT Technical Bulletin FORM
You may use this form to communicate your comments about this publication, its organization, or subject matter, with the understanding that IBM may use or distribute whatever information you supply in any way it believes appropriate without incurring any obligation to you.
Yes No
Does the publication meet your needs?
Did you find the material:
Easy to read and understand? • • Organized for convenient use? • • Complete? • •
Well illustrated? • •
Written for your technical level? • •
What is your occupation?
How do you use this publication:
As an introduction to the subject? • Asan instructor in class? •
For advanced knowledge of the subject? • As a student in class? •
To learn about operating procedures? Q As a reference manual? •
Your comments:
If you would like a reply, please supply your name and address on the reverse side of this form.
Thank you for your cooperation. No postage stamp necessary if mailed in the U.S.A (Elsewhere, an IBM office or representative will be happy to forwards your comments or you may mail directly to the address in the Edition Notice on the back of the title page.) Reader's Comment Form
CO •O Q c o m
FiK h4 Tt|« Finn III Itirli Fill Hi Tim
NO POSTAGE NECESSARY IF MAILED IN THE UNITED STATES
BUSINESS REPLY MAIL FIRST CLASS PERMIT NO. 40 ARMONK, N.Y.
POSTAGE WILL BE PAID BY ADDRESSEE:
IBM International Technical Support Center Department H52, Building 930 P.O. Box 390 Poughkeepsie, New York 12602 U.S.A.
if you would like a reply, please print: Your Name Company Name Department Street Address City State Zip Code IBM Branch Office serving you TJ 5 z H m o
X m VM/XA Sy^S'tem Product Guide G24-3173-(l PRINTED IN THE U.S.A.
K1
O ^ , Technical Newsletter This Newsletter No.: GN68-0500-00
Date: September 15, 1987
Base Publication No.: GG24-3173-00
VM/XA SYSTEM PRODUCT GUIDE
(c) Copyright IBM Corporation 1987
Please make the following pen-and-ink corrections:
On page 37, the information: EO You use this class Ifyou are "just passing through" and do NOTwait for re sources to become available, (an example would be if you run with QUICKDSP set. or Ifyou were a "hotshot" transaction, or if you are the V= R virtual machine.)
should be replaced by: EO You use this class if you are "just passing through" and do NOT wait for re sources to become available, (an example would be if you run with QUICKDSP set. or if you were a "hotshot" transaction). You need to set the QUICKDSP option if you want a V= R virtual machine to become an EO virtual machine.
On page 40, the information: Note: Do not use QUICKDSP for too many users. The option is designed for a few. crit ical response service machines. Indiscriminate use nullifies the attempts made by the Scheduler to balance loads against resources. QUICKDSP should NOT be used for interactive users, and is not relevant to the V = R machine.
should be replaced by:
Note: Do not use QUICKDSP for too many users. The option is designed for a few. crit ical response service machines. Indiscriminate use nullifies the attempts made by the I Scheduler to balance loads against resources. QUICKDSP should NOTbe used for I interactive users.
IBM Corporation, International Technical Support Center Department H52, Building 930 P.O. Box 390 r y Poughkeepsie, New York 12602 U.S.A.
Printed in the U.S.A.