Customization - IBMpublib.boulder.ibm.com/tividd/td/job/SH19-4502-00/en_US/... · 2006. 10. 25. ·...

NetView Access Services (MVS/ESA) IBM

CustomizationVersion 2 Release 1

SH19-4502-00

Note!

Before using this information and the product it supports, be sure to read the general information under “Notices” on page xi.

First Edition, December 1997

This is a major revision of, and obsoletes, SH12-5812-01. Technical changes or additions to the text and illustrations are indicatedby a vertical line to the left of the change.

This edition applies to Release 1 Modification Level 1 of NetView Access Services Version 2 (MVS/ESA) (Program Number5695-036) and to all subsequent releases and modifications until otherwise indicated in new editions or technical newsletters.

Order publications through your IBM representative or the IBM branch office serving your locality. Publications are not stocked at theaddress below.

IBM welcomes your comments. A form for readers’ comments may be provided at the back of this publication, or you may addressyour comments to the following address:

NVAS Information DevelopmentRome Tivoli LaboratoryIBM Italia S.p.A.Via Sciangai, 53

00144 Rome Italy

When you send information to IBM, you grant IBM a nonexclusive right to use or distribute the information in any way it believesappropriate without incurring any obligation to you.

Copyright International Business Machines Corporation 1987, 1997. All rights reserved.Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is subject torestrictions set forth in GSA ADP Schedule Contract with IBM Corp.

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiProgramming Interface Information . . . . . . . . . . . . . . . . . . . . . . . . . . xiTrademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

About This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

| What Is New in NetView Access Services Version 2.1.1 . . . . . . . . . . . xv| External Application Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . xv| Direct Logon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv| Compact Application Selection Panel . . . . . . . . . . . . . . . . . . . . . . . . xv| Logmode Override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv| REXX API Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

Part 1. Concepts and Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 1. NetView Access Services Concepts . . . . . . . . . . . . . . . . . 3NetView Access Services Modes of Operation . . . . . . . . . . . . . . . . . . . . 3The NetView Access Services Pseudo Terminal Concept . . . . . . . . . . . . . 4

Shared Pseudo Terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Unique and Individual Pseudo Terminals . . . . . . . . . . . . . . . . . . . . . 5Pseudo Terminal Prefix and Maximum Sessions . . . . . . . . . . . . . . . . . 6

Defining Different Terminal Models . . . . . . . . . . . . . . . . . . . . . . . . . . 7Matching a Real Terminal Name with a Pseudo Terminal Name . . . . . . . . . 8Pass Mode Application Session Considerations . . . . . . . . . . . . . . . . . . . 9The NetView Access Services Virtual Terminal Concept . . . . . . . . . . . . . 10

What the Virtual Terminal Concept Supports . . . . . . . . . . . . . . . . . . 11Functions that Leave Virtual Terminal Mode . . . . . . . . . . . . . . . . . . . 12Data Stream Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Invocation and Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Chapter 2. VTAM Considerations . . . . . . . . . . . . . . . . . . . . . . . . . 15How NetView Access Services is Defined in VTAM . . . . . . . . . . . . . . . . 15NetView Access Services Buffer Usage for VTAM Macros . . . . . . . . . . . . 16Logmode Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Logmode Entry Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Logmode Considerations for Printers . . . . . . . . . . . . . . . . . . . . . . . 18

Chapter 3. VSAM Considerations . . . . . . . . . . . . . . . . . . . . . . . . . 21VSAM Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

VSAM Profile Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21VSAM Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Reorganizing VSAM Data Sets . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Sharing VSAM Data Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Refreshing VSAM Profiles with the Latest Updates . . . . . . . . . . . . . . . . 26

Chapter 4. Security and Accounting Considerations . . . . . . . . . . . . . 27Network and Application Access Control . . . . . . . . . . . . . . . . . . . . . . 27

Application and Terminal Idle Time . . . . . . . . . . . . . . . . . . . . . . . . 27Installation-Wide Exits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Copyright IBM Corp. 1987, 1997 iii

User Data Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Logon Panel Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Terminal Based Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Synchronizing Passwords across Several Host Systems . . . . . . . . . . . 30Password Expiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31RACF PassTicket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31NetView Access Services Installation-Wide Exits . . . . . . . . . . . . . . . . 31NetView Performance Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Application Access Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Considerations for 7171 Attached Dial-In Terminals . . . . . . . . . . . . . . . . 33Considerations for Using the Dummy Logon Authorization Exit (EMSELGNX) . 34Session Transfer Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Chapter 5. Network Considerations . . . . . . . . . . . . . . . . . . . . . . . 35Network Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Session Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Response Time Monitor Considerations . . . . . . . . . . . . . . . . . . . . . . . 37NetView Performance Monitor Considerations . . . . . . . . . . . . . . . . . . . 38Network Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39User Response Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Gaining Access to CICS/VS Using NetView Access Services . . . . . . . . . . 40Gaining Access to IMS/VS through NetView Access Services . . . . . . . . . . 41

Chapter 6. General Considerations . . . . . . . . . . . . . . . . . . . . . . . . 43Resource Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Suppressing NetView Access Services Messages . . . . . . . . . . . . . . . . . 44Total Number of Users and Application Sessions . . . . . . . . . . . . . . . . . 44Using the TERMQ Operator Command for Load Balancing . . . . . . . . . . . 45Access Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Graphic Display Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Data Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Outbound-Only Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Outbound and Inbound Data Compression . . . . . . . . . . . . . . . . . . . 46

Using BIND User Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Automatic Logon Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Part 2. Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Chapter 7. Migration Considerations . . . . . . . . . . . . . . . . . . . . . . . 51Logon Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51VSAM Data Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Installation-Wide Exit Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51NetView Access Services Supplied Command Lists . . . . . . . . . . . . . . . . 52Primary and Auxiliary Storage Requirements . . . . . . . . . . . . . . . . . . . . 52Buffer Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Panel Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Chapter 8. Preparing to Customize NetView Access Services . . . . . . . 55Primary Virtual Storage Used by NetView Access Services . . . . . . . . . . . 55

Static Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Dynamic Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

iv NetView Access Services Version 2 Customization

Storage Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55CSA and SQA Storage Requirements . . . . . . . . . . . . . . . . . . . . . . 56Calculating NetView Access Services Storage . . . . . . . . . . . . . . . . . 56Example of Calculating the Primary Storage Required . . . . . . . . . . . . . 56

Auxiliary Storage Required for NetView Access Services . . . . . . . . . . . . . 57

Chapter 9. Customizing NetView Access Services after Base Installation 61Step 1: Generating the Customization Jobs . . . . . . . . . . . . . . . . . . . . 61Step 2: Running the Customization . . . . . . . . . . . . . . . . . . . . . . . . . 65Step 3: Verifying the Installation of the Batch Load Program . . . . . . . . . . . 75Step 4: Modifying EUSZAP Flag-Bit Area for Sharing VSAM Profiles (Optional) 75Step 5: Switching to Confidential Mode (Optional) . . . . . . . . . . . . . . . . . 76

Chapter 10. Customizing NetView Access Services for Your Environment 77Enabling the Generic Alert Interface to NetView . . . . . . . . . . . . . . . . . . 77Enabling the NetView Synergy Interface to the NetView Performance Monitor 78Enabling for Secondary Authentication . . . . . . . . . . . . . . . . . . . . . . . 81Customizing for Model Terminal Support . . . . . . . . . . . . . . . . . . . . . . 82Customizing NetView Access Services for Public Groups . . . . . . . . . . . . 82Preparing for NetView Access Services Startup . . . . . . . . . . . . . . . . . . 84

Chapter 11. Modifying NetView Access Services Panels, Messages, andCommands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Locating the Source Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Modifying the Source Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Modifying NetView Access Services Panels . . . . . . . . . . . . . . . . . . . . 91Migrating NetView Access Services Panels . . . . . . . . . . . . . . . . . . . . . 95Defining a NetView Access Services Help Panel . . . . . . . . . . . . . . . . . 99Guidelines for Rewriting Message Text . . . . . . . . . . . . . . . . . . . . . . 103

Message Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Generating a Message Table . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Specifying Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Example of a Message Definition . . . . . . . . . . . . . . . . . . . . . . . . 106Message Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Multilingual Support Considerations . . . . . . . . . . . . . . . . . . . . . . . . 107Modifying NetView Access Services Commands . . . . . . . . . . . . . . . . . 108

| Chapter 12. Customizing NetView Access Services Sample Exits to| Interface with RACF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Concept of the NetView Access Services Interface to RACF . . . . . . . . . . 111| External Application Authorization . . . . . . . . . . . . . . . . . . . . . . . . . 115| How Does External Application Authorization Change the Procedure . . . 116

Using RACF to Maintain External Groups . . . . . . . . . . . . . . . . . . . . . 117Comparison between Normal and External Groups . . . . . . . . . . . . . 118Where the Application Access Data Is Stored in RACF . . . . . . . . . . . 119How Application Access Data Is Stored in RACF . . . . . . . . . . . . . . . 119Deleting an Application from RACF . . . . . . . . . . . . . . . . . . . . . . . 122Installation Requirements in RACF . . . . . . . . . . . . . . . . . . . . . . . 123RACF Profiles Processed by NetView Access Services . . . . . . . . . . . 123Synchronization of RACF and NetView Access Services Databases . . . 126

Chapter 13. Customizing NetView Access Services Installation-WideExits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Overview of Installation-Wide Exit Routines . . . . . . . . . . . . . . . . . . . 129

Contents v

Coding Requirements for an Installation-Wide Exit Routine . . . . . . . . . . 130Installing an Installation-Wide Exit Routine . . . . . . . . . . . . . . . . . . . . 132EMSEADEX, Administration Exit . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Parameter List Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

EMSEAPAN, Automatic Logon and Logoff Exit . . . . . . . . . . . . . . . . . 141Parameter List Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Sample Automatic Logon and Logoff Exit . . . . . . . . . . . . . . . . . . . 142

EMSEATTE, Inactivity Timeout Exit . . . . . . . . . . . . . . . . . . . . . . . . 143Parameter List Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

EMSEBXML, Broadcast Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Parameter List Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

EMSEDTEX, Date and Time Exit . . . . . . . . . . . . . . . . . . . . . . . . . 147Parameter List Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Sample Date and Time Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

EMSEDVEX, Data Viewing Exit . . . . . . . . . . . . . . . . . . . . . . . . . . 149Parameter List Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Sample Data Viewing Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

EMSELGFX, Logoff Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151Parameter List Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Sample Logoff Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

EMSELGNX, Logon Authorization Exit . . . . . . . . . . . . . . . . . . . . . . 154| Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Parameter List Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157EMSELNEX, Language Name Exit . . . . . . . . . . . . . . . . . . . . . . . . . 161

Sample Language Name Exit . . . . . . . . . . . . . . . . . . . . . . . . . . 161Installing a New Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

EMSELVEX, Language Verification Exit . . . . . . . . . . . . . . . . . . . . . . 164Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Parameter List Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Sample Language Verification Exit . . . . . . . . . . . . . . . . . . . . . . . 165

EMSENPME, Accounting Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Parameter List Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

EMSEPRPS, Printer Presetting Exit . . . . . . . . . . . . . . . . . . . . . . . . 167Parameter List Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168Sample Exit EMSEPRPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

EMSESEEX, Session Establishment Exit . . . . . . . . . . . . . . . . . . . . . 171Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Parameter List Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172Sample Session Establishment Exit . . . . . . . . . . . . . . . . . . . . . . 176Using This Exit for Session Load Balancing . . . . . . . . . . . . . . . . . . 176

EMSESHRX, Shared Session Exit . . . . . . . . . . . . . . . . . . . . . . . . . 177Parameter List Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

EMSESREX, Session Reselection Exit . . . . . . . . . . . . . . . . . . . . . . 178Parameter List Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

vi NetView Access Services Version 2 Customization

Part 3. NetView Access Services Application Service Routines . . . . . . . . . . . 181

Chapter 14. Writing New Application Service Routines . . . . . . . . . . 183Major Functions of an Application Service Routine . . . . . . . . . . . . . . . 183

Establishing Addressability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Establishing and Terminating Sessions with Logical Units . . . . . . . . . . 183Communicating with Logical Units . . . . . . . . . . . . . . . . . . . . . . . 184

Coding Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185NetView Access Services Macros . . . . . . . . . . . . . . . . . . . . . . . . . 185

Macro Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186Operand Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

EMSSTRT, Initiate the Macro Interface . . . . . . . . . . . . . . . . . . . . . . 187EMSALLOC, Request a Session . . . . . . . . . . . . . . . . . . . . . . . . . . 187EMSDEALL, Deallocate a Session . . . . . . . . . . . . . . . . . . . . . . . . . 192EMSFBUF, Free a Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193EMSGATTR, Return Information about a Session . . . . . . . . . . . . . . . . 194EMSGBUF, Get a Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197EMSNPM, NetView Performance Monitor Interface . . . . . . . . . . . . . . . 198EMSPRETR, Prepare to Receive . . . . . . . . . . . . . . . . . . . . . . . . . 199EMSRECV, Receive Information . . . . . . . . . . . . . . . . . . . . . . . . . . 200EMSREQTS, Request to Send . . . . . . . . . . . . . . . . . . . . . . . . . . . 205EMSSENDD, Send Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206EMSSENDE, Send Error Response . . . . . . . . . . . . . . . . . . . . . . . . 208Using NetView Access Services Buffers . . . . . . . . . . . . . . . . . . . . . 209

Part 4. NetView Access Services REXX Application Programming Interface . . 213

Chapter 15. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Concept of Virtual Terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Installing the NVASAPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216Defining the Maximum Number of REXX Environments Required . . . . . . . 217Invoking the NVASAPI Functions or Subroutines . . . . . . . . . . . . . . . . 217Invoking REXX Execs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218Terminating REXX Execs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220Debugging of REXX Execs for NetView Access Services . . . . . . . . . . . 221Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221NVASAPI Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2223270 Attributes and Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222Programming Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Chapter 16. NetView Access Services REXX Application ProgrammingInterface Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225Prerequisite Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227Supplied Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227Returned Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

NVASAPI Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228CONVERT_POS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Contents vii

COPY_FIELD_TO_STR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231COPY_PASSWORD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233COPY_PS_TO_STR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235COPY_STR_TO_PS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237DIAGNOSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239DISABLE_AUTOLOG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243DISCONNECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244DISPLAY_PS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

| DISPMSG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247FIND_FIELD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250QUERY_CURSOR_POS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252QUERY_FIELD_ATTR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

| QUERY_LOGON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254QUERY_ORIGIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254QUERY_PS_UPDATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257QUERY_READ_STATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258QUERY_SESSIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

| QUERY_TERMINALS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260QUERY_VARIABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261QUERY_VT_STATUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262SEARCH_FIELD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263SEARCH_PS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265SENDKEY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266SEND_3270DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269SET_CURSOR_POS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270SET_SEND_MODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Chapter 17. REXX Execs for Automatic Logon to NetView AccessServices and Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

Description of the REXX Execs . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

Part 5. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

Appendix A. Reading the Syntax Diagrams . . . . . . . . . . . . . . . . . 303

Appendix B. NetView Access Services Administration Record Formats 305NetView Access Services Profile Concept . . . . . . . . . . . . . . . . . . . . 305

Profile Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305Profile Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306Profile Record Field Relationship . . . . . . . . . . . . . . . . . . . . . . . . 307Procedure for Updating Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 307Profile Update Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 308

Content of VSAM Profile Data Areas . . . . . . . . . . . . . . . . . . . . . . . 309User Profile Table (EMSSRTU) . . . . . . . . . . . . . . . . . . . . . . . . . 309Application Routing Table for Groups (EMSSRTG) . . . . . . . . . . . . . . 315Group Profile Table (GPRF) . . . . . . . . . . . . . . . . . . . . . . . . . . . 318Application Routing Table (EMSSRTS) . . . . . . . . . . . . . . . . . . . . . 321Group Access List Table (EMSGAL) . . . . . . . . . . . . . . . . . . . . . . 324

Appendix C. Customization Worksheets . . . . . . . . . . . . . . . . . . . 325

viii NetView Access Services Version 2 Customization

Part 6. Glossary, Bibliography, and Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337NetView Access Services Version 2 Publications . . . . . . . . . . . . . . . . 337Network Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337VTAM Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337VSAM Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337OS/VS Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337RACF Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337SNA Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337CICS Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337TSO Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337Additional Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

Contents ix

x NetView Access Services Version 2 Customization

Notices

References in this publication to IBM products, programs, or services do not implythat IBM intends to make these available in all countries in which IBM operates.Any reference to an IBM product, program, or service is not intended to state orimply that only IBM's product, program, or service may be used. Any functionallyequivalent product, program, or service that does not infringe any of IBM's intellec-tual property rights may be used instead of the IBM product, program, or service.Evaluation and verification of operation in conjunction with other products, exceptthose expressly designated by IBM, are the user's responsibility.

IBM may have patents or pending patent applications covering subject matter inthis document. The furnishing of this document does not give you any license tothese patents. You can send license inquiries, in writing, to the IBM Director ofLicensing, IBM Corporation, 500 Columbus Avenue, Thornwood, NY 10594, USA.

Programming Interface InformationThis book is intended to assist system programmers to customize NetView AccessServices.

This book primarily documents Product-sensitive Programming Interface and Asso-ciated Guidance Information.

Product-sensitive programming interfaces allow the customer installation to performsuch tasks as diagnosing, modifying, monitoring, repairing, or tuning of NetViewAccess Services Version 2. Use of such interfaces creates dependencies on thedetailed design or implementation of the IBM software product. Product-sensitiveprogramming interfaces should be used only for these specialized purposes.Because of their dependencies on detailed design and implementation, it is to beexpected that programs written to such interfaces may need to be changed in orderto run with new product releases or versions, or as a result of service.

However, this book also documents General-use Programming Interface and Asso-ciated Guidance Information provided by NetView Access Services Version 2.

General-use programming interfaces allow the customer to write programs thatobtain the services of NetView Access Services Version 2.

General-use Programming Interface and Associated Guidance Information is identi-fied where it occurs by an introductory statement to a chapter or section.

TrademarksThe following terms, denoted by an asterisk (*) in this publication, are trademarks ofIBM Corporation in the United States or other countries or both:

ACF/VTAM CICS DB2IBM IMS MVS/ESAMVS/XA NetView OfficeVision/MVSQMF RACF System/360System/370 VM/ESA VTAM

Copyright IBM Corp. 1987, 1997 xi

Tivoli is a trademark of Tivoli Systems, Inc.

Other company, product, and service names which may be denoted by a doubleasterisk (**), may be trademarks or service marks of others.

xii NetView Access Services Version 2 Customization

About This Book

The IBM* licensed program NetView Access Services Version 2 running under theMVS/ESA* operating system is a member of the NetView* family of products andprovides a single access control system for users of 3270-type terminal devices ina Systems Network Architecture (SNA) network, and supports the management of anumber of applications from a single terminal.

This book provides information on how to customize NetView Access ServicesVersion 2 for your own location. You should be familiar with the MVS/ESA oper-ating system, the VTAM* communication programs, VSAM, and the applicationsthat will be used through NetView Access Services Version 2.

Unless otherwise stated, NetView Access Services in this book refers to NetViewAccess Services Version 2.

Copyright IBM Corp. 1987, 1997 xiii

xiv NetView Access Services Version 2 Customization

| What Is New in NetView Access Services Version 2.1.1

| Four new features have been included in NetView Access Services Version 2| Release 1 Modification Level 1. These are:

| External Application Authorization

| Direct Logon

| Compact Application Selection panel

| Logmode override.

| The set of functions available with the REXX API feature has been extended.

| External Application Authorization| This feature enables NetView Access Services to use the application access infor-| mation defined in the RACF database when building the Application Selection| Panel for each user. The NetView Access Services administrator, therefore, need| no longer create security definitions for applications in NetView Access Services as| all this information will be taken from the RACF definition for the application.

| This enhancement improves the synergy between NetView Access Services and| RACF, reduces the NetView Access Services administration time, and hence| improves the usability of the NetView Access Services product.

| Direct Logon| This feature introduces the ability to define terminals that are to be logged on to| NetView Access Services without the logon panel being displayed. This feature| allows the NetView Access Services Application Selection panel to be displayed| directly when terminals are powered on.

| Compact Application Selection Panel| This is an additional format in which to display the NetView Access Services Appli-| cation Selection panel. With this new format you can display up to 42 applications| on a single screen. There is lo longer a maximum limit of 99 applications. The use| of this new format can be configured for each group.

| Logmode Override| This feature allows the NetView Access Services administrator to explicitly specify a| logmode to be used by NetView Access Services when establishing a session with| an application.

Copyright IBM Corp. 1987, 1997 xv

| REXX API Extensions| Three new REXX API calls have been added to allow users to accomplish the fol-| lowing tasks from REXX execs:

| Get a list of all the terminals attached to NetView Access Services, regardless| of which screen they are currently displaying.

| Get a list of all the terminals that are currently displaying the NetView Access| Services Logon Panel.

| Send a message to all the terminals attached to NetView Access Services,| regardless of which screen they are currently displaying.

xvi NetView Access Services Version 2 Customization

Part 1. Concepts and Considerations

This part provides information on the concepts of NetView Access Services andconsiderations required for customizing NetView Access Services for your installa-tion.

Copyright IBM Corp. 1987, 1997 1

2 NetView Access Services Version 2 Customization

Chapter 1. NetView Access Services Concepts

NetView Access Services is a VTAM application program that enables users in anSNA network to gain simultaneous access to several applications. NetView AccessServices uses VTAM to communicate with the applications.

This chapter and the following chapters in this part provide general information thatmay be useful when customizing NetView Access Services.

NetView Access Services Modes of OperationNetView Access Services has two modes in which users can gain access to appli-cations, “relay mode” and “pass mode”. Figure 1 shows the relay or pass modeconfigurations.

Figure 1. Relay or Pass Mode

Relay ModeNetView Access Services simulates a 3270 LU Type-2 device for each relay-modesession with an application. This simulated device is referred to as a “pseudoterminal”, and it acts as the Secondary Logical Unit (SLU) in the session betweenNetView Access Services and the application. To perform this simulation process,NetView Access Services uses a pool of pseudo terminals that are defined toVTAM as network resources in APPL definition statements. When a user starts arelay-mode session, NetView Access Services allocates a pseudo terminal nameand establishes a session with the application on the user’s behalf. The pseudoterminal name allocated for the session is defined by the administrator. All dataflow between the physical terminal and the application then passes throughNetView Access Services.


Pass ModeIn pass mode, the primary session end point (Primary Logic Unit (PLU)) function ispassed from NetView Access Services to the selected application. A direct sessionis established between the terminal and the application. NetView Access Servicesuses a VTAM facility (CLSDST PASS) to terminate the current session and estab-lish a new session between the terminal and the application selected by the user.After completion of the logon process only one session exists between the terminalSLU and the application PLU.

The NetView Access Services Pseudo Terminal ConceptThe following describes the pseudo terminal concept of NetView Access Services.This concept is only valid for relay mode.

One of the major user productivity functions of NetView Access Services is toprovide access to several applications concurrently from a single terminal. NetViewAccess Services interacts with an application as if it were a user’s terminal using apseudo terminal. That is, NetView Access Services establishes a session using apseudo terminal name with each active application the user selects.

The pseudo terminal name is an ACB that is defined to VTAM via an APPL defi-nition statement. NetView Access Services must be informed if a particular applica-tion can support parallel sessions using a single ACB. If the application cannotsupport this capability, NetView Access Services uses a Unique or Individual ACBfor each relay-mode session established to that application. Therefore the specificoption to select depends on the characteristics of the application.

Shared Pseudo TerminalsIf an application supports parallel sessions (for example, TSO, as shown inFigure 2), only one ACB is required for all sessions between NetView Access Ser-vices and the application, and an ACB type Shared can be defined.

Figure 2. Using a Shared ACB to Gain Access to TSO


Unique and Individual Pseudo TerminalsIf an application does not support parallel sessions (for example, CICS*), an ACB isrequired for each session between NetView Access Services and the application.In this case, either of the following can be done:

An ACB type of Unique can be defined. Unique ACBs are shown in Figure 3.This enables the ACB to be used by a user for one application. The number ofACBs required depends on the maximum number of concurrent sessionsbetween NetView Access Services and the application.

Figure 3. Using Unique ACBs

An ACB type of Individual can be defined. This enables the ACB to be used bythe same user for several applications. Individual ACBs are shown in Figure 4.

Chapter 1. NetView Access Services Concepts 5

Figure 4. Using Individual ACBs

Each of these ACBs represent an SLU (pseudo terminal) within the SNA network.NetView Access Services must establish a pseudo terminal ACB as the SLU in thesession between the relay mode application and NetView Access Services. TheACB can be defined as either Shared, Unique, or Individual, and its properties mustbe defined to VTAM as described in “APPL Statements for Each of the PseudoTerminal SLUs” on page 73.

Pseudo Terminal Prefix and Maximum SessionsWhen an application is defined to the system, values for the pseudo terminal prefixand the maximum sessions must also be specified.

If a Shared ACB type is defined, then only the pseudo terminal prefix is used as theterminal name for all relay-mode sessions to that application. The number of ses-sions that can be established using this single ACB is controlled by the maximumsessions value.

If a Unique or Individual ACB type is specified, then these two parameters are usedto derive the pseudo terminal names.

The name is constructed by taking the pseudo terminal prefix and suffixing anumber to it, making 8 characters in all. All such 8-character names must bedefined to VTAM. For example, for prefix EMSYAT, VTAM needs definitions forEMSYAT01 to EMSYAT99. The maximum sessions value can be used to set theactual upper limit required. For example, if maximum sessions was set to 20, thenEMSYAT20 is the highest-numbered SLU required.

Note: When an application is assigned to a user, a different pseudo terminalname can be specified for that user. If a pseudo terminal name is specificallyassigned to a user, NetView Access Services always uses that name to establishthe relay-mode session for that application. Otherwise, the pseudo terminal prefixinitially defined is used.


The maximum sessions value can be increased or decreased while NetViewAccess Services is running.

Defining Different Terminal ModelsSome applications require characteristics of the user terminal to be defined. Thismeans that the pseudo terminal must also be defined to the application. IMS, forexample, requires a definition of each terminal and its type.

To provide support for different terminal models using pseudo terminals, you mustdo the following for each application in question:

1. Define a different system-internal name and pseudo terminal prefix for eachmodel on the Assign an Application for the System panel.

2. Assign the system-internal name for the most frequently-used model to thegroup on the Assign an Application to a Group panel.

The session establishment exit EMSESEEX then determines the model type by useof the logmode parameter. For further details see the description of this exit inChapter 13, “Customizing NetView Access Services Installation-Wide Exits” onpage 129.

Figure 5 on page 8 shows an example of how the support for different terminalmodels can be implemented. The names in this sample refer to the names used inthe sample coding (in comments) of the EMSESEEX exit routine. The following isassumed:

IMSM2 is used as the system-internal name when IMS is defined to theNetView Access Services system. This system-internal name is specified whenthe application IMS is defined to a group. NVPIM2 is used as the pseudo ter-minal prefix for the default Model 2 pseudo terminal pool.

IMSM3 is used as the system-internal name for the Model 3 terminal typesystem definition. NVPIM3 is used as the pseudo terminal prefix for theModel 3 pseudo terminal pool.

IMSM4 is used as the system-internal name for the Model 4 terminal typesystem definition. NVPIM4 is used as the pseudo terminal prefix for theModel 4 pseudo terminal pool.

The sample assumes that Model 2 pseudo terminals are the default terminals con-nected to the IMS system. The pseudo terminal names created by NetView AccessServices based on the pseudo terminal prefix for the system-internal name must bedefined to IMS with the appropriate model types information. The names createdby NetView Access Services in this example are:

NVPIM201, NVPIM202 .... NVPIM299 for Model 2 type pseudo terminalsNVPIM301, NVPIM302 .... NVPIM399 for Model 3 type pseudo terminalsNVPIM401, NVPIM402 .... NVPIM499 for Model 4 type pseudo terminals.


Figure 5. Support for Different Terminal Models

Matching a Real Terminal Name with a Pseudo Terminal NameNetView Access Services can provide an SLU name based on the real terminalname. This could be used for the terminal based security, terminal associationCICS TCT, or for the IMSGEN. The system administrator can define the SLU (inthe pseudo terminal prefix field) containing asterisks on the Define an Applicationfor the System panel. This is referred to as a generic pseudo terminal name.

Information on how to enter the generic pseudo terminal name and how theresulting pseudo terminal name can be built can be found in NetView Access Ser-vices Version 2 Administration.

Notes:

1. The resulting pseudo terminal names must be defined as a VTAM APPL state-ment and in the target application, for example, in CICS TCT.

2. The Session Initialization exit EMSESEEX enables you to overwrite the SLUnames defined on the administration panels.


Pass Mode Application Session ConsiderationsConsider the following two items if you plan to use pass mode application sessionswith NetView Access Services.

Forwarding Terminal Sessions in Pass ModeNetView Access Services issues a SIMLOGON to regain control of the terminal LUif SIMLOGON=YES has been specified in the input parameters. VTAM queues theSIMLOGON request in a first in, first out (FIFO) queue.

If, for example, NetView Access Services passes the terminal LU to an applicationthat passes the terminal LU to another application (that is, to a third party) and alsoissues a SIMLOGON, VTAM queues this request as the next SIMLOGON in thequeue. When the terminal LU is logged off from the third party application, VTAMreturns the terminal to the application that issued the first SIMLOGON. If the ter-minal LU is logged off from the first application, VTAM gives the terminal to theapplication that issued the second SIMLOGON request.

If an LU is forwarded in this way through the network, it is not returned to the appli-cations in the same sequence as it was passed forward. Therefore, when you planto use the pass mode facility with SIMLOGON=YES, take note of the sequence inwhich the terminal is forwarded and returned in your environment. For further infor-mation, refer to Figure 6.

If SIMLOGON=YES has been specified in the input parameters, NetView AccessServices issues a SIMLOGON to regain control of the terminal LU that is passed toan application (in pass mode). This SIMLOGON request is queued by VTAM.When the terminal LU is returned to NetView Access Services, the NetView AccessServices Logon panel is displayed if RCONNECT=NO is specified in the inputparameters. If the input parameters specify RCONNECT=YES, NetView AccessServices displays the Application Selection panel upon return from a pass-modeapplication.

If SIMLOGON=NO is specified, NetView Access Services does not issue aSIMLOGON for the terminal LU that is passed to another application. If the ter-minal is returned because NetView Access Services has been defined as thedefault logon application, and SIMLOGON=NO is defined in the NetView AccessServices input parameter file, the Logon panel is always displayed, regardless ofwhat has been specified for the RCONNECT keyword.


Figure 6. Passing the Terminal through Several Systems with SIMLOGON=YES

Pass Mode Return If the Terminal Is Switched OffThis also refers to what happens if there is a power failure.

If the terminal is switched off while it is in session with an application, VTAM dropsthe session with the application. The pending queued SIMLOGON request isdropped from the queue and the NetView Access Services Logon panel or Applica-tion Selection panel is not displayed.

The NetView Access Services Virtual Terminal ConceptVirtual Terminal (VT) is a new concept for handling and storing incoming 3270 datastreams in NetView Access Services. The data stream coming from an applicationis processed by the VT function. VT acts on all 3270 orders, and stores the dataas a screen image . This screen image is always a true copy of the actual terminalscreen buffer, including the extended attribute buffer of the display terminal.

For example, when a Jump or Escape requires to save the current screen, only thenewly modified data is added to the VT buffer. No Full Screen Read operationmust be issued. When the screen has to be restored later, the VT component gen-erates a 3270 data stream out of its saved VT buffer, and sends it to the terminal.

This provides the following enhancements over current non-VT operation:

Improved line performance for all functions that require a Full Screen Read.This is especially important for installations using relatively slow remote lines.

VT operation is a prerequisite for the NVASAPI function, which works againstthe VT buffer to find fields or modify data, for example. These functions aredescribed in Chapter 16, “NetView Access Services REXX Application Pro-gramming Interface Functions” on page 225.


Session running in the background, for example, not displayed on the screen,continue to accept outbound data from an application, until this application iswaiting for input. This is important for Operator consoles with a lot of output.

In VT mode, NetView Access Services improves the handling of the applicationID display function. This means that the application ID is written to the screenonly if there is a protected field and no input field will be overwritten. The lastattribute overlayed by the application ID on the terminal screen is added at theend of the application ID to make sure that no colors, highlighting, or text onthe screen are changed. The appearance of the application ID on the terminalscreen depends on whether the display mode is currently set to extended orbase display mode.

Write optimization. NetView Access Services Version 2 uses enhanced com-pression algorithms. If Y is specified in the Data Compression field on theAssign an Application to a Group panel, then the type of compression for out-bound data streams depends on the virtual terminal definition for the applica-tion. If N is specified in the Virtual Terminal field on the Assign an Applicationto a Group panel, the normal compression method is used, which replacesrepeated characters with a Repeat to Address Order. If Y is specified in theVirtual Terminal field, an enhanced compression algorithm is used. The WriteOptimization function checks whether the data is already on the real terminal,and only the delta data (data that has changed) is transmitted in compressedformat. Erase/Writes may change to Update/Writes for this process.

Outbound and Inbound Data Compression. If F is specified in the Data Com-pression field on the Assign an Application to a Group panel, and Y is specifiedfor Virtual Terminal, NetView Access Services compresses the outbound dataas previously described, that is, only the changed data is sent. In addition,NetView Access Services removes all MDT-bits (Modified Data Tag) from thefield definitions sent to the real device. This reduces the inbound data becauseonly the data entered is sent to NetView Access Services. NetView AccessServices then adds the data from all other fields and sends it to the application.

What the Virtual Terminal Concept Supports

3270 Data Stream SupportThe VT function supports all 3270 base and extended orders. The extended attri-bute support is limited to the following attribute types:

1. Extended highlight (attribute type X'41')2. Foreground color (attribute type X'42') for up to 15 colors3. Background color (attribute type X'45') for up to 15 colors4. Character set (attribute type X'43')5. Transparency (attribute type X'46').

If other attribute types appear in the data stream, NetView Access Services tempo-rarily leaves VT mode, and continues working in non-VT mode of operation, untileither a command or a structured field that clears the screen, or the CLEAR keyrecovers from this situation.


Outbound 3270 Structured Field SupportThe VT function checks the header information in each structured field. Some ofthe structured fields are handled by the VT terminal function before they are passedto the terminal. Other structured fields are just passed to the terminal withoutaction.

Inbound 3270 Structured Field SupportThe VT function checks each Structured fields header information. Some of thestructured fields will be handled by the VT function before they are passed either toNetView Access Services or to the application. Other structured fields are justpassed to the application without action.

Virtual Terminal and 3270 Null/Space HandlingWhen a virtual terminal is configured for an application, NetView Access Servicesno longer uses the Read Buffer command to read the complete screen, forinstance, for a Jump or Escape. Instead, the Read Modified data stream commandis used to update the virtual terminal buffer in NetView Access Services storage.Because the Read Modified command suppresses all nulls from the applicationpanel, input data may appear shifted when the saved application panel is redis-played. This is similar to the effect seen when using host editors, such as SPF,when working with Nulls ON. To avoid this effect, it is recommended to run the3270 terminal with the Enhanced Null/Space processing set to ON. EnhancedNull/Space processing provides all the advantages of Read Modified, but no longershifts data. For further information on Enhance Null/Space processing and how toset it to ON, refer to 3174 Establishment Controller Terminal User’s Reference forExpanded Functions.

Functions that Leave Virtual Terminal ModeThe following functions cause NetView Access Services to temporarily leave VTmode of operation:

DBCS (Double Byte Character Set) data in a data stream Use of Multiple Partitions BIDI (Bidirectional Languages, for example, Arabic, Hebrew) in a data stream Format Storage Structured fields Attributes appearing in the data stream other than 3270 base and extended

orders and attribute types previously mentioned under 3270 data streamsupport.

These functions cause NetView Access Services to temporarily leave VT mode ofoperation, until the application sends a command that clears the VT buffer, or theuser presses the CLEAR key on the terminal. In this case, VT operation isresumed.

Data Stream Error HandlingIf virtual terminal function detects a data stream error, a NetView Access Servicesoperator message is issued. This message includes an error code that identifiesthe cause of the error. Then the defective data stream is passed to the terminal.The sense code generated by the terminal then causes the session to be left andthe Application Selection panel is displayed with an error message.

If the data stream error is detected while the VT function is working with a sessionin the background, a NetView Access Services operator message is issued, and


the defective data stream is queued and later sent when the user switches to thisapplication. The logical unit will appear busy during this queuing time.

Invocation and InteractionVT mode of operation is the default for NetView Access Services. The systemadministrator can disable VT mode for an application. For further information, referto NetView Access Services Version 2 Administration.

The VT function for the NetView Access Services panels is always allocated andused. It can not be disabled by administration.


Chapter 2. VTAM Considerations

The following provides VTAM considerations.

How NetView Access Services is Defined in VTAMNetView Access Services can be defined in VTAM in a number of ways that can beused to implement a user logon to NetView Access Services.

NetView Access Services Defined as a LOGAPPL for a TerminalUsing the LOGAPPL operand in the VTAM definition statement for a terminal to beconnected to NetView Access Services causes VTAM to initiate a session automat-ically when the terminal is activated. This means that when the terminal isswitched on, the NetView Access Services Logon panel is displayed. The sessionis created immediately, even if the terminal is not in use. This might influence thetotal system performance, because the session establishment processing and thesending of the Logon panel is performed by NetView Access Services. A high CPUload might occur during system start or restart.

NetView Access Services Defined as a VTAM USSTAB EntryTo request a session with an application program, an LU can send a formattedlogon request to VTAM specifying the name of the application program (in thiscase, NetView Access Services) and some other information. This is hard coded inthe terminal LU and therefore not all terminals can initiate a formatted logonrequest.

However, VTAM can also accept logons in character-coded (unformatted) form froman LU. To do so, the unformatted system services (USS) component of VTAMmust have the appropriate tables to convert the character strings into formattedrequests. The installation must create these tables.

Using the VTAM USS, the terminal is connected to VTAM when it is switched on.When a piece of character-coded information is entered, VTAM establishes asession between the terminal and the application defined in the USS definitions.That is, the USS table (USSTAB) tells VTAM what to do. If USSTAB is used, theterminal is in session with VTAM only when it is switched on, and the session toNetView Access Services is established on user request. This means that aUSSTAB definition causes less load than a LOGAPPL definition. The definition youuse in your environment depends on your performance and usability requirements.

For additional information refer also to VTAM Resource Definition Reference.

NetView Access Services Defined As an Entry in a VTAMInterpret TableIf the SEQNCE operand on the LOGCHAR macro is not specified for a VTAM inter-pret table entry, and the APPLID operand specifies the NetView Access Servicesapplication name, then all user logons are directed to this application. That is, nomatter what the user enters at the terminal, if this is the first entry in the interprettable, the user logon is always forced to the NetView Access Services Logon panel.Therefore, by specifying the INTAB operand on any or all of the VTAM terminal orLU definition statements, any terminal can be forced to USSTAB entry.


To force users to always access applications through NetView Access Services aVTAM interpret table can be built.

Figure 7 shows a sample VTAM interpret table.

INTBL INTAB LOGCHAR APPLID=(APPLICID,NVAS_APPL),SEQNCE='NVAS' LOGCHAR APPLID=(APPLICID,NVAS_APPL),SEQNCE='nvas' LOGCHAR APPLID=(APPLICID,NVAS_APPL) ENDINTAB END

Figure 7. Sample VTAM Interpret Table

Where NVAS_APPL is the name of your NetView Access Services application.

This table automatically displays the NetView Access Services logon screen regard-less of the key stroke entered at the VTAM USSMSG10 screen.

NetView Access Services Buffer Usage for VTAM MacrosNetView Access Services uses VTAM macros, SEND and RECEIVE, with both ter-minals and applications, but does not use the authorized path facility of VTAM.VTAM uses Service Request Block (SRB) scheduling for much of theSEND/RECEIVE functions. NetView Access Services uses multiple Task ControlBlocks (TCBs) to perform various functions and therefore can exploit a multi-processor machine, in conjunction with the SRB scheduling of VTAM.

It should also be noted that NetView Access Services uses the VTAM LargeMessage Performance Enhancement Outbound (LMPEO) option for SEND oper-ations, as appropriate. For this purpose it uses the facilities of VTAM to split alarge data buffer into one or more Request Units (RUs) for transmission to thereceiver. None of the RUs generated by VTAM exceed the RU size specified in theBIND for sending in that direction on the session. Because there are two separatesessions in relay mode, the RU sizes can differ between the terminal-to-NetViewAccess Services session and the pseudo terminal-to-application session. You cancompare the RU size used in the logmode table entries (EMSMODE), used byNetView Access Services for pseudo terminal sessions, to the RU size that isacceptable to each application. Then you can determine whether changes couldimprove performance.

Logmode ConsiderationsThe following provides information on logmode entry analysis and provides consid-erations for printers.

Logmode Entry AnalysisA logmode entry or BIND information is used to establish the session between thereal terminal and NetView Access Services. However, NetView Access Services,when establishing a relay mode session with an application, does not use the samelogmode entry or BIND. When a session request (CINIT) is received from the ter-minal in the VTAM logon exit for NetView Access Services, it analyzes the


PSERVIC field of that BIND to select an equivalent logmode entry from its logmodetable, EMSMODE, as follows:

1. The LU type of the terminal is first examined. The only LU types that are sup-ported are LU Type-0 and LU Type-2. Both the Function Management (FM)and Transmission Services (TS) profiles are examined to determine the LUtype. If the FMPROF and TSPROF are 02, then an LU Type-0 is assumed. Ifthe FMPROF and TSPROF are 03, then an LU Type-2 is assumed. Otherwise,a message is issued (EMS0517E).

2. The logmode for the incoming terminal session must not be specified by usingan Exception Response Only protocol. This session request will be rejected, ornot established by NetView Access Services. All data to the terminal is sent tothe terminal with Exception Response, with the exception of Change Directioncaused by the Attention key. This is sent with Definite Response.

You are required to use one of the following protocol types:

No response Definite response only

Refer also to the note on page 80 Definite or exception response

for the terminal session (PRIPROT parameter in the logmode table entry) andthe application session (SECPROT parameter in the logmode table entry).

3. The PSERVIC is examined to determine if extended data stream or queryfacility is supported for the terminal. If the terminal supports this facility, thelogmode entry name that is selected has the prefix EXT. However, if the ter-minal does not support the extended data stream, the prefix SNA is used forthe logmode entry name selection.

4. The next element analyzed in the original BIND is the screen size of the ter-minal. The PSERVIC field is examined to determine whether the terminal canalso support an alternative screen size. The hexadecimal value of X'7F' in thescreen size control byte in the PSERVIC indicates that an alternative screensize is supported and X'7E' indicates that only a primary screen size can beused. A value of X'03' means that a dynamic screen size is used. Theprimary or alternative screen size or both, determine the terminal type or modelthat is selected for the logmode entry name. The suffix that is appended to theEXT or SNA prefix is the same as that used in the VTAM supplied defaultlogmode entry table—ISTINCLM.

5. If a match cannot be made with the value in the PSERVIC field, then amessage is issued (EMS0517E) and an attempt is made to establish thesession using the logmode entry used to establish the original terminal session.However, for NetView Access Services to use that particular logmode entry, itmust be added to the EMSMODE table that NetView Access Services uses.

The logmode entries in the EMSMODE table do not include any Class ofService (COS) name. Therefore, to ensure consistent transmission priority forinteractive sessions in relay mode, the EMSMODE table entries must also beupdated to match the installation’s requirements. Also, this logmode entry canbe defined only for an LU Type-2 device, because NetView Access Servicesonly uses an LU Type-2 device as a pseudo terminal. See Figure 8.

Chapter 2. VTAM Considerations 17

Figure 8. VTAM and NetView Access Services Logmode Entry Tables

For example, for a 3270 terminal that supports Extended Data Stream, NetViewAccess Services uses the prefix EXT for the logmode entry. If this terminal alsosupports a primary screen size of 24 by 80, a 2-byte hexadecimal value of 1850,and an alternate screen size of 32 by 80 or X'2050', then NetView Access Ser-vices maps that to a terminal type/model suffix of 32783. Therefore the logmodeentry that is used by NetView Access Services to establish any relay mode ses-sions for this terminal is EXT32783.

This analysis of the original terminal logmode entry is done only for relay modesessions. For pass mode sessions, the original logmode entry used to establishthe session between NetView Access Services and the terminal is used, unless it ischanged by the EMSESEEX installation-wide exit.

The logmode entry used when NetView Access Services establishes a session withan application can be:

| Overridden by the user. This is done on the Application Selection panel by| entering the application ID, followed by LM= and the new logmode value. For| example:

| 5 LM=EXT32782

| The new logmode value remains active until the user logs off from the applica-| tion.

| Specified by the NetView Access Services administrator using option 6 of the| ADM function. This LogMode will be used by NetView Access Services to| open all the server sessions with this application both in pass-mode and in| relay-mode, when the user requesting the session is logged on this group.

| The logic priority for choosing the logmode to be used is as follows:

| 1. Session establishment exit (EMSESEEX)

| 2. LogMode field on option 6 of ADM function

| 3. NetView Access Services chosen logmode.

Logmode Considerations for PrintersNetView Access Services allows a user to send a copy of an application panel to aprinter. The copy can be sent:

Directly via VTAM to a line printer connected to NetView Access Services. Forinformation on defining VTAM printers to NetView Access Services, refer to“Customizing for Model Terminal Support” on page 82.

To a JES2 or JES3 system printer.


NetView Access Services supports the printing of:

Alphanumeric characters Special displayable characters Double Byte Character Set (DBCS) characters

Field outlining Nondisplayable fields.

The following characters are ignored by NetView Access Services:

Intensified display Extended highlighting Extended color Character sets other than the default and the DBCS character set

Transparency.

Notes:

1. Truncation takes place if the presentation space of the printer (rows andcolumns) is less than the presentation space of the terminal.

2. At the beginning of printing, NetView Access Services assumes that the printeris already positioned on a new page.

Print Support for Printers Connected to NetView AccessServicesNetView Access Services establishes a session with a printer via VTAM when theuser requests to print an application panel. The printer session is available as longas:

No other application program requests the printer NetView Access Services is sending print data or data is queued NetView Access Services is running.

NetView Access Services supports the following printer type sessions:

LU1 LU-LU session type 1 (data stream based on the SNA Character String(SCS) or structured fields).

NetView Access Services uses FM profile 3 and TS profile 3. Any othervalues for these profiles are changed to 3. NetView Access Services sup-ports the exchange of FM headers if requested by the SLU. It is suggestedthat the printer is run with FM headers. This allows NetView Access Ser-vices to determine the printer row and column size as well as the ability tosupport DBCS and field outlining.

If the exchange of the FM headers is not supported, NetView Access Ser-vices assumes that the printer does not support DBCS and field outlining. Inthis case, NetView Access Services uses a default column size of 80 and adefault row size of 72.

LU3 LU-LU session type 3 (an SNA 3270 data stream).

If the printer is defined to support extended data stream (that is, query issupported), then NetView Access Services checks whether the printer canhandle DBCS and field outlining. If not, NetView Access Services assumesthat the printer does not support these.

Chapter 2. VTAM Considerations 19

Print Support for System PrintersNo truncation is performed by NetView Access Services, and it is assumed that thesystem printer supports DBCS and field outlining. No special entry is needed in theNetView Access Services supplied logmode table, EMSMODE.


Chapter 3. VSAM Considerations

The following describes some VSAM items that should be considered in conjunctionwith your NetView Access Services.

VSAM PerformanceThe following VSAM items may have an impact on the performance of yourNetView Access Services.

VSAM Profile LocationNetView Access Services maintains a set of VSAM profile data sets. Most of theprofiles are used only at NetView Access Services startup and for administratorupdates. However, the EMSSRTU data set containing the user profiles is used atevery user logon to NetView Access Services. In addition, the EMSALLT profiledata set is used for each automatic logon or logoff. Therefore, it is recommendedto locate these data sets on a DASD volume that allows for fast access. If youwant to share the data sets, they have to be located on a shared device.

The SRTU can be discarded only if no Normal groups exist in the NetView AccessServices system. The EMSGAL profile data set is read whenever the ADMcommand is issued.

VSAM TuningWhen a user assigned to use applications in a normal group logs on, NetViewAccess Services performs VSAM I/O to retrieve user profile record from its VSAMuser data set (EMSSRTU).

The number of records retrieved from the VSAM data set corresponds to thenumber of applications that the user is authorized to access. For instance, if a useris authorized to use three applications, three separate records are retrieved fromthe VSAM data set. Each user profile record contains one authorized applicationfor the user and the access parameters (for example, jump key or applicationsequence) for that application.

VSAM tuning for the user-profile data set can improve VSAM access performanceand therefore reduce logon response time and CPU usage. Some of the VSAMtuning techniques are:

Allocate additional index buffers.

The recommended method for allocating buffers is to specify explicitly thedesired number of buffers on the DD statement using the AMP parameters withBUFNI subparameters.

The index and data components may be allocated on different volumes toimprove direct processing performance if IMBED is not used.

For further information, refer to the MVS/ESA VSAM Administration Guide.


Reorganizing VSAM Data SetsVSAM data sets must be reorganized using IDCAMS services periodically toimprove access to the VSAM data sets and consequently to improve the systemperformance. It is the system administrators responsibility to determine the periodbetween reorganizations based on the frequency of data set updates.

Sharing VSAM Data SetsNetView Access Services allows its profiles, which are located in VSAM data sets,to be shared between more than one program. This allows an installation to runmore than one NetView Access Services and the Batch Load Facility concurrently,using the same profiles. For information on the Batch Load Facility, refer toNetView Access Services Version 2 Administration. The profile sharing allows forbalancing the system workload or increasing the system’s availability.

When sharing VSAM data sets, NetView Access Services locks the VSAM datasets for all ADD, UPDATE, READ, and DELETE requests.

VSAM I/O activity of NetView Access Services is mainly performed during theinitialization phase and the refresh phase. The EMSDSRTG, EMSDSRTS,EMSDPLDT, EMSDGPRF, and EMSBROD files are read when a REFRESHcommand is processed. The user profile (EMSSRTU) is read when a user logs onto NetView Access Services, and the automatic logon profile (EMSDALLT) is readwhenever an automatic application logon or logoff is performed. EMSDALLT iswritten to when an automatic logon profile is recorded. Other files are also writtento when the administration facility is used for update. The normal use of the admin-istration facility does not produce any significant I/O activity.

Prerequisites for Sharing Data SetsSharing VSAM data sets NetView Access Services follows the requirements, speci-fied in the MVS/ESA VSAM Administration Guide.

The actual processing in NetView Access Services is triggered by two bits in theEUSZAP flag-bit area (refer to Figure 10 on page 25):

Cross-region profile-sharing flag Cross-system profile-sharing flag.

The job EMSVLOCK is provided by NetView Access Services to modify theEUSZAP flag-bit area according to your installation requirements. For further infor-mation refer to “EMSVLOCK” on page 75.

Ensuring Data Integrity for READ and WRITE Access

Cross-Region SharingConcurrent VSAM accesses, invoked by the VSAM subtasks of severalNetView Access Services or the Batch Load Facility in the same operatingsystem, are synchronized using the ENQ and DEQ macros. You must enablecross-region sharing by using value '1' for the cross-region profile-sharing flag.

The ENQ and DEQ macros are invoked with the SYSTEMS parameter and,supported by the global resource serialization facility (GRS), have a scopeacross operating systems.


The macros use the fixed value EMSELOCK for the queue name and theactual values specified for the appropriate VSAM DD name in the EMSSTARTjob for the resource names. An example with resource names is shown inFigure 9.

//EMSSTART ...EMSSRTS DD DSN=EMS.SAMPLE.EMSSRTSEMSSRTG DD DSN=EMS.SAMPLE.EMSSRTG

...

Figure 9. Example of EMSSTART Job Showing Resource Names

In the example, the resource names are:

EMS.SAMPLE.EMSRTS for SRTSEMS.SAMPLE.EMSRTG for SRTG

Using the resource names for each VSAM data set reduces the occurrence ofa locking conflict. For example, a system administrator can add a new applica-tion to the NetView Access Services system (adding a new SRTS record) inparallel to a user who updates an SRTU profile.

VSAM write access is locked with the EXCLUSIVE parameter of the ENQmacro, and read access is locked with the SHARED parameter. For moreinformation on the ENQ and DEQ macros refer to MVS/ESA ApplicationDevelopment Macro Reference.

Cross-System SharingIf the NetView Access Services systems that share the data sets are located ondifferent operating systems, in addition to the ENQ and DEQ processing, reo-pening of the particular data set occurs every time it is accessed. This ensuresthat the different VSAM systems are always working with the true information ofthe data sets concerning CI/CA splits. You must enable cross-system sharingby using value '1' for the cross-system profile-sharing flag. The flag can beswitched with the EMSVLOCK job. For further information refer to“EMSVLOCK” on page 75.

Share Options for NetView Access Services Used VSAM Data Sets

NetView Access Services always requires write access when opening the VSAMdata sets. For cross-region sharing you must ensure that the VSAM data sets youwant to share between more than one NetView Access Services are defined withSHAREOPTIONS(4,3) parameter. Note that the shipped default option for NetViewAccess Services is SHAREOPTIONS(3,3).

If in addition you want to share the data sets across operating systems,SHAREOPTIONS(3,3) is sufficient. This is because the synchronization ismanaged by NetView Access Services in a different way.

Note: Sharing VSAM data sets always affects system performance. Most per-formance degradation can be expected from setting the cross-system profile-sharing flag on. It is therefore recommended not to switch this bit on if you do notintend to share the data sets across operating systems.

Chapter 3. VSAM Considerations 23

Sharing VSAM data sets is disabled by submitting the EMSRESTO job. For furtherinformation, refer to “Modifying EUSZAP Flag-Bit Area for Sharing VSAM Profiles”on page 75.

Activating Modified Share Options

You can change the SHAREOPTIONS parameter of your data sets using theALTER command. For instance, before you start a Batch Load job concurrently toa running NetView Access Services, you can change the share option to 4,3 and,after the job has completed, reset the share option to 3,3.

Note: A changed share option must be activated in NetView Access Services.

NetView Access Services provides the ability to activate a modified VSAM shareoption in a running NetView Access Services system. The share option becomesactive in NetView Access Services by closing and reopening all NetView AccessServices allocated VSAM clusters.

The CLOSE/OPEN process cannot be invoked separately, but it is linked with therefresh function. The CLOSE/OPEN process is independent of the share optionspecified in the EUSZAP area. This means, if no cross-region sharing and nocross-system sharing is specified, the NetView Access Services allocated VSAMclusters are closed and reopened.

You must enable the “CLOSE/OPEN before REFRESH” by using value '1' for the“CLOSE/OPEN before REFRESH flag”. This flag can be switched with theEMSVLOCK job. For further information refer to “EMSVLOCK” on page 75.

Notes:

1. Switching the sharing of VSAM data sets on and off is not possible whileNetView Access Services is running.

2. All NetView Access Services systems that share the data sets must berestarted after the function has been switched on or off.

3. NetView Access Services reads the VSAM data sets during startup and thenmaintains all profiles in main storage that are not user related. This avoidsadditional disk access during runtime. However, a refresh function is requiredevery time the VSAM data sets are modified via an external program thatshares the data sets, for example, a batch load or a second NetView AccessServices.

4. Sharing VSAM data sets does not guarantee data consistency for concurrentupdates between NetView Access Services profile data and the VSAM datasets. Installations are advised to put into place procedures to ensure that onlyone administrator function tries to modify a given record at a particular time.

Suppressing Reopening of Data Sets for Cross-System SharingWhen cross-system sharing is requested, reopening of the particular data setoccurs every time it is accessed. Reopening can be suppressed for one or moredata sets by one or more indicators in the EUSZAP flag-bit area. For example,when two NetView Access Services systems share all VSAM data sets with theexception of EMSBROD (each system has its own EMSBROD cluster), or whentwo NetView Access Services systems share an EMSBROD VSAM cluster and allother VSAM clusters used are different for each NetView Access Services system.


Only the NetView Access Services cluster EMSBROD can be handled differentlythan other NetView Access Services clusters, because EMSBROD has no logicaldependency on any other NetView Access Services cluster.

Note: Using shared profiles together with unshared profiles in a NetView AccessServices system in another way to that described can lead to unpredictable results.

Cross-system sharing of NetView Access Services VSAM profiles is indicated via aflag-bit area in the NetView Access Services zap area EUSZAP. The flag-bit areacan be switched with the job EMSVLOCK and can be reset with the jobEMSRESTO.

EUSZAP Flag-Bit Area

1st Byte

XXXX Xððð ðððð ðððð │││

││└───────────── Cross region profile sharing flag││ '1' = share profiles cross region││ 'ð' = no profile sharing at all

│││└────────────── Cross system profile sharing flag│ '1' = share profiles cross system│ Cross system sharing is started│ only if the cross region sharing

│ is activated.│ It is possible to suppress cross│ system profile sharing on profile│ level. See 2nd byte.│ 'ð' = no cross system sharing

│└─────────────── CLOSE/OPEN before REFRESH flag

'1' = A VSAM CLOSE/OPEN is issued foreach entered REFRESH commandregardless of the profile sharing status.

'ð' = VSAM CLOSE/OPEN is issued dependingon the profile sharing status.

2nd Byte

┌───────┬────── This flag area byte is used for cross│ │ system sharing only

XXXX Xððð ðððð ðððð (cross system flag = '1'││││ ││││ cross region flag = '1').││││ ││││ It indicates all VSAM profiles that││││ ││││ are excluded from cross system profile││││ ││││ sharing. That means VSAM CLOSE/OPEN││││ ││││ is suppressed for the indicated

││││ ││││ profiles.││││ ││││ Each flag agrees with one profile:││││ │││└────── EMSBROD ─ Time controlled messages││││ ││└─────── EMSGAL ─ Admin. access list profiles││││ │└──────── EMSALLT ─ Automatic logon profiles││││ └───────── EMSGPRF ─ Group profiles

│││││││└─────────── EMSPLDT ─ BIND user data profiles││└──────────── EMSSRTU ─ User profiles│└───────────── EMSSRTG ─ Group application profiles└────────────── EMSSRTS ─ System application profiles

Figure 10. EUSZAP Flag-Bit Area

Chapter 3. VSAM Considerations 25

Example of Modifying the EUSZAP Flag-Bit AreaTable 1 shows an example of modifying the EUSZAP flag-bit area.

Table 1. Example of Modifying the EUSZAP Flag-Bit Area

ZAP Value Meaning

0100 VSAM cross-region sharing

0300 VSAM cross-system sharing

0400 CLOSE/OPEN VSAM data sets for each refresh command

0301 VSAM cross-system sharingThe profile EMSBROD is excluded from cross-system sharing

Refreshing VSAM Profiles with the Latest UpdatesThe refresh function allows an installation to read in the following profiles fromVSAM:

EMSSRTS EMSSRTG EMSGPRF EMSPLDT EMSBROD

to then update the NetView Access Services profiles with the latest versions fromVSAM.

Note: Concurrent updates can result in data inconsistency between NetViewAccess Services profile data and the VSAM data sets. The Locking function pre-vents destroying the VSAM data sets during a parallel operation, but it does notprevent data inconsistency between NetView Access Services profile data and theVSAM data sets.

Installations are advised to put into place procedures to ensure that only oneadministrator function tries to modify a given record at a particular time.


Chapter 4. Security and Accounting Considerations

The following provides information on various security aspects and the exits thatcan be used for accounting tasks.

Network and Application Access ControlNetView Access Services can secure access to both the network and applications.It can act as a front-end security system for the SNA network in that only users witha valid user ID and password that are registered with NetView Access Services anda security management system such as RACF* can gain access to the network.The facility protects the SNA network from any unauthorized access. You cantherefore make it a requirement that every user enters into your network exclusivelyvia NetView Access Services.

You can use the following methods to implement a user logon to NetView AccessServices:

After switching on, log the users’ terminals automatically on to NetView AccessServices by specifying the operand LOGAPPL on the VTAM terminal LU defi-nition statement.

For further information refer to “NetView Access Services Defined as aLOGAPPL for a Terminal” on page 15.

Define NetView Access Services in the USSTAB table and allow users to issuea command to invoke NetView Access Services.

For further information refer to “NetView Access Services Defined as a VTAMUSSTAB Entry” on page 15.

To force any or all users to log on to NetView Access Services, a null entry in aVTAM interpret table can be used.

For further information refer to “NetView Access Services Defined As an Entryin a VTAM Interpret Table” on page 15.

NetView Access Services also allows a system administrator to restrict the applica-tions that are accessible by each user or group of users. The user can thereforeonly have access to those applications that the system administrator associatedwith the group, and that the group administrator has authorized the user to gainaccess to.

Application and Terminal Idle TimeThe system can also be used to help protect against unauthorized access from aterminal that is connected but not being used. NetView Access Services discon-nects relay mode application sessions for which there is no user activity after apredefined timeout period has elapsed. The system administrator specifies thetimeout period for each relay mode application session and, if NetView Access Ser-vices receives no data from the application after the specified idle time, that sessionis disconnected.

If there is no input activity from a terminal for a predefined time, the sessionbetween NetView Access Services and the terminal is disconnected.


If the terminal idle timeout occurred with an application screen displayed on theterminal, or with the NetView Access Services Application Selection panel showinghighlighted applications on the terminal, the application sessions are still maintainedby NetView Access Services until the application idle time-out for a particular appli-cation occurs. For additional information refer to “APPL Control Statement” onpage 68 and the IDLETIME operand in the list that follows Figure 18 on page 68.

Installation-Wide ExitsIn addition to the standard administrative security mechanisms, NetView AccessServices provides installation-wide exits that can be used to implement additionalsecurity measures.

Restricting UsersThe logon authorization exit EMSELGNX is invoked each time a user logs on toNetView Access Services. This exit can be used to verify a user’s access using asecurity management system such as RACF, and can deny access at that point.You can also use the logon exit if RACF or another security system is not used.

The PUBUSER User ID: An initial administrative user ID (PUBUSER) is also pro-vided with NetView Access Services. NetView Access Services does not allow thisuser ID to be deleted. The security management system can prevent other usersfrom logging on with this user ID. For example, the security administrator canrevoke the PUBUSER user ID in RACF.

Restricting ApplicationsThe session establishment exit EMSESEEX is invoked each time an applicationsession is established by a user. Information is passed to the exit such as thetarget application name, the user’s group and user ID, the name of the terminal,and even the logmode entry. You can use this exit to deny access to the applica-tion in addition to that already provided through the standard administrative facilitiesof NetView Access Services.

Restricting TerminalsYou can ensure that only terminals with specific names or naming conventions cangain access to the system. Using the SERVRTN definition statement, an installa-tion can specify through the INPLU operand the specific LU names or a generic LUname that can access NetView Access Services. This assigns terminals to a spe-cific Application Service Routine (ASR), which can be either the NetView AccessServices-supplied routine—End User Services (EUS) or a user-written ASR. Forfurther information refer to Figure 19 o

Date post:	13-Feb-2021
Category:	Documents
Upload:	others
View:	1 times
Download:	1 times

Customization - IBMpublib.boulder.ibm.com/tividd/td/job/SH19-4502-00/en_US/... · 2006. 10. 25. ·...

Documents